Атака на Internet
Шрифт:
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), на отдельную машину и оставьте ее в открытой сети. Удалите с этой машины всю лишнюю информацию. Все остальные машины спрячьте за межсетевым экраном с полным отключением входящего трафика.
6. Поставьте защищенную версию UNIX или другой операционной системы.
Средства автоматизированного контроля безопасности
Мы уже говорили о пользе средств автоматизированного контроля безопасности отдельного компьютера, а также всей подсети, за которую он отвечает, для системного администратора. Естественно, такие средства появлялись ранее, и чаще других встречаются названия COPS (Computer Oracle and Password System), SATAN (Security Administrator Tool for Analizyng Networks), ISS (Internet Security Scanner). К сожалению, они не лишены недостатков:
1. Системозависимость – обычно рассчитаны на вполне конкретную ОС или даже ее версию.
2. Ненадежность и неадекватность – если эти программы сообщают, что все о\'кей, то совсем не значит, что так оно и есть, и наоборот – некая «уязвимость», с их точки зрения, может оказаться специальным вариантом конфигурации системы.
3. Маленький срок жизни – с момента обнаружения уязвимости до ее искоренения проходит не больше года, и программа устаревает.
4. Неактуальность – с момента выхода программы в свет все новые, и потому самые опасные, уязвимости оказываются неизвестными для нее, и ценность программы быстро сводится к нулю. Этот недостаток является самым серьезным.
5. Возможность использовать средства с прямо противоположными целями – для взлома вашей системы, а не для тестирования на предмет изъянов.
Прослеживается явная аналогия программ с антивирусными сканерами первого поколения – те знали лишь строго определенный набор вирусов, а новые вирусы добавлялись только в следующем выпуске программы. Если посмотреть на возможности современных антивирусных программ – это и оперативное лечение вирусов, и автоматизированное пополнение базы вирусов самим пользователем, и поиск неизвестных вирусов, то можно пожелать, чтобы хороший сканер Internet смог позаимствовать некоторые из них. В первую очередь – пополнять базы новыми уязвимостями. Причем в наши дни сделать это несложно – достаточно лишь скачивать информацию с источников типа CERT или CIAC, занимающихся как раз сбором таких сведений.
Программа SATAN
После общего введения мы решили познакомить читателя с таким нашумевшим средством, как SATAN, которое и до сих пор иногда считается чуть ли ни самой опасной программой из написанных, на что указывает и зловещее название, и возможность влезть в самый защищенный компьютер (рис. 9.6). Насчет названия сразу подчеркнем, что в момент инсталляции с помощью специальной процедуры вы можете поменять его на SANTA (Security Analysis Network Tool for Administrator), а заодно и зловещего сатану на симпатичного Деда Мороза (рис. 9.7). А что касается влезания в компьютер (не любой, конечно) – если подобная программа и имелась бы у хакеров или спецслужб, то она никогда не стала бы свободно распространяться по Internet, как это происходит с SATAN.
На самом деле SATAN – это добротно сделанная, с современным интерфейсом программа для поиска брешей в вашей подсети (Intranet – как модно говорить в последнее время), написанная на машинно-независимых языках Perl и С, поэтому она в некоторой мере преодолевает первый из вышеописанных недостатков. SATAN даже допускает возможность для расширения и вставки новых модулей. К сожалению, во всем остальном ей присущи указанные недостатки, в том числе и самый главный – она уже устарела и не может в настоящий момент серьезно использоваться ни администраторами, ни хакерами. Поэтому непонятен мистический страх перед всемогуществом SATAN. Авторы, готовя материал для книги, сами столкнулись с таким отношением и были немало этим удивлены. Однако на момент выхода (1995 г.) программа была достаточно актуальной, содержала в себе поиск большинства уязвимостей, описанных в разделе «Типичные атаки». В частности, последняя (во всех смыслах) ее версия ищет уязвимости в следующих службах:
• FTP и TFTP;
• NFS и NIS;
• rexd;
• sendmail;
• r-службах;
• X-Window.
Существуют также и дополнения к SATAN, в которые включены другие уязвимости.
Для поиска уязвимостей программа сначала различными способами собирает информацию о вашей системе, причем уровень проникновения конфигурируется пользователем и может быть легким, нормальным или жестким (рис. 9.8).