Token

Эксперт OTUS Александр Колесников поделился с нами полезной статьёй, которую написал специально для студентов курса "Пентест. Практика тестирования на проникновение".

Мы же в свою очередь приглашаем всех желающих принять участие в бесплатном демо-уроке на тему: "Windows AD сбор информации, эскалация привилегий. Эксплойты и уязвимости последних 5ти лет."

Предыдущая статья рассказывала о том, как эксплойты используют технику копирования токена для повышения привилегий. В этой статье мы попытаемся рассмотреть еще одну технику модификациитокенов, а также постараемся узнать, как задаются привилегии, которые помещаются в Primary Token.

Все примеры в статье имеют ознакомительный характер, и если вы захотите повторить эксперименты, то используйте виртуальную машину, так как некоторые из действий могут вывести вашу рабочую машину из строя. Все эксперименты выполняются только для исследовательских задач.

Настройка тестового стенда

Для экспериментов подойдет пара виртуальных машин, которые работают по NAT сети. Две потому что нет другого способа проводить ядерную отладку операционной системы. А NAT сеть, чтобы были отладочные символы, с ними проще и быстрее искать данные без исходного кода. Настройка отладчика есть на просторах сети, но все же ниже будет пару строк как это делается для операционной системы Windows 10 1909.

1. Устанавливаем отладчик. Для операционной системы Windows есть только Windbg Preview, установим его:

2. Переводим целевую операционную систему в отладочный режим:

Перезагружаем систему. И открываем вторую машину, которая будет содержать отладчик:

После перезагрузки системы:

Так как это Windbg Preview все настройки по загрузке и хранению отладочных символов, были выполнены автоматически. Нам остается только дождаться когда они будут полностью загружены. После этого начинаем наше исследование.

Token

Официальная документация гласит, что основные данные, которые существуют в операционной системе касательно привилегий пользователя хранятся в специальной структуре, которая называется Primary Token. В прошлой статье мы не останавливались подробно на части, которая описывается Se* привилегиями. Наиболее интересные привилегии, которые могут быть использованы для эскалации привилегий, вывода из строя ОС:

• SeAssignPrimaryToken

• SeAudit

• SeBackup

• SeChangeNotify

• SeCreateToken

• SeDebug

• SeLoadDriver

• SeLockMemory

• SeManageVolume

• SeRestore

• SeSecurity

• SeTakeOwnership

Каждая строка это константа, которая определяет, какие привилегии существуют в токене. В операционной системе данный из токена включены в специальную структуру, которая называется Security Descriptor:

В качестве подопытного процесса возьмём процесс System. Для получения адреса токена можно ввести следующую команду dx @$cursession.Processes[4].KernelObject.Token

Токен хранится с использованием EXFAST_REF это означает, что нужно занулить последний байт, чтобы вычислить адрес токена:

Посмотрим полный список групп и привилегий у пользователя System:

Стоит обратить внимание на тот факт, что найти Security Descriptor можно за несколько шагов, которые представлены выше на снимке. Полный список информации о привилегиях и группах представлен ниже:

Исследуем, что будет, если мы модифицируем ссылку на токен из отладчика:

Из-за изменения токена на нулевой, произошёл BSOD. В Windows была возможность использовать нулевой токен, но всё закончилось на Windows 10 1607. Был имплементирован механизм, который вызывает BSOD, если ссылка на токен в Security Descriptor модифицируется. Анализ дампа показывает, что проблема в испорченном объекте:

А можем ли мы все таки произвести модификацию без BSOD? Попробуем модифицировать так, чтобы осталась возможность работать с ОС. Для проверки попробуем создать условия, при которых токен обычного пользователя включал максимальное количество привилегий:

1.Найдем системный процесс и выясним, какие привилегии у него включены:

2.Пройдем в токен cmd.exe просмотрим текущее значение на включенные права:

3.Модифицируем права. Список прав после модификации:

Модификация прошла успешно, но все равно пользователь не может аттачиться к ряду системных приложений. Из-за того, что у пользователя еще остались ограничения из-за Integrity Levels и дополнительных битов, которые запрещают взаимодействие с процессами.

А можно ли провести выставление конкретных прав у пользователя в дескрипторе? Попробуем определить. В официальной документации указываются только строковые приставления констант, попробуем переписать токен значениями: 0x1

BSOD не произошло, похоже что механизм защиты просматривает только случаи, когда испорчен заголовок объекта. Это хорошо, значит, можно брутить. Первое значение, которое показало какой-то вменяемый результат 0x100000.

В итоге перебора значений были получены следующие данные о константах в токене:

• SeDebugPrivilege - 0x100000

• SeAuditPrivilege - 0x200000

• SeSystemEnvironmentPrivilege - 0x400000

• SeCreatePermanentPrivilege - 0x010000

• SeSystemtimePrivilege - 0x001000

• SeSecurityPrivilege - 0x000100

• SeLockMemoryPrivilege - 0x000010

Получается, что хранимые привилегии это всего лишь байт в поле из 6 байт. И все действия, которые были проведены в отладчике, могут быть выполнены через shellcode, только нужно учитывать, что в эксперименте мы просто проставляли права как существующие, но для их полноценного использования их нужно еще включить. То есть записать привилегии по адресу SEPTOKEN_PRIVILEGES и _SEPTOKENPRIVILEGES+0x8.

Проведем следующий эксперимент отнимем привилегии у процесса System и посмотрим, сможем ли мы выполнить операции, которые требуют расширенных привилегий.

В качестве теста была запущена команда netstat -ab, команда успешно отработала. Почему так произошло? Ведь все данные из токена о привилегиях были удалены. Здесь стоит вспомнить, что в ОС Windows привилегии наследуются от группы к пользователю, поэтому пока пользователь System принадлежит группам из списка ниже, он сможет продолжать использовать свои привилегии:

Ну и напоследок, шелкод, который можно использовать в качестве payload для эксплойтов из прошлой статьи:

[BITS 64]start:mov r9, [gs:0x188]                ;KPROCESS/currentThreadmov r9, [r9+0x220]                ;EPROCESS смещение к KTHREADmov r8, [r9+0x3e8]                ;InheritedFromUniqueProcessId (cmd.exe PID)mov rax, r9                           loop1:  mov rax, [rax + 0x2f0]         sub rax, 0x2f0                    ;KPROCESS  cmp [rax + 0x2e8],r8              ;сравнить ProcessId  jne loop1                           mov rcx, rax                        ;если найден нужный PID EPROCESSadd rcx, 0x360                        mov rax, [rcx]                           and rax, 0xFFFFFFFFFFFFFFF0mov r8,  0x1e73deff20               ;System набор привилегийmov [rax+0x48],r8                   ;Перезапись привилегийret

Узнать подробнее о курсе "Пентест. Практика тестирования на проникновение".

Смотреть открытый вебинар на тему "Windows AD сбор информации, эскалация привилегий. Эксплойты и уязвимости последних 5ти лет."

ЗАБРАТЬ СКИДКУ

Большую часть своей жизни я жил и работал в Москве. Занимался тем, что менял здоровье на деньги. Правда, на очень хорошие, поэтому под занавес пятого десятка купил квартиру в тихом приморском городке, далеко от столичной суеты и ежедневной нервотрёпки.

Особой необходимости в работе у меня не было. Дети уже стали самостоятельными настолько, что запросто могут содержать нас с женой. Да и скопить удалось прилично. Однако, были три проблемы.

Работа в тихом городке

Во-первых до пенсии неплохо хоть где-то формально числиться. Во-вторых, без работы скучно. В-третьих, даже небольшие деньги лишними никогда не бывают.

Однако, в маленьком приморском городке работы для айтишника не было никакой, а ездить в областной центр мне совсем не хотелось. Так я стал ИП и занялся дистанционным обслуживанием компаний, которым было накладно содержать постоянного админа.

Буквально за пару недель я обзавёлся первыми клиентами небольшими компаниями-мелкооптовиками. В штате 10-50 работников, главбух на аутсорсе, сервер с 1С и одним общим для всех каталогом. Почту используют бесплатную, вопросами ИБ заморачиваются по минимуму. В-общем, достаточно типичный для нашей страны мелкий бизнес.

Иногда приходилось выезжать на место, но не часто. Большинство задач вполне решалось дистанционно либо через TeamViewer, либо по телефону. Меня это устраивало, клиентов тоже.

Токены головная боль

Например, надо срочно отправить счёт. Сотрудник вводит пароль, входит в Диадок, загружает документ Но подписать его не может его коллега вчера сунул ключ себе в карман, а сегодня не пришёл на работу, поскольку с утра поехал утрясать какие-то вопросы с партнёром. Приходится отгружать товар без оплаты. Это означает, что деньги придут с большой задержкой как известно, уже оказанная услуга услугой не считается.

Разумеется, меня в этом ни один заказчик не упрекал. Но почти все постоянно намекали, что было бы неплохо как-то раз и навсегда решить проблему с токенами техническими средствами, поскольку административными уже пытались, но безрезультатно.

Всё действительно сложно

Сначала задача показалась мне простой. Технология USB over IP существует достаточно давно все токены подключены к одному устройству, а сотрудники работают с ними, как с локальными. Ничего не теряется, поскольку не покидает пределов офиса.

Осталось полчасика погуглить, найти решение подешевле и предложить заказчикам. Но ни тут-то было. Поразмыслив, я пришёл к выводу, что такой проект значительно сложнее, чем казался.

Прежде всего я выяснил, сколько токенов используют мои заказчики. Оказалось, от двух до одиннадцати. Стало быть, нужно такое решение одного производителя, чтобы удовлетворить всех, причём с небольшим запасом.

Почему одного производителя? Потому что мудрый Оккам умножения сущностей не приветствовал от этого одни проблемы. Да и дешевле так выходит, как правило.

Поскольку айтишников на фултайме ни в одной конторе не было, самодельные и софтовые решения исключались. Делать, настраивать и чинить некому.

По масштабированию прекрасно подходят облака. Но цены у них откровенно кусаются. Например, сервис FlexiHub обойдётся заказчику более 10 тыс. рублей в месяц за 5 ключей, не считая стоимости хаба. И это без гарантий совместимости.

Но самое главное сервисы требуют регулярной своевременной оплаты. У небольшой компании с этим могут быть проблемы. У неё не всегда есть возможность даже зарплаты сотрудникам заплатить вовремя. Задержка в неделю-другую дело обыкновенное.

В-общем, нужна железка. Точнее, набор устройств с разным количеством портов. Как я писал выше: от двух до одиннадцати с небольшим запасом. Чтобы один раз купил и навсегда твоё.

Если ориентироваться на мировые бренды, то надо брать Digi AnywhereUSB. За 2 USB-порта больше 20 тыс. рублей, за 14 портов в районе 150 тыс. рублей. Для небольших компаний это явно дорого.

Конечная остановка USB over IP концентратор

Перебирая варианты я пришёл к отечественному аппаратно-программному решению DistKontrolUSB. На нём и остановился. Причин этому несколько.

Прежде всего цена. За концентратор на 4 порта мой мелкий клиент заплатит 26 тыс. рублей с хвостиком, а более крупным придётся выложить около 69 тыс. рублей, но за 16 портов. Дешевле западного аналога в два раза.

Второе достоинство отечественного разработчика знание российской специфики. Младшая версия концентратора на 4 порта имеет ограниченную функциональность. В ней отсутствует авторизации для подключения к токенам, нет ограничений доступа и управления питанием портов.

Такой подход разумен, поскольку в небольших организациях все ключи по сути являются общими достаточно одной авторизации для всего. На практике это означает, что даже если реализовать отдельный вход для каждого токена, то получится всего лишь замедление работы сотрудников на время дополнительной аутентификации. Да ещё и возникнет путаница в паролях, что рано или поздно всё равно закончится уменьшением количества пар логин-пароль до одной.

Что касается управления питанием портов, то при их небольшом количестве функция лишена смысла. Проще перезагрузить концентратор полностью. Или руками перевоткнуть зависший USB-ключ.

Таким образом, большинство моих клиентов, обходящихся 2-4 ключами, за относительно небольшую сумму получат надёжное устройство для дистанционной работы с токенами. Причём, без заведомо избыточной функциональности, за которую надо платить.

Третье достоинство удобное удалённое управление концентратором через веб-интерфейс. Это особенно важно для более крупных организаций, которым подойдёт концентратор на 16 портов. Сотрудников там больше и без каких-то элементов ИБ не обойтись.

Допустим, по соображением безопасности требуется ограничить доступ к порту по IP-адресу, а к ключу по логину и паролю. Через панель управления это делается мгновенно, причём в одном модуле. Надо всего два раза сдвинуть соответствующие ползунки и нажать на кнопу Сохранить. Изменения сразу вступят в силу.

Проблема нахождения концов актуальна не только для очень крупных организаций, но и для моих клиентов. При помощи системного журнала в WEB-интерфейсе Управляемого USB over IP концентратора решение этой задачи облегчается. В журнале хранится вся информация о подключениях и отключениях, включая логин пользователя и IP-адрес, с которого было осуществлено подключение. Кстати, пару раз пригодилось.

Раз уж дело дошло до практики, то вот ещё один пример. Хоть правило уходя гасите свет существует, но выполняется не всегда. Один мой заказчик опасался, что в ночное время какой-нибудь хакер взломает концентратор и наделает делов.

В настройках USB over IP концентратора было сформировано автоматическое задание, по которому устройство отключается в заданное время. А чтобы директор не волновался и спал спокойно он получает уведомление о выполнении на электронную почту.

Итоги

Проект по оптимизации работы с токенами я начал в январе этого года. Из семи предприятий, с которыми я работаю, три уже приобрели и успешно используют USB over IP концентраторы. В одной организации это запланировано на лето. Думаю, что и оставшиеся три до конца года примут положительное решение.

Тем более, что моя аргументация теперь основана не только на умозрительных аргументах, но и на практике эксплуатации. Поскольку теперь я что-то смыслю в торговле, то могу оперировать цифрами.

Например, дневная задержка в оплате счёта на один миллион стоит от 100 до 1000 рублей в зависимости от договора. С отчётностью ещё хуже 5% от суммы налога. А это уже несколько тысяч даже для небольшой фирмочки. Причём, только прямого ущерба о каких-то сорвавшихся сделках я даже не говорю.

Сумму убытков из-за подобных задержек владелец компании знает. Стоимость USB over IP концентратора тоже. Срок окупаемости вычисляется без всякой высшей математики.

Насколько я могу судить, первопроходцы уже ушли в плюс. Даже те, кто приобрёл устройство на 16 портов.

Внимательный читатель заметит, что я ничего не написал про стоимость обслуживания. Исправляюсь оно ничего не стоит. По крайней мере для моих клиентов, поскольку работы у меня не прибавилось.

Впрочем, вру. Мои клиенты уже начали рекомендовать меня своим знакомым. Я думаю, что по уровню заработка я тут потихоньку достигну своего бывшего московского уровня. Жалею, что не уехал из Москвы раньше.

В JavaScript мы часто используем сущности вроде window, navigator, requestAnimationFrame или location. Некоторые из этих объектов существуют испокон веков, некоторые часть вечно растущего набора Web API. Возможно, вы встречали класс Location или токен DOCUMENT в Angular. Давайте обсудим, для чего они нужны и чему мы можем у них научиться, чтобы сделать наш код чище и более гибким.

DOCUMENT

DOCUMENT это токен из общего пакета Angular. Вот как можно им воспользоваться. Вместо этого:

constructor(private readonly elementRef: ElementRef) {}get isFocused(): boolean {return document.activeElement === this.elementRef.nativeElement;}

Можно написать так:

constructor(@Inject(ElementRef) private readonly elementRef: ElementRef,@Inject(DOCUMENT) private readonly documentRef: Document,) {}get isFocused(): boolean {return this.documentRef.activeElement === this.elementRef.nativeElement;}

В первом примере мы обратились к глобальной переменной напрямую. Во втором внедрили ее как зависимость в конструктор.

Я не собираюсь бросаться в вас модными акронимами или утверждать, что первый пример нарушает тот или иной принцип программирования. По правде сказать, я в этой теории не сильно подкован.

Вместо этого я покажу, почему подход с токеном лучше. Начнем с того, что посмотрим, откуда берется этот токен. В его объявлении в @angular/common нет ничего особенного:

export const DOCUMENT = new InjectionToken<Document>('DocumentToken');

Внутри @angular/platform-browser, однако, мы видим, как он получает свое значение (пример упрощенный):

{provide: DOCUMENT, useValue: document}

Когда вы добавляете BrowserModule в app.browser.module.ts, вы регистрируете целую кучу имплементаций для токенов, таких как RendererFactory2, Sanitizer, EventManager и наш DOCUMENT. Почему так? Потому что Angular это кросс-платформенный фреймворк. Он оперирует абстракциями и активно использует механизм внедрения зависимостей для того, чтобы работать в браузере, на сервере и на мобильных устройствах. Чтобы разобраться, давайте заглянем в ServerModule ещё одну платформу, доступную из коробки (пример упрощенный):

{provide: DOCUMENT, useFactory: _document, deps: [Injector]},// ...function _document(injector: Injector) {const config = injector.get(INITIAL_CONFIG);const window = domino.createWindow(config.document, config.url);return window.document;}

Мы видим, что там используется domino для создания имитации документа на основе конфига, взятого из DI. Именно это вы получите, если запустите Angular Universal для рендеринга приложения на сервере. Мы уже видим первый и самый важный плюс данного подхода. Работа с DOCUMENT возможна в SSR-окружении, в то время как глобальный document в нем отсутствует.

Другие глобальные сущности

Что ж, команда Angular позаботилась о document для нас, это здорово. Но что, если мы хотим, например, проверить браузер через строку userAgent? Для этого мы обычно обращаемся к navigator.userAgent. На самом же деле это означает, что сначала мы запрашиваем глобальный объект, window в случае браузера, и потом берем его поле navigator. Так что давайте начнем с токена WINDOW. Его довольно просто реализовать благодаря фабрике, которую можно добавить к созданию токена:

export const WINDOW = new InjectionToken<Window>('An abstraction over global window object',{factory: () => inject(DOCUMENT).defaultView!},);

Этого достаточно, чтобы начать использовать WINDOW по аналогии с DOCUMENT. Теперь используем тот же подход для создания NAVIGATOR:

export const NAVIGATOR = new InjectionToken<Navigator>('An abstraction over window.navigator object',{factory: () => inject(WINDOW).navigator,},);

Мы шагнем дальше и сделаем отдельный токен под USER_AGENT тем же способом. Зачем? Увидим позже!

Иногда одного токена недостаточно. Location из Angular это, по сути, обертка над location для упрощения работы с ним. Поскольку мы привыкли к RxJS, давайте заменим requestAnimationFrame на реализацию в виде Observable:

export const ANIMATION_FRAME = new InjectionToken<Observable<DOMHighResTimeStamp>>('Shared Observable based on `window.requestAnimationFrame`',{factory: () => {const performanceRef = inject(PERFORMANCE);      return interval(0, animationFrameScheduler).pipe(map(() => performanceRef.now()),share(),);},},);

Мы пропустили создание PERFORMANCE, потому что оно следует той же модели. Теперь у нас есть один общий стрим, основанный на requestAnimationFrame, который можно использовать по всему приложению. После того как мы заменили всё на токены, наши компоненты больше не полагаются на волшебным образом доступные сущности и получают всё, от чего они зависят, из DI. Классно!

Server Side Rendering

Теперь, допустим, мы хотим написать window.matchMedia('(prefers-color-scheme: dark)').

Конечно, на сервере в нашем WINDOW что-то да есть, но оно, безусловно, не поддерживает весь API объекта Window. Если мы попробуем сделать данный вызов в SSR, скорее всего, получим ошибку undefined is not a function. Один способ решить проблему обернуть все подобные вызовы в проверку isPlatformBrowser, но это скукота. Преимущество DI в том, что значения можно переопределять. Так что вместо особой обработки таких случаев мы можем предоставить безопасный муляж WINDOW в app.server.module.ts, который защитит нас от несуществующих свойств.

Это демонстрирует еще одно достоинство данного подхода: значение токена можно менять. Благодаря этому тестировать код, зависящий от браузерного API, становится очень просто. Особенно если вы используете Jest, в котором нативный API по большей части отсутствует. Но муляж это просто заглушка. Иногда мы можем подложить что-то осмысленное. В SSR-окружении у нас есть объект запроса, который содержит данные о user agent. Для этого мы и вынесли его в отдельный токен иногда его можно заполучить отдельно. Вот как мы можем превратить запрос в провайдер:

function provideUserAgent(req: Request): ValueProvider {return {provide: USER_AGENT,useValue: req.headers['user-agent'],};}

А затем добавим его в server.ts, когда будем настраивать Angular Universal:

server.get('*', (req, res) => {res.render(indexHtml, {req,providers: [{provide: APP_BASE_HREF, useValue: req.baseUrl},provideUserAgent(req),],});});

Node.js так же имеет собственную имплементацию Performance, которую можно использовать на сервере:

{provide: PERFORMANCE,useFactory: performanceFactory,}// ...export function performanceFactory(): Performance {return require('perf_hooks').performance;}

Однако в случае requestAnimationFrame он нам не понадобится. Скорее всего, мы не хотим гонять наши Observable-цепочки впустую на сервере, так что просто подложим в DI EMPTY:

{provide: ANIMATION_FRAME,useValue: EMPTY,}

Следуя данной схеме, мы можем токенизировать все глобальные объекты в нашем приложении и предоставить замены для различных платформ, на которых мы его запускаем.

Подытожим

С таким подходом ваш код становится хорошо абстрагированным. Даже если вы не используете серверный рендеринг сейчас, возможно, он понадобится в будущем и вы будете к этому готовы. Кроме того, тестировать код гораздо легче, если все зависимости можно подменить. Мы создали крошечную библиотеку с токенами, которые используем сами:

Если вам требуется что-то, чего в ней еще нет, не стесняйтесь заводить issue на Гитхабе. Также у пакета есть напарник с версиями этих токенов под SSR:

Вы можете изучить этот проект по вселенной Rick and Morty от моего коллеги Игоря, чтобы увидеть это все в действии. Если вам в особенности интересен Angular Universal, прочитайте его статью о проблемах, с которыми он столкнулся, и как их решить.

Благодаря данному подходу наша библиотека Angular-компонентов Taiga UI без труда запустилась и под Angular Universal, и под Ionic. Надеюсь, что эти знания помогут и вам!