Приходилось ли вам когда-нибудь соединяться с потенциально скомпрометированной удаленной машиной, используя привилегированную учетную запись домена, и задумываться о том, существует ли у злоумышленника возможность узнать ваши учетные данные?
Приходилось ли вам когда-нибудь соединяться с потенциально скомпрометированной удаленной машиной, используя привилегированную учетную запись домена, и задумываться о том, существует ли у злоумышленника возможность узнать ваши учетные данные? Лично мне приходилось. Я размышлял и беспокоился по этому поводу, поэтому, в конце концов, движимый любопытством (и паранойей), стал исследовать атаки, направленные на учетные данные домена, и, в частности, их последствия для сотрудников службы реагирования на инциденты безопасности. Я несколько раз выступал с докладами по данной теме, а теперь (наконец-то) у меня появилось время, чтобы задокументировать мои находки. Это первая статья, которая станет частью цикла, посвященного данному вопросу.
По моему мнению, это весьма увлекательная тема, которая должна быть предметом интереса всего сообщества IR. Нужно предупредить, что данные статьи не предназначены для быстрого прочтения. Однако, если вы последуете за мной, вы, полагаю, не потратите время зря, поскольку точно будете знать, что вы можете и не можете безопасно делать со своей привилегированной учетной записью домена.
Итак, приступим!
Давайте начнем со сценария, представляющего собой худший, но все же реалистичный случай: в нашем домене есть вероятно скомпрометированная клиентская машина под управлением Windows XP Service Pack 2. Для оценки ущерба нам нужно провести анализ, во время которого она должна оставаться в сети.
Я назвал данный сценарий худшим случаем, потому что XP SP2 обладает множеством уязвимостей, которые позволяют атакующему относительно легко получить на хосте привилегии администратора (фактически, привилегии уровня SYSTEM), что дает вредоносным программам возможность отслеживать ваши учетные данные с системными полномочиями. Данный сценарий также назван реалистичным, так как большинство организаций все еще имеет в своей сети машины с Windows XP, и почти всегда найдется несколько систем, на которых по тем или иным причинам заплатки не устанавливаются должным образом.
Теперь, чтобы оценить ущерб и классифицировать эту потенциально скомпрометированную машину, нам нужно выполнить несколько задач:
Чтобы эффективно отреагировать на компьютерный инцидент, нам нужен административный доступ к скомпрометированной машине. Без него мы наверняка пропустим существенные признаки заражения. В этом случае не будет эффективного способа сделать образы памяти и дисков, получить полный список запущенных процессов, сетевых соединений и так далее, а, значит, вышеупомянутые инструменты будут мало полезны.
Учитывая все вышесказанное, позвольте сделать следующее замечание: во всех ситуациях, какие только приходят мне на ум, безопаснее всего использовать локальную учетную запись администратора (если вы знаете пароль от нее).
Если вы не знаете учетные данные локальной учетной записи администратора, вам придется использовать привилегированный аккаунт домена, чтобы получить доступ к целевой машине. В этом случае нужно предпринять меры предосторожности, чтобы гарантировать невозможность кражи учетных данных атакующим. Но какие меры? В доменной архитектуре Windows существует 4 основных компонента, требующих защиты:
В оставшейся части данной статьи мы обсудим хэши паролей и то, как мы можем защитить учетные записи наших доменов от угрозы похищения хэшей. Остальные защищаемые компоненты я рассмотрю в следующих статьях.
Процесс создания, хранения и аутентификации парольных хэшей дает компьютеру механизм для аутентификации учетной записи по паролю, представленному криптографически, а не в открытом тексте. Такое представление имеет очевидное преимущество в плане безопасности: пароль к учетной записи не будет храниться в системе открытым текстом. Однако, стойкость алгоритма хэширования пароля сильно связана с его эффективностью. К сожалению, 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:
Итак, мы заложили определенный фундамент для дальнейшего обуждения. В оставшейся части статьи я хочу сосредоточиться на том, что служба реагирования на инциденты должна знать для снижения риска раскрытия парольных хэшей, а затем привести в подтверждение результаты нескольких тестов.
Важно четко представлять, что делает парольные хэши аккаунтов домена доступными в системе и как они могут быть атакованы. Чтобы атакующий смог получить парольные хэши, должны выполняться оба следующих условия:
По моему мнению, тот факт, что для локального кэширования парольных хэшей требуется интерактивный вход, недостаточно документирован (или, по крайней мере, недостаточно опубликованы) и, таким образом, могут привести к некоторому замешательству. Однако, он документирован Microsoft здесь и здесь. В еще большей степени скрыт тот факт, что в результате сетевого входа парольные хэши домена не будут хранится на удаленной машине. Это очень важный факт, и я его вскоре продемонстрирую. Этот факт отражен в документе Гернана Окоа, описывающем его утилиту Windows Credentials Editor (см. страницу 25 этого документа).
Перед тем, как перейти к тестам, давайте поговорим о двух типах входа пользователя в систему – интерактивном и сетевом:
Это означает, что для того, чтобы парольные хэши домена хранились в памяти или на диске и, таким образом, стали доступны атакующему, сотрудник службы реагирования должен выполнить интерактивный вход на скомпрометированную машину. С другой стороны, если сотрудник выполнит не интерактивный, а сетевой вход, его хэши не будут подвержены риску.
Чтобы доказать это, давайте проведем несколько тестов…
Для данных тестов я настроил Windows Server 2003 на работу в качестве доменного контроллера для домена "MSAD2" и присоединил к домену две машины под управлением Windows XP.
В приведенных ниже тестах я собираюсь показать локальные интерактивные входы учетных записей жертв, удаленные сетевые входы под аккаунтом сотрудника службы реагирования, а затем результаты – выгрузки хэшей с машины жертвы.
Для демонстрации типов входа я использовал журналы событий Windows. Вам нужно знать, что тип 2 – это интерактивный вход, а тип 3 – сетевой. Типы входа описаны здесь. Существует также неплохая карта ссылок, доступная здесь.
Теперь давайте посмотрим, что происходит по команде RunAs, которая, как ранее было упомянуто, запускает интерактивный вход.
Отметим, что на показаном выше скриншоте процесс входа называется "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:
Теперь, когда два пользователя домена совершили интерактивный вход, а сотрудник службы реагирования соединился с целевой машиной удаленно через сетевой вход, давайте попробуем выгрузить хэши, хранящиеся на скомпрометированной машине.
Существует множество доступных утилит, которые выгружают хэши локальных аккаунтов из базы данных SAM, вроде pwdump, samdump и модуля Метасплоита hashdump. Однако, нам не интересны хэши локальных аккаунтов. Используемые нами инструменты должны иметь возможность обращаться к LM/NT хэшам доменных аккаунтов, хранящимся в памяти, и хэшам кэшированных учетных данных на диске. Я протестирую следующие два инструмента:
Между прочим, если вы захотите протестировать любые из перечисленных или другие утилиты для выгрузки хэшей, вы можете скачать многие из них с Openwall Project. Большинство утилит сопровождаются файлами README, которые описывают, что они собирают и как работают. Некоторые из этих инструментов трудно найти, так что данный ресурс может быть очень полезен.
Вот результаты выгрузки хэшей с нашей скомпрометированной машины, USER-XP-PC:
На показанном выше снимке экрана видно, что MSAD2-RESPONDER1 остается зарегистрированным в системе через NET USE и что удаленно запущенный процесс WMIC продолжает выполняться в фоне. Хотя я не смог показать это на скриншоте, сеанс входа PsExec также остается активным во время выгрузки хэшей.
Результаты показывают следующее:
Рассмотренные тесты показывают, какие хэши паролей могут быть и будут доступны на Windows-машине при интерактивном входе. Когда доступна подобная информация об обычных учетных записях пользователей, уже можно получить ощутимый ущерб, но если к атакующему попадут парольные хэши привилегированного аккаунта домена, это может обернуться полным разорением.
Сетевой вход в систему, выполняемый утилитами вроде NET USE, WMIC, и PsExec (без опции альтернативных учетных данных "-u") безопасен в плане защиты парольных хэшей. Более того, любой инструмент, который использует только сетевой вход, не приведет к появлению ваших хэшей на удаленной машине. Чтобы самостоятельно проверить интересующий вас инструмент, просто запустите его на удаленной тестовой машине и проверьте, что в журнале событий этой машины будет зафиксирован лишь вход типа 3.
С другой стороны, вы всегда должны избегать интерактивного входа под привилегированной учетной записью домена, чтобы не допустить генерации и хранения ваших парольных хэшей на скомпрометированной машине. Интерактивный вход имеет место всякий раз, когда вам предоставляется рабочий стол, входите ли вы через консоль или через удаленное соединение с помощью Remote Desktop, Citrix, Dameware, VNC или еще как-нибудь. Он также имеет место при использовании опции "-u" (альтернативных учетных данных) утилиты PsExec. Любой из таких интерактивных входов на скомпрометированную машину под привилегированной учетной записью может стать разрушительным для доменной среды.
Помните также, что независимо от того, находится ли скомпрометированный хост в соседней комнате или на другой стороне планеты, использование сетевого входа – единственный способ безопасного обращения к этому хосту с использованием доменных учетных данных. Существует множество инструментов оценки инцидентов, разработанных для локального взаимодействия с машиной. Я говорю в особенности о тех, которые, например, запускаются с USB-накопителей. В данной ситуации позаботьтесь о том, чтобы не использовать доменный аккаунт с высокими привилегиями для локального входа на машину (через CTRL-ALT-DEL или RunAs), иначе хэши этого привилегированного аккаунта будут подвергнуты значительному риску.