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

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-хэш.

Как защитить свой хост

Узнав такой впечатляющий набор фактов об уязвимости вашей системы, вы, несомненно, зададите себе вопрос: как же обеспечить защиту в сети и возможно ли это? Не будем дискутировать на философскую тему «Почему абсолютная защита невозможна». В любом случае задача каждого администратора безопасности – сделать все, чтобы максимально ее улучшить. Надеемся также, что вы уже прочитали рассуждения в главе 8 по вопросу «А что мне защищать?». Поэтому советуем придерживаться следующих концепций:

1. Актуальность – защищаться надо от реальных атак, а не от фантастических или, наоборот, архаичных времен вируса Морриса.

2. Разумность затрат – поскольку 100-процентной защиты мы все равно не обеспечим, надо найти тот рубеж, за которым затраты на дальнейшее повышение безопасности оказываются выше стоимости той информации, которую может украсть взломщик.

Итак, ниже (табл. 9.2) приводится список очень простых правил и действий (некоторые идеи взяты из [26]) с учетом важности и первоочередности применения.

Таблица 9.2. Административные меры усиления защиты серверов в Internet

Перечисленные меры позволят вам не подпустить к своему хосту до 99 % всех кракеров. Но ненадолго. Для того чтобы поддерживать систему в таком защищенном состоянии, советуем раз в одну-две недели вновь посещать CERT или CIAC. Также не забывайте контролировать наличие вирусов или «троянских» коней. Не менее полезно подписаться на листы рассылки или дайджесты по безопасности, лучшим из которых, на наш взгляд, является BUGTRAQ.