Илья Медведовский - Атака на Internet
Итак, хэш-функция, разработанная на базе того же самого алгоритма 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: [email protected]
Таким образом, основной проблемой, ослабляющей алгоритмы аутентификации в 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-хэш.
Как защитить свой хост
Узнав такой впечатляющий набор фактов об уязвимости вашей системы, вы, несомненно, зададите себе вопрос: как же обеспечить защиту в сети и возможно ли это? Не будем дискутировать на философскую тему «Почему абсолютная защита невозможна». В любом случае задача каждого администратора безопасности – сделать все, чтобы максимально ее улучшить. Надеемся также, что вы уже прочитали рассуждения в главе 8 по вопросу «А что мне защищать?». Поэтому советуем придерживаться следующих концепций:
1. Актуальность – защищаться надо от реальных атак, а не от фантастических или, наоборот, архаичных времен вируса Морриса.
2. Разумность затрат – поскольку 100-процентной защиты мы все равно не обеспечим, надо найти тот рубеж, за которым затраты на дальнейшее повышение безопасности оказываются выше стоимости той информации, которую может украсть взломщик.
Итак, ниже (табл. 9.2) приводится список очень простых правил и действий (некоторые идеи взяты из [26]) с учетом важности и первоочередности применения.
Таблица 9.2. Административные меры усиления защиты серверов в Internet
Перечисленные меры позволят вам не подпустить к своему хосту до 99 % всех кракеров. Но ненадолго. Для того чтобы поддерживать систему в таком защищенном состоянии, советуем раз в одну-две недели вновь посещать CERT или CIAC. Также не забывайте контролировать наличие вирусов или «троянских» коней. Не менее полезно подписаться на листы рассылки или дайджесты по безопасности, лучшим из которых, на наш взгляд, является BUGTRAQ.
Остальные меры, предусмотренные для отлова последнего процента самых достойных кракеров, являются превентивными, они не направлены конкретно на ту или иную службу. Возможно, они будут сопряжены с более или менее значительной переделкой вашего хоста:
1. Придумайте какую-нибудь собственную изюминку, очень простую (чтобы поставить слишком умных кракеров в тупик), типа переименования какой-нибудь важной команды или сообщения на входе «FSB host. Vvedite vashe imya i zvanie:».
2. Используйте более простые программы – в них меньше ошибок. В UNIX – избавьтесь от sendmail, поставьте другой SMTP-демон, в Windows NT – не стоит для этих же целей использовать монстров типа Microsoft Exchange Server.
3. Выкиньте некоторые малоиспользуемые службы (типа finger, talk, rpc) и ужесточите настройки вашего межсетевого экрана.
4. Поставьте proxy-сервер для дополнительной аутентификации извне, а также для скрытия адресов и топологии внутренней подсети.
5. Перенесите весь сервис, требующий входящих соединений (http, SMTP), на отдельную машину и оставьте ее в открытой сети. Удалите с этой машины всю лишнюю информацию. Все остальные машины спрячьте за межсетевым экраном с полным отключением входящего трафика.
