|
ru.nethack
- RU.NETHACK -------------------------------------------------------------------
From : Dennis Erokhin 2:5063/41.32 15 Aug 2000 20:24:57
To : Vladislav Myasnyankin
Subject : Re: Hевъеду в пакет.
--------------------------------------------------------------------------------
VM>>>> Перехватил хэш и предъявлю в следующий раз :)
an>>> а разьве значение хеша не привязано к машине с которой оно
an>>> отрправляется?
EK>> Все еще хyже ;-) Это классический challenge-response. Так, что
EK>> сpазy после
VM> Вот я на это и намекал :) Кстати, алгоритм в более-менее удобоваримом
VM> виде есть ? Хочется сравнить с новеловским.
Это конечно бaнaльно, нa вот что пишетcя во второй "Атaке"
>=== Ховайся, Windows Clipboard идет ===<
Функции хэширования паролей
1 В ОС Windows NT для защиты паролей используются две однонаправлен-1 ные
хэш-функции: хэш Lan Manager (LM-хэш) и хэш Windows NT I (NT-хэш). Hаличие
двух функций, выполняющих одно и то же, говорит
о совместимости со старыми ОС. LM-хэш был разработан Microsoft для
операционной системы IBM OS/2, он интегрирован в Windows 95/98, Windows
for Workgroups и частично в Windows 3.1. Хэш Windows NT был разработан
специально для ОС Microsoft Windows NT, и его умеют вычислять только
последние версии ОС этого семейства, начиная с Windows 95. Функция LM-хэш
основана на алгоритме DES; NT-хэш является не чем иным, как известной
хэш-функцией MD4.
Обычно в базе данных SAM хранятся, будучи дополнительно зашифрованными по
алгоритму DES с ключом, зависящим от RID пользователя, оба хэш-образа
пароля. Hо иногда в системе может храниться только один из них. Очевидно,
это будет происходить в случае, когда пользователь меняет пароль из ОС, нс
поддерживающей NT-хэш, - тогда в базу SAM записывается только LM-хэш (а
поле NT-хэша обнуляется). И наоборот, если пароль пользователя превышает
14 байт, то туда попадет один лишь NT-хэш.
- -------------------------------------------------------------
I В документации Microsoft сказано, что длина паролей Windows NT может
достигать 128 символов. Однако User Manager (диспетчер пользователей)
ограничивает длину до 14 символов.
- -------------------------------------------------------------
При обоих способах входа в систему (локальном и удаленном) процедура
аутентификации сначала пытается сверить NT-хэш. Если его не оказывается
(либо в базе SAM, либо в переданной информации), тогда она пытается
проверить подлинность по LM-хэшу. Такая схема призвана обеспечить большую
надежность сетей Windows NT, но в то же время и совместимость со старыми
сетевыми клиентами. Однако первое ей не удается по той простой причине,
что часто клиент не знает, какой хэш следует передавать серверу, в
результате оба хэша передаются одновременно, и стойкость их равна
стойкости наиболее слабого из них. Какого же? Функция хэша Lan Manager
вычисляется таким образом:
1. Пароль превращается в 14-символьную строку путем либо усечения более
длинных паролей, либо дополнения коротких паролей нулевыми элементами.
2. Все символы нижнего регистра переводятся в верхний регистр. Цифры и
специальные символы остаются без изменений.
3. Полученная 14-байтовая строка разбивается на две 7-байтовых половины.
4. Каждая половина строки используется в роли ключа DES при шифровании
фиксированной константы, что дает две 8-байтовых строки.
5. Эти строки сливаются для создания одного 16-разрядного значения
хэш-фуикции.
Из этого можно сделать вывод, что атаки на функцию LM-хэша достигают
успеха по следующим причинам:
1. Преобразование всех символов в верхний регистр ограничивает и без того
небольшое число возможных комбинаций для каждого (26 + 10+ 32 - 68).
2. Две "половины" пароля хэшируются независимо друг от друга. Таким
образом, обе 7-символьные части пароля могут подбираться перебором
независимо друг от друга, и пароли длиной более семи символов не сильнее
паролей длиной в семь символов. Следовательно, для гарантированного
нахождения пароля необходимо перебрать вместо 94" + 94' + ...+ 94^ - 4 x
1027 всего лишь 68ш +68' +...+6У" 7х10" " 1" комбинации (то есть почти в
10^ раз меньше).
- -------------------------------------------------------------
I По логике вещей эту сумму надо было умножить на два, так как необхо-^^д
димо перебирать две половинки хэша. Hо нетрудно оптимизировать атаку так,
чтобы перебрались все пароли только по одному разу, сравнивая поочередно
их хэш-значение с каждой половинкой, что сократит время перебора почти в
два раза.
- -------------------------------------------------------------
Кроме того, пароли, длина которых не превышает семи символов, очень легко
распознать, поскольку вторая половина хэша будет одним и тем же значением
AAD3B435B51404EE, получаемым при шифровании фиксированной константы с
помощью ключа из семи нулей. '
3. Скорость перебора паролей в 15 раз больше, чем в UNIX, и достигает 190
000 паролей/с на Pentium 166.
4. Hет элемента случайности (привязки (salt), как это сделано в cryptO) -
два пользователя с одинаковыми паролями всегда будут иметь одинаковые
значения хэш-функции. Таким образом, можно заранее составить словарь
хэшированных паролей и осуществлять поиск неизвестного пароля. Это
позволит увеличить скорость перебора на несколько порядков.
Итак, хэш-функция, разработанная на базе того же самого алгоритма DES, но
на 10-15 лет позже функции crypt(), оказывается хуже последней по всем
параметрам, а именно:
. по мощности перебора для гарантированного подбора пароля - почти в 1000
раз;
. по скорости перебора - почти в 15 раз;
. по отсутствию случайности, что приводит к уменьшению требуемой памяти
для хэширования каждого пароля, - в 4 096 раз.
Hе удивительно, что фирме Microsoft пришлось разрабатывать более
криптостойкую функцию (точнее, не изобретать велосипед, который мог
оказаться с квадратными колесами, а воспользоваться готовым образцом). Хэш
Windows NT вычисляется следующим образом.
1. Пароль длиной до 128 символов преобразуется в строку в кодировке
Unicode, при этом сохраняются разные регистры.
2. Эта строка хэшируется с помощью MD4, что дает в результате 16-байтовое
значение хэш-функции.
Хэш Windows NT обладает преимуществом по сравнению с функцией хэша Lan
Manager - различаются регистры, пароли могут быть длиннее 14 символов, для
хэширования используется весь пароль в целом, а не его части, хотя
по-прежнему отсутствует элемент индивидуальности. Таким образом, люди,
имеющие одинаковые пароли, всегда будут иметь одинаковые хэш-значения.
Удаленная аутентификация
Механизм удаленной регистрации на сервере (надо отдать должное
разработчикам Windows NT) более надежен тем, что ни пароль пользователя,
ни его хэш не передаются по сети в открытом виде (по крайней мере, в
последних диалектах SMB). Впрочем, это не оригинальная находка Microsoft,
а стандартный механизм большинства систем клиент - сервер, если связь
между ними осуществляется по небезопасным каналам.
Функционирует механизм удаленной аутентификации, называемый
"запрос-отклик", таким образом:
1. Клиент выдает команду на подключение к серверу.
2. Сервер либо возвращает пакет, в котором присутствует флаг, требующий от
клиента передавать пароль в открытом виде (то есть сервер не поддерживает
последние диалекты SMB), либо возвращает 8-байтовый случайный запрос
(challenge). Далее рассматривается только последний вариант.
3, Клиент вычисляет LM-хэш введенного пароля, добавляет к нему пять нулей,
получая таким образом 21-байтовую строку. Далее он делит ее на три
7-байтовых части, каждая из которых используется как отдельный ключ в
алгоритме DES, - на этих ключах независимо три раза зашифровывается
полученный запрос, что приводит к появлению 24-разрядного шифрованного
значения. Поскольку клиент не знает, значения каких хэш-функции определены
для данного пользователя в базе данных SAM на сервере, то он поступает
аналогично и с хэш-функцией Windows NT. Таким образом, длина отклика
клиента достигает 48 байт.
4. Сервер ищет то значение хэш-функции в своей базе данных SAM, которое
присуще данному пользователю, аналогично шифрует запрос с его помощью и
сравнивает с нужной половиной полученного отклика. Если значения
совпадают, аутентификация считается состоявшейся. Из сказанного можно
сделать следующие выводы:
1. Все-таки есть возможность передачи пароля открытым текстом.
Соответственно, используя механизм ложного сервера, можно заставить
клиента передавать незашифрованные пароли.
2. Для успеха аутентификации злоумышленнику не нужно знать оригинальный
пароль пользователя. Это вполне очевидно, так как сервер также его не
знает, а пользуется только хэш-значением. Владея этим значением,
злоумышленник может подключаться к серверу.
3. При этом взломщик не получит это хэш-значение, непосредственно
перехватив один или более сеансов подключения к серверу, потому что оно
используется как ключ шифрования. Итак, самый реальный способ для
злоумышленника - извлечение хэша непосредственно из базы данных на сервере.
4. Клиенту приходится передавать два отклика, для обоих хэш-значений. И в
этом случае LM-хэш, естественно, оказывается более слабым. В частности,
сразу можно выяснить, длиннее ли 7 символов пароль пользователя: если нет,
то третий ключ DES будет представлять собой фиксированную константу
04ЕЕОООООООООО, с помощью которой легко зашифровать запрос и проверить,
тот ли отклик был отправлен серверу. Совершенно очевидно, что для подбора
LM-хэша взломщику, когда у него есть перехваченные запрос и отклик,
потребуется не больше действий, чем для восстановления пароля по хэшу, так
как за те же самые 2^ операции он легко восстановит и оригинальный пароль,
и хэш.
>=== А вот и конец (Windows Clipboard) ===<
Dennis
---
* Origin: Доктора ведут... (2:5063/41.32)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
