|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Все наверняка слышали об уязвимости в популярном форуме phpBB. Масса серверов была взломана через дыру в этом скрипте версии <=2.0.10. Суть уязвимости заключалась в том, что после фильтрации кавычек значение переменной highlight прогонялось через функцию urldecode и передавалось для вставки в интересную конструкцию:
$message = str_replace('\"', substr(preg_replace('#(\>(((?>([^><]+|(?R)))*)\<))#se',
"preg_replace('#\b(" . $highlight_match . ")\b#i',
'<span style=\"color:#" . $theme['fontcolor3'] . "\"><b>\\\\1</b></span>', '\\0')",
. $message . 1, -1));
Вот тут и появлялась проблема: кавычку можно было передать в двойном урл кодировании – проверка при фильтрации проходит нормально, а потом перекодировка и вставка позволяют выполнить произвольный PHP код на уязвимой системе.
Если кто не понял, поясняю:
зачем нужна кавычка? - Закрыть условие проверки preg_replace;
дальше делаем .пхпкод. и получаем его вывод непосредственно;
второй кавычкой открываем для нового условия.
Это известно многим. Но не все знают как этот баг “залатали” авторы phpBB :)
Они просто убрали функцию urldecode, думая, что нет двойного декодирования – нет и проблемы.
Экранирование кавычки производится для всех элементов глобальных массивов в common.php:
if( !get_magic_quotes_gpc() )
{
if( is_array($HTTP_GET_VARS) )
{
while( list($k, $v) = each($HTTP_GET_VARS) )
{
if( is_array($HTTP_GET_VARS[$k]) )
Но есть одно но: помещаясь в базу SQL, экранированные кавычки становятся неэкранированными! Т.о., если мы сделаем пост на форуме с темой приблизительного следующего содержания:
'.passthru($cmd).'
то именно в таком виде это все и сохранится в таблице HYPERLINK "http://localhost:80/Tools/phpMyAdmin/tbl_properties_structure.php?lang=ru-win1251&
server=1&collation_connection=cp1251_general_ci&db=phpbb&table=phpbb_posts_text"
phpbb_posts_text
в поле post_subject c post_id соответствующим номеру нашего.
Что нам это дает? Пока ничего %) но не спешите, у нас все впереди.
В скором времени, обнаружили, что сам код с preg_replace() еще бажен тем, что можно вызвать раскрытие пути, что пофиксили в 13-й версии пхпББ:
Find:
Code:
$message = str_replace('\"', substr(preg_replace('#(\>(((?>([^><]+|(?R)))*)\<))#se',
"preg_replace('#\b(" . $highlight_match . ")\b#i',
'<span style=\"color:#" . $theme['fontcolor3'] . "\"><b>\\\\1</b></span>', '\\0')",
. $message . 1, -1));
Replace with:
Code:
$message = str_replace('\"', substr(@preg_replace('#(\>(((?>([^><]+|(?R)))*)\<))#se',
"@preg_replace('#\b(" . $highlight_match . ")\b#i',
'<span style=\"color:#" . $theme['fontcolor3'] . "\"><b>\\\\1</b></span>',
'\\0')", . $message . 1, -1));
Это не очень, но важно. Почему – увидим позже.
Рассмотрим пока еще одну интересную часть кода:
$tracking_topics = ( isset($HTTP_COOKIE_VARS[$board_config['cookie_name'] . )
? unserialize($HTTP_COOKIE_VARS[$board_config['cookie_name'] . : array();
Предварительно зашифрованная функцией serialize наша куки „рассериализируется” – т.е. дешифруется. При этом, естественно, ничего не фильтруется, несмотря на «прогонку» массива COOKIE через функцию addslashes, т.к. она делается до «рассериализации».
Все это вместе дает нам возможность проэксплоитить наш пхпББ:
регистрируемся и создаем тему на форуме с нужным контекстом – php кодом, запоминаем номер темы;
узнаем полный путь к форуму от корня, через баг раскрытия пути в коде с preg_replace();
делаем стандартную инъекцию через куки.
На сем прощаюсь, оставляя для пытливых скрипткидди возможность поэксперементировать с sql инъекцией в куки. Нужно ведь и что-то самому попытаться сделать, а не пользоваться готовыми эксплоитами.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
