Илья Медведовский - Атака на Internet

3. Скорость перебора паролей в 15 раз больше, чем в UNIX, и достигает 190 000 паролей/с на Pentium 166.

4. Нет элемента случайности (привязки (salt), как это сделано в crypt()) – два пользователя с одинаковыми паролями всегда будут иметь одинаковые значения хэш-функции. Таким образом, можно заранее составить словарь хэшированных паролей и осуществлять поиск неизвестного пароля. Это позволит увеличить скорость перебора на несколько порядков.

Итак, хэш-функция, разработанная на базе того же самого алгоритма DES, но на 10–15 лет позже функции crypt(), оказывается хуже последней по всем параметрам, а именно:

• по мощности перебора для гарантированного подбора пароля – почти в 1 000 раз;

• по скорости перебора – почти в 15 раз;

• по отсутствию случайности, что приводит к уменьшению требуемой памяти для хэширования каждого пароля, – в 4 096 раз.

Не удивительно, что фирме Microsoft пришлось разрабатывать более криптостойкую функцию (точнее, не изобретать велосипед, который мог оказаться с квадратными колесами, а воспользоваться готовым образцом).

Хэш Windows NT вычисляется следующим образом.

1. Пароль длиной до 128 символов преобразуется в строку в кодировке Unicode, при этом сохраняются разные регистры.

2. Эта строка хэшируется с помощью MD4, что дает в результате 16-байтовое значение хэш-функции.

Хэш Windows NT обладает преимуществом по сравнению с функцией хэша Lan Manager – различаются регистры, пароли могут быть длиннее 14 символов, для хэширования используется весь пароль в целом, а не его части, хотя по-прежнему отсутствует элемент индивидуальности. Таким образом, люди, имеющие одинаковые пароли, всегда будут иметь одинаковые хэш-значения.

Удаленная аутентификация

Механизм удаленной регистрации на сервере (надо отдать должное разработчикам Windows NT) более надежен тем, что ни пароль пользователя, ни его хэш не передаются по сети в открытом виде (по крайней мере, в последних диалектах SMB). Впрочем, это не оригинальная находка Microsoft, а стандартный механизм большинства систем клиент – сервер, если связь между ними осуществляется по небезопасным каналам.

Функционирует механизм удаленной аутентификации, называемый «запрос-отклик», таким образом:

1. Клиент выдает команду на подключение к серверу.

2. Сервер либо возвращает пакет, в котором присутствует флаг, требующий от клиента передавать пароль в открытом виде (то есть сервер не поддерживает последние диалекты SMB), либо возвращает 8-байтовый случайный запрос (chаllenge). Далее рассматривается только последний вариант.

3. Клиент вычисляет LM-хэш введенного пароля, добавляет к нему пять нулей, получая таким образом 21-байтовую строку. Далее он делит ее на три 7-байтовых части, каждая из которых используется как отдельный ключ в алгоритме DES, – на этих ключах независимо три раза зашифровывается полученный запрос, что приводит к появлению 24-разрядного шифрованного значения. Поскольку клиент не знает, значения каких хэш-функций определены для данного пользователя в базе данных SAM на сервере, то он поступает аналогично и с хэш-функцией Windows NT. Таким образом, длина отклика клиента достигает 48 байт.

4. Сервер ищет то значение хэш-функции в своей базе данных SAM, которое присуще данному пользователю, аналогично шифрует запрос с его помощью и сравнивает с нужной половиной полученного отклика. Если значения совпадают, аутентификация считается состоявшейся.

Из сказанного можно сделать следующие выводы:

1. Все-таки есть возможность передачи пароля открытым текстом. Соответственно, используя механизм ложного сервера, можно заставить клиента передавать незашифрованные пароли.

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

3. При этом взломщик не получит это хэш-значение, непосредственно перехватив один или более сеансов подключения к серверу, потому что оно используется как ключ шифрования. Итак, самый реальный способ для злоумышленника – извлечение хэша непосредственно из базы данных на сервере.

4. Клиенту приходится передавать два отклика, для обоих хэш-значений. И в этом случае LM-хэш, естественно, оказывается более слабым. В частности, сразу можно выяснить, длиннее ли 7 символов пароль пользователя: если нет, то третий ключ DES будет представлять собой фиксированную константу 04EE0000000000, с помощью которой легко зашифровать запрос и проверить, тот ли отклик был отправлен серверу. Совершенно очевидно, что для подбора LM-хэша взломщику, когда у него есть перехваченные запрос и отклик, потребуется не больше действий, чем для восстановления пароля по хэшу, так как за те же самые 243 операции он легко восстановит и оригинальный пароль, и хэш.

При WWW-доступе к серверу IIS, требующем аутентификации, используется тот же самый механизм «запрос-отклик». Но существует единственное отличие – и запрос, и отклик кодируются для передачи в рамках протокола http с помощью base64, то есть практически передаются так же, как и в локальных сетях, со всеми вытекающими отсюда последствиями. Впрочем, базовая схема аутентификации http является еще более слабой, требуя и имя, и пароль пользователя в открытом виде. Соответствующий запрос может выглядеть примерно так: http://user:password@www.victim.com.

Таким образом, основной проблемой, ослабляющей алгоритмы аутентификации в Windows NT, является передача нестойкого значения LM-хэша даже в сетях, где нет других серверов и клиентов, кроме Windows NT. В частности, пароли любой длины из латинских букв будут вскрыты нарушителем в среднем за (26 + 262 + … 267) / (2 х 190000) = 22 000 секунд, или всего за 6 часов!

Поэтому фирма Microsoft выпустила заплатку (hot-fix), называемую lm-fix (она вошла потом в Service Pack 4), которая может запретить использование LM-хэша, и он не будет передаваться.

К сожалению, недостатки такого решения лежат на поверхности – теряется совместимость с другими ОС. В частности, hot-fix должна устанавливаться и на сервер, и на все клиенты, так как в противном случае, при обращении, например, к закрытой WWW-странице, будет выдаваться сообщение типа: 500 Server Error (-2146893054). Аналогичное сообщение последует и при попытке доступа с клиентов под управлением Windows 95.

Увы, подобное решение проблемы вносит и дополнительные ошибки, что очень наглядно продемонстрировал Service Pack 4: если клиент после установки Service Pack 4 изменит свой пароль при помощи ОС, не поддерживающей NT-хэш (при этом, как объяснялось выше, его значение в базе SAM обнулится), то потом при входе в систему такое нулевое значение будет ошибочно приниматься за отсутствие пароля, при условии, что для аутентификации использовался NT-хэш.