IPB 3.3.0 LFI помогите разобраться с CVE-2012-2226

[coolspot]

Привет!

Есть форум с IPB 3.3.0 , всё у этого форма прекрасно, даже CVE-2012-2226 (http://www.exploit-db.com/exploits/18736/) не пропатчена, 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 , но $key, из которого получается $area проходит через trim() (http://php.net/manual/en/function.trim.php) который NULL оттуда вырезает.

Таким образом, в $area ну никак не может оказаться NULL.

Вопросы:

1. Что имел ввиду автор эксплоита?

2. Как раскрутить LFI во что-то полезное, когда он инклудит только .php ?

[coolspot]

Хм... Хотя trim должен отрезать NULL только вначале и в конце...

Тогда не понятно почему не работает.

Когда я делаю key равным

base64("forums;/../../../../../phpinfo;1;1;mail@mail.ru")

то инклуд срабатывает и подключается файл phpinfo.php (или любой другой .php)

но когда я меняю на вроде бы аналог с NULL:

base64("forums;/../../../../../phpinfo.php\0;1;1;mail@mail.ru")

то не работает.

Может ли php 5.2.17 быть как-то пропатчен\настроен от null-byte poisoning?

[b3]

coolspot said:
Может ли php 5.2.17 быть как-то пропатчен\настроен от null-byte poisoning?




PHP:
str_replace("\0",'',$value);

Как вариант попасть на сервер через соседей/хостинг и через /tmp заинклудится.

[coolspot]

Не, ну если бы кто-то туда вставил


Code:
str_replace("\0", '', $value);

То он бы и всё остальное вставил, чтобы не допустить local file inclusion.

Выглядит вроде как обычный php 5.2.17 (без suhosin), IPB 3.3 дырявый, но null-byte poisoning не пашет =(

Подниму сегодня виртуалку с похожим сетапом, посмотрю что там происходит...

[coolspot]

Поднял виртуалку с такими же характеристиками и настройками PHP.

Нулл-байт работает отлично, всё-таки у этого товарища какой-то пропатченный PHP, так что NULL вырезается.

Просканировал этим инклюдом директории на наличие всяких шеллов в закрытых снаружи папках (cache, hooks). Ничего.

Дальше не знаю куда копать.

[BigBear]

Мб там просто экранируется нулл-байт за счёт MQ ?

[coolspot]

Я инклюжу phpinfo.php (который лежит в корне сайта) и вижу что MQ отключены.

Зато дата сборки php 5.2.17 стоит - февраль 2013. Кроме того это хостинг агавы, так что вероятно хостер делает сборку с каким-то патчем (suhosin в phpinfo не замечено).

По пути я проверил MAXPATHLEN-альтернативу null-byte (http://raz0r.name/articles/null-byte-alternative/) , к сожалению она не работает когда в include указан абсолютный путь, тоесть для:


Code:
include "lib/" . $_GET['x'] . ".php";

оно сработает, а вот для


Code:
include "/var/www/site.ru/lib/" . $_GET['x'] . ".php";

трюк с x = /./././.[~4000]/./. к сожалению не работает.

В уязвимости CVE-2012-2226 в IPB формируется абсолютный путь =(