ТЕХНИКА СЕТЕВЫХ АТАК - Крис Касперский

Клиент, в отклик, посылает сообщение SMB_SESSION_SETUP_ANDX, содержащее пользовательское имя (открытым текстом); открытый пароль или challenge, зашифрованный хеш - значением пароля.

Сервер извлекает из базы данных (в просторечии «файла паролей») оригинальный хеш пароля данного пользователя, шифрует им challenge и сравнивает полученный результат с откликом клиента. Если они совпадают - хорошо, а нет - invalid user.

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

Говоря математическим языком, если 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(x1) ® y1; тогда, очевидно если y -y1, то и x - x1. [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-хеш.

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

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

1. DES(0) - P 1…7® H1…8; [159]

2. DES(0) - P 8…14® H9…16;

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

Но алгоритм DES нестоек к перебору! Он не требует больших объемов вычислений и допускает существование эффективных реализаций. В среднем случае злоумышленнику потребуется 1+k+k2+k3+k4+k5+k6+k7 операций [161] для подбора пароля, где k максимально допустимое количество символов, использующихся для составления пароля [162]. Это намного меньше ожидаемого количества операций, необходимых для подбора четырнадцати символьного пароля!

1+k+k2+k3+k4+k5+k6+k7 «(1+k+k2+k3+k4+k5+k6+k7++k8+k9+k10+k11+k12+k13+k14)*1/2, где знак “«” обозначает «намного меньше». И пароль, состоящий из восьми и более символов, окажется ничуть не сложнее пароля, состоящего всего из семи символов! Фактически система запрашивает два семисимвольных пароля и обрабатывает их независимо друг от друга [163].

Причем, пароли, состоящие менее чем из восьми символов, легко распознать! Если пароль, введенный пользователем, оказывается меньше четырнадцати символов, то система расширяет его до требуемой длины нулями. Пусть пользователь ввел пароль из семи или менее символов, тогда P8…14 = 0, а DES(0) - P 8…14® 0xAAD3B435B5140EE - однако, константа! (А, разработчики, однако, чукчи).

Поэтому, если старшие восемь байт LM-хеша равны 0xAAD3B435B5140EE, то исходный пароль состоит из семи или менее символов. Впрочем, на результаты поиска это не оказывает сильного влияния (дальше будет объяснено почему).

Если оптимизировать алгоритм, то скорость перебора можно увеличить вдвое! В самом деле, совершенно ни к чему дважды вычислять значение функции DES в уравнении 1 и в уравнении 2, поскольку области определения обеих функций одинаковы. Следовательно, для каждого P достаточно один раз вычислить значение DES(0) и поочередно сравнить его с H1…8; и с H9…16. Если пренебречь временем, затраченным на сравнение значения функции с H1…8 и H9…16 (а их для ускорения можно поместить в один 16-разрядный регистр), то скорость перебора возрастет вдвое!

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

Поскольку хеш представляет собой 16-байтовую строку, то всего возможно 2128 комбинаций, то есть перебор потребует нереальных вычислительных мощностей, недоступных злоумышленнику. Даже для современных суперкомпьютеров эта задача слишком сложна. Если, конечно, реализация алгоритма DES свободна от ошибок [164].

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

К шестнадцатибайтовому хеш - значению дописываются пять нулей, образуя последовательность из двадцати одного байта (16+5=21) обозначенную в этой книге как h1…21.

Эта последовательность разрезается на три равных части по семь байт, обозначенные h1…7, h8…14, h15…21.