Защита привилегированных аккаунтов домена: охрана маркеров доступа

Остальные статьи цикла:

Защита привилегированных аккаунтов домена: безопасность парольных хэшей

Защита привилегированных аккаунтов домена: LM-хэши – Хорошие, Плохие, Ужасные

Защита привилегированных аккаунтов домена: удаление шифрованных паролей из памяти

Ранее я писал о рисках раскрытия парольных хэшей на скомпрометированной машине. Оказывается, существует и другой способ воспользоваться учетными данными на Windows-хосте, который очень походит на кражу хэшей с последующим их использованием в атаках передачи хэша. Этот способ эксплуатирует маркеры доступа Windows, которые в концепции чем-то напоминают неперсистентные куки. Они располагаются в памяти и, по существу, предоставляют функционал единой точки входа (single sign on), позволяющий любому процессу или потоку, связанному с пользователем, легко обращаться к атрибутам безопасности этого пользователя (в том числе видеть его привилегии и членство в группах).

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

Что такое маркеры доступа?

По словам Microsoft, в Windows до версии Vista (версии начиная с Vista также используют "фильтрованный" маркер для контроля учетных записей UAC, который, по сути, является первичным маркером без административных прав) существует два типа маркеров доступа:

"…существует два вида маркеров доступа: первичные и имперсонализирующие. Каждый процесс имеет первичный маркер доступа, который описывает контекст безопасности учетной записи пользователя, связанной с данным процессом. Обычно первичный маркер доступа назначается процессу, чтобы сообщить ему информацию, касающуюся безопасности. Имперсонализирующие маркеры, с другой стороны, обычно используются в клиент-серверных сценариях. Имперсонализирующие маркеры позволяют потоку запускаться в контексте безопасности, отличном от контекста безопасности процесса, владеющего этим потоком."

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

Чтобы увидеть, как можно использовать имперсонализацию, рассмотрим FTP-сервер, с которым вы соединяетесь под авторизованной учетной записью. Авторизованная учетная запись, вероятно, имеет права на загрузку и скачивание файлов только из определенных директорий. FTP-сервер узнает ваши права через имперсонализацию. Когда процесс FTP-сервера занят обслуживанием ваших запросов, он на короткое время выполняется под управлением вашего имперсонализирующего маркера, что дает ему "врожденное" знание ваших привилегий, то есть, того, к каким файлам и папкам вы имеете доступ. Когда он завершает обработку вашего запроса, то возвращается к своей работе под управлением своего первичного маркера или имперсонализирующего маркера другого пользователя.

Существует четыре уровня имперсонализации: анонимный, идентификация, имперсонализация и делегирование. В данном блоге TechNet дается описание этих уровней:

"Данные уровни влияют на то, что вы можете сделать с имперсонализирующим маркером, получив его. Анонимный характеризуется своим названием – мы можем представлять вас только как анонимного пользователя. Уровень идентификации – это когда процесс может получить ваш маркер для проверки учетных данных, но не может производить никаких действий над маркером. Уровень имперсонализации означает, что процесс может выполнять действия от имени другого пользователя… Имперсонализация ограничена только локальными для данного компьютера задачами… Процесс не может 'запустить задачу' или 'запросить объект', которые располагаются вне его системы… Делегация находится на шаг впереди имперсонализации: процесс может вызывать ресурсы и выполнять задачи на других компьютерах. …делегирование – это возможность, предоставляемая протоколом аутентификации Керберос, и часто называемая аутентификацией 'двойного прыжка' (double hop) – наши учетные данные перепрыгивают с одного компьютера на другой, освобождая нас от необходимости заходить на каждый из этих компьютеров отдельно."

На практике, с точки зрения атакующего, ценность имеют маркеры уровня имперсонализации и уровня делегирования, поскольку они позволяют коду выполняться в контексте безопасности иного пользователя.

Когда появляются эти маркеры доступа?

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

Маркеры уровня делегирования появляются при интерактивных входах, в том числе, входах с консоли, через RunAs, PsExec с опцией "-u" и при входах на удаленный рабочий стол RDP/VNC-вида. Я уже говорил о значительном риске раскрытия парольных хешей при интерактивном входе, поэтому нам определенно нужно избегать этого типа входа в систему под нашим привилегированным аккаунтом домена.

Маркеры уровня делегирования также могут появляться в результате сетевых входов в определенные сервисы, например, SharePoint. SharePoint, который часто использует веб-сервер как фронтенд и SQL-Server как бэкенд, является превосходным примером того, насколько полезным может быть делегирование. Она позволяет веб-серверу (фронтенду) после того, как клиент соединился с ним и прошел аутентификацию, соединяться с SQL-сервером от имени этого аутентифицированного клиента. Многозвенные решения такого типа – это обычный сценарий использования делегирования. Отметим также, что Шифрующая Файловая Система (EFS) Microsoft использует делегирование для шифрования и расшифрования файлов от имени пользователя.

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

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

А вот снимок экрана, показывающий, как в Active Directory можно включить делегирование для определенной учетной записи компьютера (всплывающее окно показалось после того, как я выбрал "Trust computer for delegation"):

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

Необходимые условия кражи маркеров безопасности

Итак, мы знаем, что должно произойти, чтобы маркеры уровня делегирования и имперсонализации были созданы и стали доступными для использования. Но что должно случиться, чтобы можно было ими завладеть и эксплуатировать их? Код атакующего должен быть запущен от имени пользователя, имеющего привилегию имперсонализации (SeImpersonatePrivilege). По умолчанию в Windows XP данным правом обладают администраторы, а также члены встроенной группы SERVICE:

Обычно на момент кражи маркеров доступа атакующий уже поднял привилегии до уровня Adminstrator/SYSTEM, так что данное условие редко представляет проблему.

Кража маркеров в действии

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

Я сконцентрируюсь на краже маркера уровня делегирования. Хотя, конечно, возможно украсть маркер уровня имперсонализации и использовать его для повышения локальных привилегий, в моем сценарии это не представляет интереса, поскольку я предполагаю, что атакующий уже имеет полный контроль над скомпрометированным хостом. Я также предполагаю, что для эффективного анализа данного хоста должна быть использована административная учетная запись, поэтому любой административный аккаунт будет аналогично уязвим к краже (только для локального использования) маркера уровня имперсонализации. Что я действительно хочу защитить, так это маркер уровня делегирования, который, если станет доступен, позволит атакующему аутентифицироваться на удаленных машинах от имени привилегированного аккаунта.

Для просмотра и кражи маркеров доступа я собираюсь использовать утилиту incognito, созданную Люком Дженнингсом. Точнее, в данных тестах я собираюсь использовать модуль Метасплоита incognito (также созданный Дженнингсом), поскольку я обнаружил, что он является более совместимым, чем приложение incognito. Статья Дженнингса "Security Implications of Windows Access Tokens — A Penetration Tester's Guide" – это прекрасный источник, позволяющий разобраться в данной проблеме и описывающий то, как работает incognito.

В нашем сценарии имеется потенциально скомпрометированная машина Windows XP SP2 с именем "USER-XP-PC". У нас также есть сотрудник службы реагирования на инциденты безопасности "MSAD2-RESPONDER1", которому нужно со своей машины "IR-XP-PC" соединиться со скомпрометированной машиной для анализа последней. В прошлой своей статье я тестировал утилиты NET USE, WMIC и PsExec. В данной же статье я сфокусируюсь только на PsExec, поскольку лишь она оказалась уязвимой по умолчанию к краже маркеров доступа уровня делегирования, если предположить, что скомпрометированный компьютер является доверенным для делегирования. Для WMIC делегирование можно включить путем указания ключа /IMPLEVEL.

Итак, давайте начнем!

• Здесь наш сотрудник посредством PsExec заходит с его машины (IR-XP-PC) на удаленную скомпрометированную машину USER-XP-PC:
  
• Атакующий запустил сессию Metasploit Meterpreter на удаленной машине USER-XP-PC. На этот момент он может полностью контролировать USER-XP-PC с консоли Metasploit своей машины, на которой установлена ОС BackTrack Linux. Здесь мы видим попытку атакующего украсть маркер уровня делегирования пользователя MSAD2-RESPONDER1.
  
• Теперь давайте посмотрим, что может сделать атакующий, когда действует от имени MSAD2-RESPONDER1. Вот продолжение сессии, показанной на предыдущем снимке:
  

Результаты показывают очень эффективный метод повышения привилегий с уровня стандартной учетной записи домена до уровня привилегированной доменной записи (в данном случае – администратора домена) и получения доступа к файлу резервной копии контроллера домена. Ксаба Барта в документе "Active Directory Offline Hash Dump and Forensic Analysis" указал, что файлы резервных копий часто содержат NTDIS.DIT и файлы реестра, необходимые для извлечения доменных хэшей. В более реалистичном сценарии (и, возможно, более простом) атакующий попытается заполучить упомянутые файлы с сервера резервных копий, используя учетную запись администратора резервных копий. В любом случае, мы видим, что кража маркеров уровня делегирования привилегированной учетной записи домена может иметь очень серьезные последствия.

Защита маркеров доступа

Теперь давайте посмотрим, что можно сделать для решения данной проблемы. К счастью, Microsoft предоставляет нам простой и эффективный способ защиты наших привилегированных учетных записей. Практически для всех привилегированных учетных записей домена вам следует включить опцию "Account is sensitive and cannot be delegated" в свойствах учетной записи:

Microsoft рекомендует этот способ как лучшую практику защиты важнейших учетных записей, что зафиксировано в данной статье TechNet про делегирование. Имейте в виду, что по рассмотренным выше причинам, вам, возможно, не захочется включать эту опцию для стандартных учетных записей домена, если вы используете многозвенные приложения вроде SharePoint. Однако, для учетных записей сотрудников службы безопасности, учетных записей администраторов домена и других учетных записей с высокими привилегиями включение данной опции не должно иметь вредных побочных эффектов, поскольку вряд ли вам понадобится обращаться из под этих учетных записей к многозвенным приложениям. Помните, однако, что удаленные операции с EFS требуют делегирования.

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

• Наш сотрудник службы безопасности опять заходит через PsExec со своей машины IR-XP-PC на удаленную скомпрометированную машину USER-XP-PC:
  
• Атакующий снова запускает сессию Metasploit Meterpreter, чтобы получить контроль над скомпрометированной машиной. Все последующие команды запускаются на скомпрометированном хосте USER-XP-PC с машины атакующего (ОС BackTrack Linux):
  
• Все выглядит так же, как в прошлый раз, но давайте посмотрим, можем ли мы теперь соединиться с контроллером домена как раньше, когда опция "Account is sensitive and cannot be delegated" была отключена.
  
• Не получается! Так что же произошло? Давайте посмотрим на логи контроллера домена, MSAD2-DC-2K3:
  

Мы видим попытку сетевого входа (Event ID 540) в 7:11:31 PM с рабочей станции USER-XP-PC. Это удачная попытка сетевого входа, но от имени анонимного пользователя, а не от имени MSAD2-RESPONDER1. Так происходит потому, что без маркера уровня делегирования в соединениях с удаленными рабочими станциями отсутствуют учетные данные. Эти соединения являются анонимными входами, которые хоть и аутентифицируются, но не авторизуются доменным контроллером. Другими словами, относительно наших ожиданий попытка входа оказалась неудачной.

Заключение

Мы получили важный результат. Включение опции "Account is sensitive and cannot be delegated" означает, что мы можем предотвратить ситуацию, когда маркеры доступа уровня делегирования станут доступны атакующему. В противном случае для атакующего существует явная возможность украсть маркер уровня делегирования, чтобы перемещаться по всей сети, а это может быть столь же опустошительным, как и компрометация хэшей привилегированной учетной записи.

Хотя данная опция исключает возможность украсть маркер уровня делегирования, маркер уровня имперсонализации все еще остается доступным атакующему. Как упоминалось ранее, это открывает уязвимость к локальному повышению привилегий на скомпрометированной машине. В нашем сценарии, однако, это не имеет большого значения, поскольку машина вероятнее всего уже была полностью скомпрометированна атакующим. Даже если машина еще не была полностью скомпрометирована, мы установили, что для эффективного анализа машины нам понадобятся права администратора. Поскольку любая учетная запись администратора (локальная или доменная) одинаково уязвима к локальному повышению привилегий, использование учетной записи администратора домена вместо аккаунта локального администратора не вносит дополнительного риска.

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