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

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

Это третья статья из цикла "Защита привилегированных аккаунтов домена". Моя главная цель – помочь сотрудникам службы реагирования на инциденты безопасности (IR) защитить их привилегированные аккаунты при взаимодействии со скомпрометированными хостами, однако я полагаю, что эта информация будет полезна и всем тем, кто администрирует и защищает системы Windows.

Автор: Mike Pilkington

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

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

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

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

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

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

Шифрованные пароли в памяти… вы серьезно?

Именно так. Оказывается, что по умолчанию при интерактивных входах в систему в память загружаются зашифрованные пользовательские пароли. Это делается с целью обеспечить единой точкой входа (single sign-on, SSO) те сервисы, которые не поддерживают нативных протоколов сетевой аутентификации (т. е. Kerberos, NTLM/LM вызов-ответ). Чтобы аутентифицировать вас в данных службах, Microsoft сохраняет в памяти зашифрованную версию вашего пароля.

Если сейчас вы размышляете о том, есть ли какая-либо действительная разница между зашифрованным паролем в памяти и парольным хэшем в памяти, то отвечу вам: определенно есть. Хэш считается однонаправленной функцией, то есть, как только данные прошли через алгоритм хэширования, вы не можете восстановить исходные данные, зная результат (получить пароль). Шифрование, с другой стороны, обратимо, то есть, позволяет провести расшифрование. Поэтому, раз в памяти содержится зашифрованная версия вашего пароля, существует и способ расшифровать пароль. Это не сулит ничего хорошего. Мы уже знаем, что взлом LM-хэша – тривиальная задача, что делает LM-хэш эквивалентом обычного пароля – и в этом тоже нет ничего хорошего. Но, если вы установите пароль длиной более 15 символов, вычислить LM-хэш будет невозможно: будет доступен лишь NT-хэш, а NT-хэш сильного пароля взломать гораздо труднее, как и должно быть на самом деле.

Получение пароля

Эта проблема относительно нова – или, по меньшей мере, была малоизвестна до недавнего времени. Лишь несколько недель назад в блоге pentestmonkey появилось множество случаев описания данной проблемы в связи с утилитой mimikatz. (Я должен поблагодарить Эда Скудиса за то, что он обратил на это мое внимание… спасибо, Эд!). Позднее Тим Томс опубликовал на PaulDotCom интересную статью, показывающую, как использовать mimikatz в связке с Метасплоит. Я полагаю, что не придется долго ждать и соответствующего модуля Метерпретера. Однако, до данных статей мало кто знал о проблеме.

По-видимому, проблему обнаружил разработчик утилиты mimikatz. Он известен под ником "Gentil Kiwi" (я не смог найти его настоящее имя) и проживает во Франции. Его статьи (+ Google Translate) дают хороший обзор проблемы и в общих чертах описывают, каким образом его утилита получает пароли открытым текстом.

Его первый блог по данной теме был остроумно назван "Pass the pass(word)". В блоге он обсуждает то, что системы Windows версии Vista и выше включают в себя поставщик поддержки безопасности (SSP) для терминальных служб – TsPkg, который дает функционал единого входа для терминальных серверов. Здесь рассматривается, как эта опция может быть добавлена и в Windows XP SP3. Более того, данная статья с TechNet показывает, как включить эту опцию SSO для определенных терминальных серверов через GPO. Однако, как в своем блоге заметил автор утилиты и как подтверждает мое тестирование, Windows по-прежнему хранит пароли в памяти независимо от того, "включена" ли данная опция через GPO или нет. Другими словами, по умолчанию она всегда включена.

Несколько недель спустя автор mimikatz опубликовал новую статью с заголовком "Re-pass the pass(word)", в которой он рассматривал другой SSP, предоставляющий подобную возможность единого входа – WDigest. На данный момент он доступен не только в Windows Vista и выше, но также и в Windows XP и Server 2003!

WDigest предоставляет механизм "аутентификации по дайджесту". Это расширение HTTP, задокументированное в RFC 2069, а позднее и в RFC 2617. Аутентификация по дайджесту является более совершенной, чем базовая аутентификация, в ходе которой учетные данные посылаются открытым текстом. WDidgest реализует RFC 2617, равно как и RFC 2831, который описывает более общий механизм аутентификации (применимый не только для HTTP), называемый Простым Слоем Аутентификации и Безопасности (Simple Authentication and Security Layer , SASL). Общая идея здесь в том, что упомянутые спецификации описывают вызов-ответную аутентификацию, в которой отвечающая сторона в ответ на вызов посылает сообщение, сформированное с помощью хэш-функции, принимающей на вход пароль открытым текстом. Статья Википедии, посвященная аутентификации по дайджесту, очень интересна, и в ней выделено несколько проблем этого способа аутентификации. Одна из них - то, что сервер, использующий данную схему, для проверки ответа может хранить пароли клиента открытым текстом. Тем не менее, нас больше беспокоит клиент, которому приходится хранить пароль в открытом виде, чтобы ответить на вызов сервера.

Поэтому в каждом случае SSP хранит пароль в "зашифрованной" форме. Шифрование реализовано с помощью стандартных функций Win32 LsaProtectMemory и LsaUnprotectMemory, которые "шифруют/расшифровывают" заданный буфер памяти. Утилита mimikatz может вытаскивать шифрованные учетные данные из памяти и просто расшифровывать их с помощью функции LsaUnprotectMemory, выводя исходные пароли на консоль.

Тестирование

Давайте посмотрим на все это в действии. Сначала взглянем на поставщиков поддержки безопасности по умолчанию.

  • Вот настройки по умолчанию в Windows 7:
  • А вот они же в Windows XP:

Теперь запустим утилиту mimikatz и посмотрим, что она выдает.

  • В данном тесте MSAD2-RESPONDER2 выполнил интерактивный вход на консоли, в то время как MSAD2-RESPONDER1 выполнил интерактивный вход посредством RunAs.

Утилита работает так, как заявлялось. Она выдает пароли открытым текстом для интерактивно вошедших аккаунтов. Отметим, что она также выдает значения LM и NT (aka NTLM) хэшей, хотя в случае MSAD2-RESPONDER2 из-за большой длины пароля LM-хэш отсутствует.

Так что же мы можем сделать для отключения этой "опции"? Мы можем просто удалить этих поставщиков поддержки безопасности из куста реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

  • На своей машине под управлением Windows 7 я удалил WDigest и TsPkg и перезагрузился:
  • Теперь давайте запустим утилиту снова и посмотрим, что она выдаст:

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

Заключение

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

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

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

На сегодня все. В следующий раз – маркеры доступа!

Устали от того, что Интернет знает о вас все?

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