Безопасная эксплуатация Apache, часть 9: атаки на PHP-приложения

Оригинал: Securing Apache, Part 9: Attacks that Target PHP-based Instances
Автор: Arpit Bajpai
Дата публикации: 1 Мая 2011 г.
Перевод: А.Панин
Дата перевода: 4 Февраля 2013 г.

Начало статьи: "Безопасная эксплуатация Apache, часть 9: атаки на PHP-приложения"

Атаки локального включения файлов (LFI)

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

<?php
$page = $_GET[page];
include($page);
?>

Данный код уязвим, так как значение переменной page не проходит проверку, а напрямую включается (исполняется). Представьте, что существует директория /test с файлом test.php в ней; пример строки URL для доступа к нему будет выглядеть следующим образом: www.example.com/test/test.php. Теперь представим, что в директории /test находится файл index.php, доступный с помощью следующей строки URL: www.example.com/test/index.php. Если файл index.php содержит следующий уязвимый код PHP, у нас будет возможность использовать строку URL www.example.com/test/index.php?page=../test/test.php и, таким образом, выполнить сценарий test.php. (Последовательность символов ../ служит для перехода в директорию уровнем выше.)

Если веб-сайт работает на сервере под управлением *NIX, у нас должна быть возможность произвести обход директорий до файла passwd и других с помощью подобной строки URL (предполагается, что файл index.php находится в директории /var/www/test): www.example.com/test/index.php?page=../../../etc/passwd. (Если вы не знаете, в какой директории на сервере находится файл test.php, можете попытаться подставлять последовательность символов ../ до того момента, как окажитесь в нужной директории.) Кроме файла /etc/passwd, взломщики также могут попытаться получить содержимое файлов /etc/shadow, /etc/group, /etc/security/group, /etc/security/passwd, /etc/security/user, /etc/security/environ, /etc/security/limits и /usr/lib/security/mkuser.default.

Чаще всего в качестве меры дополнительной безопасности разработчики просто добавляют расширение .php в конец строки URL, поэтому при запросе взломщиками файла /etc/passwd, как показано выше, запрос примет вид /etc/passwd.php. Этого файла не существует. Однако, для обхода этой системы защиты взломщик может просто использовать нулевой байт - т.е. добавить %00 в конец строки URL перед отправкой: /etc/passwd%00. Нулевой байт позволяет игнорировать часть строки после него, таким образом запрос примет вид: /etc/passwd.

Журнал Apache и атаки локального включения файлов

Описанный выше пример атаки позволяет взломщикам читать файлы, располагающиеся на сервере. Но существуют также способы выполнения необходимого злоумышленникам кода - в большинстве случаев с использованием файлов журнала Apache. Обычно Apache использует два файла журнала: access_log, содержащий все корректные запросы к веб-серверу и error_log, содержащий сообщения об ошибках. Apache позволяет настроить подробность записи событий в эти файлы - администраторы могут устанавливать, нужно ли записывать в файл информацию о браузере, ОС, предыдущей строке URL для каждого запроса. Так как взломщики могут контролировать то, какая информация передается серверу, они могут просто изменить информацию о браузере или ОС на корректный код PHP и передать его.

Так как Apache поддерживает виртуальные узлы, он может работать с несколькими доменами, используя один и тот же IP-адрес, поэтому администратор может задать имя и расположение файла журнала, следовательно сложно установить директорию хранения журнала событий Apache. Однако, эта информация очень важна для успешного завершения атаки. Ниже приведены стандартные директории, используемые для хранения файлов журнала событий Apache (в качестве имен файлов должны использоваться access.log и error.log): /etc/httpd/logs/, /opt/lampp/logs/, /usr/local/apache/log, /usr/local/apache/logs/, /usr/local/etc/httpd/logs/, /usr/local/www/logs/thttpd_log, /var/apache/logs/, /var/log/apache/, /var/log/apache-ssl/, /var/log/httpd/, /var/log/httpsd/ssl.access_log (в *NIX-системах) и C:\apache\logs, C:\Program Files\Apache Group\Apache\logs, C:\program files\wamp\apache2\logs, C:\wamp\apache2\logs, C:\wamp\logs, C:\xampp\apache\logs в Windows-системах.

Теперь давайте рассмотрим случай использования файла error_log в ходе атаки. Взломщики используют запрос в отношении уязвимого к атакам локального включения файлов сервера со следующей строкой URL: http://www.example.com/<?php+$s=$_GET;@chdir($s['x']);echo@system($s['y'])?>.

После этого они пытаются получить доступ к вставленному в файл журнала событий коду PHP с помощью запроса: http://www.example.com/test/index.php?page=/var/log/apache/logs/error_log%00&x=/&y=uname.

В итоге взломщиками будет получена системная информация от сервера. В ходе атаки использовалась особенность работы сервера, заключающаяся в том, что так как файла <?PHP $s=$_GET;@chdir($s['x']);echo@system($s['y'])?> не существует на сервере, данный код PHP добавляется в файл журнала error_log, а затем исполняется при помощи запроса с использованием второй строки URL.

Теперь рассмотрим второй случай с использованием файла access_log в ходе атаки. В данном случае взломщики подменяют значение параметра User-Agent, отправляемое в заголовках их браузерами на PHP-код (как и в предыдущем примере) с помощью расширения Firefox с названием "User Agent Switcher". Для записи в журнал событий сервера измененной строки User Agent, они просто заходят на сайт http://www.example.com. После этого они включают файл access_log для выполнения кода (строка URL аналогична предыдущему случаю за исключением изменившегося имени файла).

Мероприятия по повышению безопасности

Инструменты

Проверка на уязвимость к атакам включения файлов

Уязвимости загрузки файлов

Всегда, когда вы позволяете пользователям загружать файлы, такие, как изображения, принимаемые приложением гостевой книги, вы добавляете уязвимость в ваше приложение. Пользователи могут загрузить вирус, руткит или другой вредоносный сценарий так же просто как безобидную картинку. Механизм загрузки файлов может быть главной угрозой безопасности и без лишних сложностей использоваться для получения доступа к файловой системе сервера, поддерживающего работу веб-приложения. Для лучшего понимания методов проведения атак против механизма загрузки файлов, рассмотрим простой сценарий атаки.

Сценарий атаки 3

<?php
$target_path = "uploads/";
$target_path = $target_path . basename( $_FILES['uploadedfile']['name']);
if(move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target_path))
{
    echo "The file ". basename( $_FILES['uploadedfile']['name']).
    " has been uploaded";
}
else
{
    echo "There was an error uploading the file, please try again!";
}
?>

<form enctype="multipart/form-data" action="uploader.php" method="POST">
    <input type="hidden" name="MAX_FILE_SIZE" value="100000" />
    Choose a file to upload: <input name="uploadedfile" type="file" /><br />
    <input type="submit" value="Upload File" />
</form>

Функция PHP move_uploaded_file переместит временный файл по заданному пользователем пути. В данном случае путь для перемещения файла находится в пределах корневой директории веб-сервера. Следовательно, файл будет доступен при использовании строки URL, похожей на следующую: http://www.example.com/uploads/temp-uploads/uploadedfile.jpg.

В этом простом примере не накладывается ограничений на тип загружаемых файлов, поэтому взломщик может загрузить файл с вредоносным кодом PHP или .NET, что приведет к компрометации сервера. В таком случае взломщик может просто загрузить вредоносные сценарии c99 shell или r57 shell и получить контроль над сервером.

Однако, даже если в целях безопасности проверка расширения файла производится перед загрузкой, взломщик может также обойти ее, использовав нулевой символ %00. Все что требуется сделать, это выбрать файл PHP для загрузки, не нажимая на кнопку "Загрузить". Путь к выбранному для загрузки файлу будет отображен и для *NIX-систем будет выглядеть как /Users/username/exploit.php, а для Windows-систем как c:\exploit.php. На этом этапе нужно вручную добавить к строке нулевой символ с каким-либо последующим расширением изображения, например, /Users/username/exploit.php%00.jpg или c:\exploit.php%00.jpg.

После нажатия на кнопку "Загрузить" сервер проверит расширение, посчитает, что производится загрузка изображения и выведет сообщение, подобное следующему: "Спасибо за загрузку вашего изображения!". Как только файл будет загружен, появится возможность выполнения вредоносного кода на сервере.

AddHandler cgi-script .php .php3 .php4 .phtml .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI

AddType application/x-httpd-php .jpg

Эта строка указывает Apache, что необходимо исполнять файлы изображений с расширением .jpg так, как будто это сценарии PHP. Теперь взломщик может загрузить файл с расширением .jpg, содержащий код PHP. Так как загружаемые файлы могут перезаписывать и перезаписывают существующие, злоумышленники могут без лишних сложностей заменить файл .htaccess своей модифицированной версией, позволяющей исполнять определенные сценарии для последующей компрометации сервера.

Мероприятия по повышению безопасности

Мы поговорим о других опасных атаках на веб-приложения и Apache в следующей статье.

Всегда помните: нужно знать все о взломе, но не заниматься им.

Дополнительные ресурсы

Я настоятельно рекомендую прочитать пост из блога с названием "Remote File Inclusion Attacks - pt1".

Следующая статья серии: "Безопасная эксплуатация Apache, часть 10: модуль mod_security"