Илья Медведовский - Атака на Internet
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 -c 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, как обычно бывает, а 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 включительно, оказались уязвимыми.
Причины существования уязвимостей в UNIX-системах
Проанализировав большой фактический материал, коснемся причин, по которым описанные нарушения безопасности UNIX имели место, и попытаемся их классифицировать (рис. 9.4). Сразу оговоримся, что классификация ни в коей мере не претендует на новизну или полноту – кому интересна эта тема, предлагаем обратиться к более серьезным научным работам [11, 27]. Здесь же мы опишем вполне понятные читателю причины, по которым происходит до 90 % всех случаев вскрытия UNIX-хостов:
Рис. 9.4. Причины уязвимости UNIX1. Наличие демонов.
2. Механизм SUID/SGID-процессов.
3. Излишнее доверие.
4. Человеческий фактор с весьма разнообразными способами его проявления – от легко вскрываемых паролей у обычных пользователей до ошибок у квалифицированных системных администраторов, многие из которых как раз и открывают путь для использования механизмов доверия.
Механизмы 1 и 2, являющиеся неотъемлемой частью идеологии UNIX, были и будут лакомым кусочком для хакеров, так как пользователь в этом случае взаимодействует с процессом, имеющим большие привилегии, и поэтому любая ошибка или недоработка в нем автоматически ведет к использованию этих привилегий.
О механизме 3 уже достаточно говорилось выше. Повторим, что в UNIX много служб, использующих доверие, и они могут тем или иным способом быть обмануты.
Итак, вот те причины, по которым демоны и SUID/SGID-процессы становятся уязвимыми:
1. Возможность возникновения непредусмотренных ситуаций, связанных с ошибками или недоработками в программировании.
2. Наличие скрытых путей взаимодействия с программой, называемых «люками».
3. Возможность подмены субъектов и объектов различным образом.
К первой можно отнести классическую ситуацию с переполнением буфера или размерности массива. Заметим сразу, что конкретные атаки, несмотря на универсальность способа, всегда будут системозависимыми и ориентированными только на конкретную платформу и версию UNIX.
Хорошим примером непредусмотренной ситуации в многозадачной операционной системе является неправильная обработка некоторого специального сигнала или прерывания. Часто хакер имеет возможность смоделировать ситуацию, в которой этот сигнал или прерывание будет послано (в UNIX посылка сигнала решается очень просто – командой kill, как в примере с sendmail).
Наконец, одна из самых распространенных ошибок программистов – неправильная обработка входных данных, что является некоторым обобщением случая переполнения буфера. А если программа неправильно обрабатывает случайные входные данные, то, очевидно, можно подобрать такие специфические входные данные, которые приведут к желаемым для хакера результатам, как случилось с innd.
Люком или «черным входом» (backdoor) часто называют оставленную разработчиком недокументированную возможность взаимодействия с системой (чаще всего – входа в нее), например, известный только разработчику универсальный «пароль». Люки оставляют в конечных программах вследствие ошибки, не убрав отладочный код, или вследствие необходимости продолжения отладки уже в реальной системе из-за ее высокой сложности, или же из корыстных интересов. Люки – это любимый путь в удаленную систему не только у хакеров, но и у журналистов, и режиссеров вместе с подбором «главного» пароля перебором за минуту до взрыва, но, в отличие от последнего способа, люки реально существуют. Классический пример люка – это, конечно, отладочный режим в sendmail.
Наконец, многие особенности UNIX, такие как асинхронное выполнение процессов, развитые командный язык и файловая система, позволяют злоумышленникам использовать механизмы подмены одного субъекта или объекта другим. Например, в рассмотренных выше примерах часто применялась замена имени файла, имени получателя и т. п. именем программы. Аналогично может быть выполнена подмена специальных переменных. Так, для некоторых версий UNIX существует атака, связанная с подменой IFS (internal field separator – символ разделителя команд или функций) на символ «/». Это приводит к следующему: когда программа вызывает /bin/ sh, вместо него вызывается файл bin с параметром sh в текущем каталоге. Похожая ситуация возникает при атаке на telnetd. Наконец, очень популярным в UNIX видом подмены является создание ссылки (link) на критичный файл. После этого файл-ссылка некоторым образом получает дополнительные права доступа, и тем самым осуществляется несанкционированный доступ к исходному файлу. Подобная ситуация с подменой файла возникает, если путь к нему определен не как абсолютный (/ bin/sh), а как относительный (../bin/sh или $(BIN)/sh). Такая ситуация также имела место в рассмотренной уязвимости telnetd.
И последнее, о чем уже подробно говорилось во второй главе, – нельзя приуменьшать роль человека в обеспечении безопасности любой системы (про необходимость выбора надежных паролей упоминалось ранее). Неправильное администрирование – тоже очень актуальная проблема, а для UNIX она особенно остра, так как сложность администрирования UNIX-систем давно стала притчей во языцех, и часто именно на это ссылаются конкуренты. Но за все надо платить, а это – обратная сторона переносимости и гибкости UNIX.
Настройки некоторых приложений, той же sendmail, настолько сложны, что для поддержания работоспособности системы требуется специальный человек – системный администратор, но даже он, мы уверены, не всегда знает о всех возможностях тех или иных приложений и о том, как правильно их настроить. Более того, если говорить о слабости человека, защищенные системы обычно отказываются и еще от одной из основных идей UNIX – наличия суперпользователя, имеющего доступ ко всей информации и никому не подконтрольного. Его права могут быть распределены среди нескольких людей: администратора персонала, администратора безопасности, администратора сети и т. п., а сам он может быть удален из системы после ее инсталляции. В результате вербовка одного из администраторов не приводит к таким катастрофическим последствиям, как вербовка суперпользователя.
