Привет! Есть форум с IPB 3.3.0 , всё у этого форма прекрасно, даже CVE-2012-2226 не пропатчена, PHP версии 5.2.17 , который позволяет null-byte poisoning, и даже в корне сайта лежит волшебный файл /phpinfo.php Уязвимость позволяет сделать require_once произольного .php файла в системе, и эта часть работает. Но в описании уязвимости основной акцент делается на то, что её можно использовать совместно с null-byte poisoning для того чтобы сделать инклюд не .php файла, а файла с любым расширением, например закачанный в uploads джипег. И эта часть у меня не получается. Более того, мне кажется автор эксплоита чего-то напутал и она в принципе не должна получаться. В эксплоите даны куски кода, где анализируется как работает баг. Параметр key распаковывают base64: Code: $key = trim( IPSText::base64_decode_urlSafe( $this->request['key'] ) ); Потом его разпиливают на кусочки: Code: list( $app, $area, $relId, $likeMemberId, $memberId, $email ) = explode( ';', $key ); Потом один из кусочков ($area) без проверок и очисток принимает участие в формировании пути к файлу: Code: $_file = IPSLib::getAppDir( $app ) . '/extensions/like/' . $area . '.php'; Чтобы заюзать null-byte poisoning надо чтобы $area было равно target_file_name.txt<NULL> , но $key, из которого получается $area проходит через trim() который NULL оттуда вырезает. Таким образом, в $area ну никак не может оказаться NULL. Вопросы: 1. Что имел ввиду автор эксплоита? 2. Как раскрутить LFI во что-то полезное, когда он инклудит только .php ?
Хм... Хотя trim должен отрезать NULL только вначале и в конце... Тогда не понятно почему не работает. Когда я делаю key равным base64("forums;/../../../../../phpinfo;1;1;[email protected]") то инклуд срабатывает и подключается файл phpinfo.php (или любой другой .php) но когда я меняю на вроде бы аналог с NULL: base64("forums;/../../../../../phpinfo.php\0;1;1;[email protected]") то не работает. Может ли php 5.2.17 быть как-то пропатчен\настроен от null-byte poisoning?
PHP: str_replace("\0", '', $value); Как вариант попасть на сервер через соседей/хостинг и через /tmp заинклудится.
Не, ну если бы кто-то туда вставил Code: str_replace("\0", '', $value); То он бы и всё остальное вставил, чтобы не допустить local file inclusion. Выглядит вроде как обычный php 5.2.17 (без suhosin), IPB 3.3 дырявый, но null-byte poisoning не пашет =( Подниму сегодня виртуалку с похожим сетапом, посмотрю что там происходит...
Поднял виртуалку с такими же характеристиками и настройками PHP. Нулл-байт работает отлично, всё-таки у этого товарища какой-то пропатченный PHP, так что NULL вырезается. Просканировал этим инклюдом директории на наличие всяких шеллов в закрытых снаружи папках (cache, hooks). Ничего. Дальше не знаю куда копать.
Я инклюжу phpinfo.php (который лежит в корне сайта) и вижу что MQ отключены. Зато дата сборки php 5.2.17 стоит - февраль 2013. Кроме того это хостинг агавы, так что вероятно хостер делает сборку с каким-то патчем (suhosin в phpinfo не замечено). По пути я проверил MAXPATHLEN-альтернативу null-byte , к сожалению она не работает когда в include указан абсолютный путь, тоесть для: Code: include "lib/" . $_GET['x'] . ".php"; оно сработает, а вот для Code: include "/var/www/site.ru/lib/" . $_GET['x'] . ".php"; трюк с x = /./././.[~4000]/./. к сожалению не работает. В уязвимости CVE-2012-2226 в IPB формируется абсолютный путь =(
