Чудеса аутентификации. Чудо первое: доступ разрешён

Как-то раз я поспорил с одним коллегой о том, каким образом ОС Windows хэширует пароли, а именно: солит она их или нет. Коллега, будучи весьма опытным человеком, с абсолютной уверенностью утверждал, что хэш пароля просто обязан быть солёным. Его уверенность базировалась на теории о том, что без применения соли данные по хэшу легко вскрываются атакой со словарём. Вот только эта теория никак не могла объяснить такую странность: 

• есть 2 хоста, не включённых в домен, – AliceHost и BobHost;
• на обоих хостах есть одноимённые пользователи с одинаковыми паролями: AliceHost\user и BobHost\user;
• на хосте AliceHost есть сетевая папка \\AliceHost\Folder, доступ к которой предоставлен только пользователю AliceHost\user;
• если на хосте BobHost осуществить вход пользователем BobHost\user, то вы легко получите доступ к папке \\AliceHost\Folder.

Хэши
Очевидно, что подобный трюк возможен лишь в 2-ух случаях:

• пароль хранится открытым текстом или кэшируется в сессии,
• хэши паролей на обоих хостах совпадают.

Первый вариант можно даже не рассматривать, как совершенно абсурдный. Реальность гораздо проще: ОС Windows действительно не осуществляет никаких модификаций пароля перед хэшированием. Поэтому на разных хостах для одного и того же пароля мы будем иметь один и тот же хэш. Если быть точнее, то хэша может быть два: LM хэш и NT хэш.

Для вычисления LM хэша применяется алгоритм DES, при этом хэшируются только первые 14 символов пароля, преобразованные к верхнему регистру. Этот хэш был разработан для очень старых версий ОС Windows. Его криптографическая надёжность не выдерживает никакой критики, на современных системах он отключен в конфигурации по умолчанию (Windows Vista и выше), включать и использовать не рекомендуется и здесь более упоминаться не будет.
NT хэш гораздо проще и надёжнее. Он представляет собой MD4 хэш над паролем, преобразованным в Unicode строку. Максимальная длина пароля – 128 символов. NT хэш в отличие от LM хэша чувствителен к регистру символов. Длина обоих хэшей равна 16 байтам.

Протоколы
Основными протоколами сетевой аутентификации в ОС Windows являются: Kerberos, NTLMv1 и NTLMv2. Протокол Kerberos применяется только для аутентификации в домене Active Directory. Он является международным стандартом и достаточно хорошо описан. Здесь я его рассматривать не буду.

Протокол NTLM является закрытым протоколом компании Microsoft, вся имеющаяся о нём информация была получена методом reverse engineering`а. Он применяется практически всегда, когда не возможно использование протокола Kerberos, например, вне домена Active Directory. Впервые данный протокол появился в Windows NT 3.5. Первая версия протокола используется до сих пор и сейчас известна под названием NTLMv1. Аутентификация выполняется следующим образом:

1. Клиент отправляет серверу запрос на аутентификацию.
2. В ответ на запрос сервер отвечает случайным 8-байтным числом – server challenge.
3. Клиент берёт 16-байтный NT хэш пароля, дополняет его нулями до 21-ого байта и полученную последовательность разбивает на 3 части по 7 байтов. Каждая из этих частей используется как ключ для независимого шифрования ответа сервера алгоритмом DES. Три полученных шифрованных последовательности соединяются в одно 24-байтное значение, которое отправляется серверу.
4. Сервер выполняет аналогичное преобразование своего ответа, используя свою версию NT хэша. Если полученное значение совпадает с ответом клиента, то аутентификация считается успешной.

Одного этого описания уже достаточно, чтобы объяснить парадокс, приведённый в начале этой заметки: вне домена Active Directory хост BobHost имеет всю необходимую информацию, чтобы осуществить аутентификацию пользователем user на хосте AliceHost по протоколу NTLM.

Протокол NTLMv2 доступен опционально, начиная с версии ОС Windows NT 4 SP4. Начиная с Windows Vista, он является основным и включен в конфигурации по умолчанию – это означает, что данные операционные системы по умолчанию более не посылают запросов и откликов по протоколу NTLMv1. Данная версия протокола сложнее и надёжнее. Её можно описать следующим образом:

1. Клиент отправляет серверу запрос на аутентификацию.
2. В ответ на запрос сервер отвечает случайным 8-байтным числом – server challenge.
3. Клиент берёт NT хэш пароля, дополняет его именами пользователя и домена и вычисляет для этих идентификационных данных HMAC-MD5 хэш. Затем он генерирует 8-байтное случайное число (client challenge). Эта информация будет использоваться для формирования 2-ух частей ответа.
4. Первая часть ответа включает хэш идентификационных данных, полученных на шаге 3, server challenge и client challenge. Эти данные хэшируются алгоритмом HMAC-MD5, после чего клиент приписывает к ним client challenge в открытом виде (это необходимо, что сервер мог выполнить проверку).
5. Вторая часть ответа включает хэш идентификационных данных, server challenge и client challenge 2. Как и в случае первой части данные хэшируются алгоритмом HMAC-MD5, после чего в конец дописывается client challenge 2 в открытом виде. В свою очередь client challenge 2 содержит следующие данные: фиксированный заголовок, текущее время, client challenge и имя домена.
6. Обе части отправляются серверу.
7. Сервер формирует аналогичные хэши, используя свою версию NT хэша пароля пользователя, имена пользователя и домена и переданные в открытом виде client challenge и client challenge 2. Если полученное значение совпадает с ответом клиента, то аутентификация считается успешной.

Продолжение следует...