LFI на нестандартно сконфигурированном сервере

[Mints97]

[nikp]

Mints97 said:
Полез в /etc/php.ini. Там прописано:

Code:
session.save_path = "/var/lib/php/session"

Лезу в /var/lib/php/session/sess_. Опять облом!


А чем прочитал php.ini? При помощи lfi прочитать его нельзя.

И что за облом с сессией, файл сессии не существует или просто пустой?

[nikp]

Mints97 said:
Почему это нельзя прочитать php.ini? нормально он прочитался...


В условиях LFI, include('../../../../etc/php.ini') не прочитает ни один конфиг ни от какой версии php, можешь убедиться сам. При RFI прочитать можно.

Посмотри уязвимый скрипт, что там на самом деле. Это, скорее всего, - простое чтение файлов.

===

UPD

Точнее не читаются конфиги, в которых оставлен дефолтный комментарий, из-за наличия в нем тегов .

Инклуд выдаст ошибку на них.

Посмотри полученный php.ini, если встречается тег "

[Unknown]

Насчет сессий - вероятно они хранятся в памяти. Какое значение "session.save_handler" в php.ini?

[Unknown]

Хм, если нет строки, тогда, если верить докам, по умолчанию должно сохранять в файлы. Странно, php явно должен иметь доступ к файлам сессии. Файлы сессии именно не найдены или же есть вероятность, что они просто-напросто пусты?

Насчет "/usr/lib/perl5" и ко - я думаю, стоит пробить инфу о сервере, есть вероятность, что в используемой версии оси файлы расположены в другом месте. Глянь что написано в "/etc/issue".

[Adio]

Пока ты хекаеш сервех хипстер хекает тебя

[Unknown]

Попробуй "/usr/lib64/perl5" и подобное.

Хотя, с другой стороны, я посмотрел листинг файлов для CentOS 5.8, и там нет нигде папки Locus, а единственный Logger.pm был в "/usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/". Вероятно файл называется иначе.

[BillyMilliga]

а как же старый добрый /proc/self ?

если пхп как цги, то вот тебе и окружение на которое ты можешь повлиять

если как модуль апача, то возможно логи

[Unknown]

А сессии точно ли работают? Если админ параноик, то у апача возможно нет прав на запись в папку сессий или баг аля https://github.com/puphpet/puphpet/issues/274

[Unknown]

Вобщем, если действительно очень хочется, то наверно в самом деле придется методом тыка перебрать всю /proc и найти процесс с перлом, потому как, по всей видимости, логгер класс подключен внешне. Скорей всего, лучше это сделать скриптом, потому как процесс может иметь ооочень большой номер для ручного перебора (проверь /proc/sys/kernel/pid_max чтобы узнать крайнее значение). Базово, апач должен уметь читать файлы из /proc, если у админа не еще один бзик.

[Unknown]

Да нет, перебрать 32к файлов - это не везение, сугубо вопрос времени. Если сделать скрипт, то даже с расчетом пары секунд на запрос, это 18 часов в худшем случае.

Я с механикой LFI не знаком, потому не знаю, можно ли ей читать все файлы. Если можно, то как на это ни посмотри, но запрет на доступ в /proc - странен, ввиду того, что ты мог качать другие файлы системы (т.е. логичней было б сильней урезать права, если уж на то пошло).

[Unknown]

Т.е., допустим, при попытке прочесть /proc/1/cmdline файл выдает 404?

[Unknown]

Обычно видно, если просканить сервер через nmap. Или можно попробовать узнать, подключившись по telnet на frp порт.