Техника сетевых атак

Говоря математическим языком, если f - функция шифрования, key - ключ, а value - шифруемые данные, то: f(value) ?^key® crypt, а F(crypt) ?^key® value, где F - функция дешифрования. Если key - challenge, а value - хеш пароля, то злоумышленник, перехватив challenge и crypt, сможет восстановить хеш - значение пароля! Но как все изменится, если key - хеш, а value - challenge! Тогда, чтобы из crypt извлечь challenge (а на кой его извлекать, когда оно и без того известно?!), необходимо знать ключ шифрования - хеш значение пароля, а его как раз и требуется найти. Причем, функция шифрования специально подобрана так, чтобы, зная исходный и зашифрованный текст (то есть challenge и crypt), вычислить ключ (key, он же хеш - значение пароля) было невозможно, иначе, чем прямым перебором.

Строго говоря, сервер также не в состоянии расшифровать ответ клиента, ибо не имеет никакого представления, каким ключом он был зашифрован. Но это и не нужно! Функция необратимого шифрования позволяет установить идентичность аргументов, но не позволяет узнать сами аргументы по значению функции. Математически это можно выразить так. Пусть f(x) ® y, f(x₁) ® y₁; тогда, очевидно если y -y₁, то и x - x₁. [156]

Описанная выше схема (именуемая «запрос-отклик») нечувствительная к перехвату канала связи (то есть перехват y не дает никакого представления о значении x), но критична к криптостойкости используемых алгоритмов хеширования и шифрования (а так же, разумеется, защищенности «хранилища» хеш-значений паролей).

Операционная система Windows NT 4.0 (Windows 2000) поддерживает один алгоритм шифрования и, по крайней мере, два алгоритма хеширования: хеш LAN Manager (далее просто LM-хеш), разработанный Microsoft для операционной системы IBM OS/2, а позже интегрированный в Windows 3.1, Windows 3.11 for Workgroups, Windows 95, Windows 98 и, собственно, свой «родной» NT-хеш.

В базе данных диспетчера учетных записей SAM (Security Account Manager) обычно хранятся оба хеш значения - как LM-хеш, так и NT-хеш, поэтому, клиент для аутентификации может посылать либо LM-хеш, либо NT-хеш, либо и тот и другой сразу. Но если поменять свой пароль из операционной системы, не поддерживающей NT-хеш, его значение в базе SAM аннулируется [157]! Теперь, для аутентификации клиент вынужден передавать LM-хеш, до тех пор, пока вновь не поменяет свой пароль из операционной системы поддерживающий оба типа хеш -значений одновременно. Поэтому большинство клиентов посылают и LM, и NT хеш, даже если требуется лишь один из них [158].

Алгоритм получения LM-хеша при ближайшем рассмотрении выглядит так: пароль, введенный пользователем, превращается в строку фиксированной длины, равной четырнадцати символам. Короткие пароли расширяются добавлением нулевых элементов, а длинные усекаются. Все символы из множества ‘a’-‘z’ переводятся в верхний регистр, и, полученная в результате этой операции, строка расчленяется на две независимые половинки, состоящие из семи символов. Каждая из них играет роль ключа для шифровки последовательности нулей алгоритмом DES. Затем, полученные строки дописываются друг к другу, образуя шестнадцати байтовый LM-хеш.

Алгоритм получения LM-хеша

Независимое хеширование половинок пароля, в 1 000 000 000 000 000 раз уменьшает количество попыток, требующихся для его перебора (а вовсе не в два раза, как это может показаться на первый взгляд). Это же какой талант надо иметь, чтобы допустить такой ляп! Уж сколько раз твердили миру (то бишь разработчикам) - не разводите самодеятельность, используйте проверенные временем алгоритмы, да только все не впрок.

Но эмоции эмоциями, а как все это звучит на языке математики? Путь f - некая хеш функция, а x_1…7y_8…14 - введенный пользователем пароль. Тогда LM-хеш будет равен f(x)+2⁶⁴*f(y), поскольку область допустимых значений функции f лежит в интервале целых неотрицательных чисел, не превышающих 2⁶⁴, то поиск подходящего пароля заключается в решении двух уравнений (где P - искомый пароль, а H значение LM-хеша):

1. DES(0) -^P1…7® H_1…8; [159]

2. DES(0) -^P8…14® H_9…16;

Какие существуют способы решения данных уравнений? Алгоритм DES специально разрабатывался так, чтобы, зная исходный (в данном случае строка нулей) и зашифрованный (в данном случае восемь байт хеш - значения) тексты, злоумышленник не мог эффективно вычислить ключ шифрования (искомый пароль). Обсуждение надежности функции DES выходит за рамки данной книги, поэтому все дальнейшие рассуждения исходят из того, что она достаточно криптостойка [160].