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

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

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

Автор: Mike Pilkington

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

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

Итак, приступим!

Сценарий

Давайте начнем со сценария, представляющего собой худший, но все же реалистичный случай: в нашем домене есть вероятно скомпрометированная клиентская машина под управлением Windows XP Service Pack 2. Для оценки ущерба нам нужно провести анализ, во время которого она должна оставаться в сети.

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

Теперь, чтобы оценить ущерб и классифицировать эту потенциально скомпрометированную машину, нам нужно выполнить несколько задач:

  • Запросить у машины информацию с помощью инструмента вроде WMIC:
    Существует множество данных системы, которые мы можем захотеть узнать, вроде списка запущенных процессов, установленных служб, вошедших в систему пользователей, уровней патчей и т. д. К счастью, у нас есть замечательные инструменты вроде WMIC, которые помогут в решении этой задачи. Чтобы узнать о WMIC больше, прочтите одну из нескольких выдающихся статей Эда Скудиса, касающихся данного инструмента.
  • Запустить на машине нужные процессы с помощью инструмента вроде PsExec:
    PsExec – инструмент от Microsoft Sysinternals, который предоставляет очень эффективный способ запуска других инструментов на удаленной машине. По этой причине он очень популярен в нашей работе, так что я бы хотел непременно упомянуть о нем. Тем не менее, нужно предупредить, что вы всегда должны избегать использования PsExec с альтернативными учетными данными, то есть указания командной опции "-u". Я рассмотрю риски, связанные с альтернативными учетными данными, ниже в данной статье, а также в следующей статье, посвященной PsExec.
  • Скопировать файлы на машину или с нее через команду NET USE:
    В итоге нам понадобится способ обмена файлами с целевой системой, так почему бы не создать сетевой диск для удаленной машины с помощью NET USE?

Требования

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

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

Если вы не знаете учетные данные локальной учетной записи администратора, вам придется использовать привилегированный аккаунт домена, чтобы получить доступ к целевой машине. В этом случае нужно предпринять меры предосторожности, чтобы гарантировать невозможность кражи учетных данных атакующим. Но какие меры? В доменной архитектуре Windows существует 4 основных компонента, требующих защиты:

  • Хэши паролей: метод хранения учетных данных на локальной системе
  • Маркеры (токены) доступа: "-ish" функциональность единого входа Windows
  • Зашифрованная память LSA: другая технология единого входа Windows
  • Сетевая аутентификация: протоколы для аутентификации на удаленных системах

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

Хэши паролей

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

В нашем сценарии нас интересует защита учетных данных аккаунта домена (а не учетных данных локального аккаунта). Пароли учетных записей домена, вводимые на хосте Windows, хранятся в трех формах: в виде LM (LanMan) хэшаNT-хэша, и хэша кэшированных учетных данных. В каждом случае хэши получаются по известным алгоритмам и являются относительно уникальным представлением вашего исходного пароля. Я говорю «относительно уникальным», потому что ни LM, ни NT хэши не используют соли. Соль добавляет уникальные данные к паролю перед его передачей в алгоритм хэширования так, чтобы, например, мой пароль "abc123" и ваш пароль "abc123" не имели одинакового хэш-значения. Это отсутствие соли является большой проблемой Windows, поскольку позволяет проводить атаки на основе предвычисленных радужных таблиц, которые очень эффективны для взлома хэшей паролей, особенно LM-хэшей из-за дополнительной слабости в алгоритме.

Данные хэши паролей Windows хранит и использует для аутентификации учетных записей. Так что, по существу, каждый бит парольных хэшей должен защищаться не меньше, чем реальные значения паролей. Если они не защищены, существуют очень эффективные атаки, которые приводят либо к раскрытию паролей пользователей (через оффлайновые методы взлома вроде радужных таблиц), либо (в случае NT и LM хэшей) к тому, что атакующий просто использует украденный хэш для прямой аутентификации на удаленных сетевых ресурсах. Атаки второго вида называются атаками «передачи хэша» и могут привести к разорению всей доменной среды, поскольку позволяют атакующим легко перемещаться по сети в роли аутентифицированного аккаунта, используя для успешной аутентификации лишь парольный хэш.

Хэши кэшированных учетных данных, с другой стороны, являются модификацией NT-хэшей и дают нам несколько большую степень защиты, поскольку включают соль (соль является именем пользователя, как описано здесь для систем, предшествующих Vista и здесь для систем, начиная с Vista). Они используются для аутентификации пользователей домена на локальной системе, когда контроллер домена недоступен. Поскольку они генерируются с солью, они, к счастью, неприменимы для атак передачи хэша. Однако, инструменты вроде Cain and Abel и John the Ripper могут взломать их в ходе оффлайн-атаки, поэтому нам хотелось бы выяснить, будут ли доступны атакующему хэшированные учетные данные.

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

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

Если вы хотите изучить данный предмет более глубоко, я также рекомендую две превосходные статьи из SANS Reading Room:

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

Требования к атакующему для получения хэшей аккаунтов домена

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

  1. Хэши должны присутствовать в скомпрометированной системе. Для локальных учетных записей пользователей это выполнено всегда, поскольку хэши локальных учетных записей хранятся в локальной базе данных SAM. В доменной среде все хэши аккаунтов домена будут храниться в Active Directory на контроллерах домена. Для серверов и рабочих станций домена (то есть, не-контроллерах домена), хэши паролей доменных аккаунтов могут храниться только на тех системах, где пользователь совершил интерактивный вход. Скоро мы обсудим интерактивный вход подробнее. При выполнении пользователем интерактивного входа в систему, парольный хэш аккаунта домена будет храниться на диске в форме хэша кэшированных учетных данных. Это имеет смысл, поскольку кэшированные учетные данные используются для аутентификации аккаунта домена, когда контроллер домена недоступен, и потому должны храниться на диске, чтобы быть доступными после перезагрузки. Кроме того, родные LM и NT хэши для аккаунта домена будут храниться в памяти, пока данный аккаунт активен. После выхода пользователя из системы они стираются из памяти.
  2. Атакующий должен иметь на скомпрометированной системе права администратора. Существует множество утилит для атаки, которые получают парольные хэши домена, но для получения их с запущенной системы всем утилитам требуются права администратора. Некоторым инструментам требуется возможность повышать привилегии до локального SYSTEM, чтобы обращаться к защищенным файлам реестра, а другие работают путем внедрения кода в запущенные процессы, используя привилегию "SeDebugPrivilege", которая по умолчанию выдается лишь администраторам. Данное требование, однако, оказывается довольно слабым препятствием, особенно для XP-систем. Существует множество атак, повышающих привилегии, которые позволяют атакующему получить административный доступ к системе (например, модуль "priv" Метепретера), так что, получение административного доступа ничуть не затруднит злоумышленника, даже если аккаунт жертвы не является локальным администратором системы.

По моему мнению, тот факт, что для локального кэширования парольных хэшей требуется интерактивный вход, недостаточно документирован (или, по крайней мере, недостаточно опубликованы) и, таким образом, могут привести к некоторому замешательству. Однако, он документирован Microsoft здесь и здесь. В еще большей степени скрыт тот факт, что в результате сетевого входа парольные хэши домена не будут хранится на удаленной машине. Это очень важный факт, и я его вскоре продемонстрирую. Этот факт отражен в документе Гернана Окоа, описывающем его утилиту Windows Credentials Editor (см. страницу 25 этого документа).

Перед тем, как перейти к тестам, давайте поговорим о двух типах входа пользователя в систему – интерактивном и сетевом:

  • Сетевой вход: Сетевой вход обычно выполняется при доступе к удаленной системе для обращения к общим файлам и принтерам и/или для межпроцессного взаимодействия. Как мы скоро увидим, примеры сетевого входа включают создание сетевых дисков, а также опрос машины через WMIC.
  • Интерактивный вход: Интерактивный вход обычно связан с сессией входа, которая представляет пользователю рабочий стол. Инициировать сессию можно физически путем взаимодействия с системой с консоли или виртуально через сеть с помощью терминальных сервисов (также известных как Удаленный Рабочий Стол) или сторонних приложений вроде Citrix, VNC, RAdminDameWare и т. д. Кроме того, существуют способы инициировать интерактивный вход, не задействуя рабочий стол. Например, команда RunAs, которая позволяет вам запускать определенную команду или приложение от имени другого пользователя, также использует интерактивный вход. Мы скоро увидим, что Windows считает это "вторичным входом", но, тем не менее, интерактивным.

Так что же это значит для нас?

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

Чтобы доказать это, давайте проведем несколько тестов…

Тестовая конфигурация

Для данных тестов я настроил Windows Server 2003 на работу в качестве доменного контроллера для домена "MSAD2" и присоединил к домену две машины под управлением Windows XP.

  • "USER-XP-PC" играет роль скомпрометированного хоста под управлением Windows XP Service Pack 2. Учетная запись пользователя "MSAD2-USER1" является основной учетной записью данной машины и членом домена MSAD2.
  • "IR-XP-PC" играет роль машины сотрудника службы реагирования, используемой пользователем "MSAD2-RESPONDER1", который является администратором домена MSAD2.

Тестирование: когда раскрываются хэши?

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

Для демонстрации типов входа я использовал журналы событий Windows. Вам нужно знать, что тип 2 – это интерактивный вход, а тип 3 – сетевой. Типы входа описаны здесь. Существует также неплохая карта ссылок, доступная здесь.

  • Пользователь домена "MSAD2-USER1" нажимает комбинацию клавиш CTRL-ALT-DEL на рабочей станции "USER-XP-PC", чтобы совершить локальный вход. Как показывает журнал событий, в результате происходит интерактивный вход (вход типа 2) в домен:

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

  • В данном тесте я открыл окно CMD на машине "USER-XP-PC" и открыл в командной строке второе окно CMD от имени пользователя "MSAD2-USER2" через RunAs:
  • Вот журнал событий, показывающий запуск процесса RunAs:
  • 3 записи спустя вы видите процесс интерактивного входа (тип 2) для пользователя "MSAD2-USER2":

Отметим, что на показаном выше скриншоте процесс входа называется "seclogon". Это вторичный вход, который описан в данной статье Microsoft TechNet. На самом деле это автоматически запускаемая служба, как показано ниже:

Теперь, когда на скомпрометированном хосте два пользователя осуществили интерактивный вход в систему, давайте удаленно используем наши утилиты из-под IR-аккаунта. С рабочей станции "IR-XP-PC" сотрудник службы реагирования "MSAD2-RESPONDER1" войдет на удаленную машину с помощью трех утилит: NET USE, WMIC, и PsExec:

Отметим, что здесь я не использую альтернативные учетные данные для PsExec. Данная возможность позволяет указать альтернативное имя пользователя в опции "-u" для соединения с удаленной машиной. Оказывается, что при использовании этой возможности PsExec на самом деле производит два входа в систему – сначала сетевой вход для запуска службы PsExec, а затем вторичный интерактивный вход. Одно из назначений второго интерактивного входа состоит в "делегировании", то есть, в том, чтобы пользователь получил полные учетные данные и смог осуществить вход на третьей машине. Вдобавок, PsExec передает альтернативные имя пользователя и пароль по сети открытым текстом. Поэтому, что бы вы ни делали, не передавайте PsExec альтернативные учетные данные через опцию "-u". Скоро я опубликую статью, описывающую PsExec более подробно. Я также гораздо подробнее рассмотрю делегирование в паре статей, посвященных маркерам доступа.

Когда я перечислил 3 действия, которые мы хотели бы совершать с удаленной машиной (копировать файлы, запрашивать информацию и запускать процессы), я сказал, что для запроса информации вроде списка запущенных процессов или вошедших в систему пользователей я бы использовал WMIC. Для данного теста, однако, я хотел выполнить задачу, которая не была бы кратковременной, а оставалась активной во время попыток кражи хэшей. Для этого я использовал возможность WMIC "process call create", чтобы непрерывно пинговать целевую машину в фоне. Если безопасным окажется запуск непрерывного процесса, то и единичный запрос будет безопасным (и, на самом деле, я также протестировал сценарий простого запроса с помощью команды "wmic /node:[remote-PC] computersystem get username", получив те же результаты, что показаны ниже).

Итак, каким же будет результат запуска вышеуказанных команд на нашем скомпрометированном хосте? Посмотрим на следующие записи журнала событий Windows:

  • Команда NET USE выполнила следующий сетевой вход (тип 3):
  • Запуск WMIC генерирует следующие события: "MSAD2-RESPONDER1" выполняет сетевой вход (тип 3), а затем стартует процесс WMI Provider Service (wmiprvse), который запускает ping.exe с идентификатором процесса 1996:
  • Наконец, PsExec приводит к созданию нескольких записей в журнале – сначала появляется запись о сетевом входе, а затем происходит ряд событий, связанных со стартом службы PsExec и запуском данной службой запрошенной команды (в данном случае – cmd.exe):

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

Существует множество доступных утилит, которые выгружают хэши локальных аккаунтов из базы данных SAM, вроде pwdumpsamdump и модуля Метасплоита hashdump. Однако, нам не интересны хэши локальных аккаунтов. Используемые нами инструменты должны иметь возможность обращаться к LM/NT хэшам доменных аккаунтов, хранящимся в памяти, и хэшам кэшированных учетных данных на диске. Я протестирую следующие два инструмента:

  • Windows Credentials Editor (WCE), который может получать из памяти хэши паролей для текущих сеансов интерактивного входа. Это очень мощный и универсальный инструмент, написанный Германом Окоа и основанный на утилите Pass-the-Hash Toolkit того же автора. Получить данные хэши из памяти также можно с помощью утилиты Gsecdump.
  • Cachedump, который позволяет извлекать хэши кэшированных учетных данных пользователей домена из реестра. К той же категории относятся такие инструменты, как, например, creddump и Cain and Abel. Напомню, что хэш кэшированных учетных данных является модифицированной формой NT-хэша, который сгенерирован с использованием соли. Он не может быть использован в атаках передачи хэша, но может быть взломан оффлайн, особенно в случае слабого пароля.

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

Вот результаты выгрузки хэшей с нашей скомпрометированной машины, USER-XP-PC:

На показанном выше снимке экрана видно, что MSAD2-RESPONDER1 остается зарегистрированным в системе через NET USE и что удаленно запущенный процесс WMIC продолжает выполняться в фоне. Хотя я не смог показать это на скриншоте, сеанс входа PsExec также остается активным во время выгрузки хэшей.

Результаты показывают следующее:

  • Для доменных пользователей "MSAD2-USER1" и "MSAD2-USER2", которые осуществили интерактивный вход, в памяти хранятся их LM и NT хэши, а на диске хранятся хэши их кэшированных учетных данных
  • Хэши кэшированных учетных данных доменного пользователя "MSAD2-USER4", который входил в систему ранее, но в момент выгрузки уже не был в ней зарегистрирован, хранятся на диске.
  • LM и NT хэши локальной учетной записи администратора хранятся в памяти, поскольку для этого пользователя я открыл командное окно RunAs. Кэшированные учетные данные этого аккаунта недоступны, поскольку это не доменный аккаунт.
  • Важнее всего то, что для доменного пользователя "MSAD2-RESPONDER1", который выполнил удаленный сетевой вход, не хранится ни LM/NT хэшей в памяти, ни хэшей кэшированных учетных данных на диске.

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

Рекомендации по защите парольных хэшей

Сетевой вход в систему, выполняемый утилитами вроде NET USE, WMIC, и PsExec (без опции альтернативных учетных данных "-u") безопасен в плане защиты парольных хэшей. Более того, любой инструмент, который использует только сетевой вход, не приведет к появлению ваших хэшей на удаленной машине. Чтобы самостоятельно проверить интересующий вас инструмент, просто запустите его на удаленной тестовой машине и проверьте, что в журнале событий этой машины будет зафиксирован лишь вход типа 3.

С другой стороны, вы всегда должны избегать интерактивного входа под привилегированной учетной записью домена, чтобы не допустить генерации и хранения ваших парольных хэшей на скомпрометированной машине. Интерактивный вход имеет место всякий раз, когда вам предоставляется рабочий стол, входите ли вы через консоль или через удаленное соединение с помощью Remote Desktop, Citrix, Dameware, VNC или еще как-нибудь. Он также имеет место при использовании опции "-u" (альтернативных учетных данных) утилиты PsExec. Любой из таких интерактивных входов на скомпрометированную машину под привилегированной учетной записью может стать разрушительным для доменной среды.

Помните также, что независимо от того, находится ли скомпрометированный хост в соседней комнате или на другой стороне планеты, использование сетевого входа – единственный способ безопасного обращения к этому хосту с использованием доменных учетных данных. Существует множество инструментов оценки инцидентов, разработанных для локального взаимодействия с машиной. Я говорю в особенности о тех, которые, например, запускаются с USB-накопителей. В данной ситуации позаботьтесь о том, чтобы не использовать доменный аккаунт с высокими привилегиями для локального входа на машину (через CTRL-ALT-DEL или RunAs), иначе хэши этого привилегированного аккаунта будут подвергнуты значительному риску.

Ваша приватность умирает красиво, но мы можем спасти её.

Присоединяйтесь к нам!