Почему не стоит держать на сайте доступный для всех файл с phpinfo() ?

Нередко на веб-сайтах можно обнаружить php-файл содержащий одну-единственную php-функцию - phpinfo(). К тому же, файл этот обычно лежит в открытом доступе и имеет легкоподбираемое имя, например, phpinfo.php. При аудите веб-сайтов я постоянно встреачаю подобное и всегда рекомендую владельцам сайтов удалить/спрятать/переименовать этот файл. Почему?

Во-первых, это наверное всем известно, информация, содержащаяся в выводе phpinfo() нередко может помочь взломщику провести другие веб-атаки (например, из phpinfo() можно узнать полный путь до "DOCUMENT_ROOT" и использовать это при наличии sql-инъекции с чтением файлов, и т.д.).

Но phpinfo() опасна не только этим. Сама по себе эта функция в некоторых версях PHP содержит ошибки, которые можно использовать для проведения XSS. Поискав в гугле можно найти несколько оповещений об XSS-уязвимостиях в phpinfo():

PHP XSS exploit in phpinfo() by Silent Needle
PHP 4.4.3 - 4.4.6 phpinfo() Remote XSS Vulnerability by Stefan Esser
phpinfo() Cross Site Scripting PHP 5.1.2 and 4.4.2 by Maksymilian Arciemowicz
Тут китайцы показывают как можно провести атаку на IE7 через phpinfo() методом Algol'а

Очень часто файл с phpinfo() можно повстречать на сайтах хостеров, а некоторые организующие управление хостингом движки позволяют просматривать вывод phpinfo() всем желающим. Например, в WHMCompleteSolution получить вывод phpinfo() можно обратившись по адресу

http://vuln.site/status/index.php?action=phpinfo&xss[]=%3Cscript%3Ealert(/hi, i am xss!/)%3C/script%3E

Набрав в гугле запрос

"php version" inurl:status/index.php?action=phpinfo

можно быстро найти с десяток сайтов с WHMCompleteSolution и уязвимыми версиями PHP.
Кстати, XSS в phpinfo() можно использовать для обхода HTTPOnly, ведь содержимое cookies выводится на странице, и их можно взять из нее, не используя метод cookies:

http://vuln.site/phpinfo.php?xss[]=%3Cscript%3Ealert(document.getElementsByTagName('*')[xxx].innerHTML)%3C/script%3E

Значение 'xxx' в данном примерe - это номер элемента массива, возвращаемого методом getElementsByTagName, содержащий значение cookies.

Чтение php-кода из файла при наличии LFI

Ну вот, заканчивается это замечательное лето (надеюсь, у вас оно тоже было замечательным), и похоже пасмурная осень не заставит себя долго ждать. Ну что ж, значит пришло время вернутся к своему ноуту и продолжить изучение интересующих меня вещей из мира ИТ. А это означает, что в этом бложике начнут, наконец, появляться новые заметки. ( : Начну я, пожалуй, с тех вещей о которых я все хотел, но забывал/забивал написать в течении последних нескольких месяцев.

Итак, это было небольшое лирическое отступление, а теперь перейду непосредственно к теме заметки.

Когда я описывал в заметке Self-contained RFI in PHP способ использования wrapper'а php://filter для кодирования php-кода веб-шелла, я упустил из виду одну интересную возможность, которую может дать использование этого wrapper'а при наличии RFI в коде атакуемого сайта, но невозможности эксплуатации уязвимости как RFI, а только как LFI, из-за allow_url_include = Off.

Иногда вместо выполнения php кода при инклуде, может оказаться полезным не выполнение, а чтение файла, содержащего php-код. А чтобы php-код не выполнился, мы можем закодирвать его с помощью php://filter. Например:

http://vuln.site/?lfi_here=php://filter/read=convert.base64-encode/resource=index.php

Затем остается лишь перекодировать выведенный закодированный base64-кодировкой текст обратно в php-код. Не забывайте только, что php://filter доступен в версиях PHP => 5.0.0.

Узнал я об этом трюке пару месяцев назад из заметки в блоге pragmatk'a. Если вам это пригодилось - шлите респекты ему. Да, и отдельное спасибо Qwazar'у за то, что напомнил мне об этом. ( ;

"Памятник вайтхэтам" ( ;

На мой взгляд, отличное место для проведения летних поинтов айтишников-секьюрников. ( :

Вышел Phrack #66 ( ;

Сегодня зарелизили Phrack #66, чему я весьма рад. Это уже пятый релиз этого езина, который я застал, и, должен заметить, журнал под руководством последнего редакторского состава, "Общества потерянных хакеров", становится действительно интереснее, по крайней мере, мне так кажется.

Помимо традиционно открывающих езин введения, новостей и профайла, а также, похоже, уже ставшей традиционной, заключительной статьи из серии "Hack your brain", в номер вошло 13 "технических" статей. Интересно, что авторы статей для этого номера phrack'a совершенно забили на Виндось - ни одной статьи о каких-нибудь хаках Windows-систем, что выглядит даже как-то странно. Впрочем, меня это не особо расстроило. ( ;

Итак, качаем свежий номер #66 с phrack.org!

Кстати, этот номер phrack'a его редакторы посвятили памяти безвременно ушедшего из жизни в мае этого года Cliph'а, известного исследователя безопасности Linux-систем, автора нескольких linux-kernel-эксплоитов...