Rückblick: Was wir schon wissen
In Teil 1 haben wir LFI als „zu gutgläubigen Bibliothekar“ beschrieben: Eine Anwendung lädt jede Datei, die der Nutzer angibt. Wir haben gesehen, dass Angreifer mit ../
im Pfad Dateien außerhalb des vorgesehenen Verzeichnisses öffnen können – z. B. /etc/passwd
.
Jetzt schauen wir genauer:
- Welche Funktionen machen LFI möglich?
- Wie manipulieren Angreifer Pfade?
- Welche Tricks gibt es, um Filter zu umgehen?
1. Die gefährlichen Funktionen
In vielen Sprachen gibt es Funktionen, die Dateien laden oder ausführen.
In PHP
include()
/require()
→ binden Dateien ein, können Code ausführen.include_once()
/require_once()
→ wie oben, aber nur einmal pro Datei.file_get_contents()
→ liest den Inhalt einer Datei.fopen()
→ öffnet Dateien.
Beispiel
$page = $_GET["page"];
include($page);
Wenn der Angreifer ?page=about.php
aufruft, lädt die App about.php
.
Wenn er ?page=../../etc/passwd
aufruft, versucht die App /etc/passwd
einzubinden.
2. Directory Traversal
Das Herzstück von LFI ist Directory Traversal.
../
= eine Ebene nach oben.../../
= zwei Ebenen nach oben.
Wenn die Anwendung im Ordner /var/www/html/
läuft:
?file=../../etc/passwd
→ Pfad: /var/www/html/../../etc/passwd
→ Normalisiert: /etc/passwd
ASCII-Skizze:
/var/www/html/
├── index.php
├── about.php
└── contact.php
../../etc/passwd → /etc/passwd
3. Null Byte Injection (ältere Systeme)
In alten PHP-Versionen (vor 5.3.4) konnte man einen String mit %00
(Null-Byte) abschneiden.
Beispiel:
include($_GET["page"] . ".php");
Angreifer ruft auf:
?page=../../etc/passwd%00
- Anwendung hängt
.php
an →../../etc/passwd%00.php
- Null-Byte
%00
beendet den String → effektiv wird/etc/passwd
geladen.
Heute meist gefixt, aber historisch ein Klassiker.
4. Encoding-Tricks
Manche Entwickler filtern ../
, aber Angreifer können es verschleiern:
- URL-Encoding:
%2e%2e%2f
=../
- Doppelt encodiert:
%252e%252e%252f
=%2e%2e%2f
=../
- Unicode-Tricks:
%c0%ae%c0%ae%c0%af
So umgehen Angreifer simple Filter.
5. Wrapper in PHP
PHP kennt sogenannte Wrapper, mit denen man auf verschiedene Quellen zugreifen kann.
Beispiele:
php://filter
→ zum Filtern von Dateien (z. B. Base64-Encoding).?file=php://filter/convert.base64-encode/resource=config.php
Ergebnis: Der Quellcode vonconfig.php
wird Base64-codiert angezeigt – selbst wenn der Server PHP sonst ausführt.php://input
→ liest den Request-Body.data://
→ erlaubt eingebettete Daten.
Das macht LFI noch mächtiger.
6. Typische Angriffsketten
LFI allein bedeutet meist: Dateien lesen. Aber in Kombination entsteht mehr.
a) LFI + Sensitive Files
- Zugriff auf
/etc/passwd
→ Usernamen. - Zugriff auf
.env
oderconfig.php
→ Datenbank-Credentials.
b) LFI + Log Poisoning
- Angreifer sendet als
User-Agent
:<?php system($_GET["cmd"]); ?>
- Dieser Eintrag landet in
access.log
. - Mit
?file=../../logs/access.log
inkludiert → PHP-Code wird ausgeführt.
c) LFI + File Upload
- Angreifer lädt „image.jpg“ hoch, das in Wirklichkeit PHP enthält.
- Normaler Aufruf blockiert (weil Uploads in
/uploads/
liegen und nicht direkt ausgeführt werden). - Mit LFI →
?file=../../uploads/image.jpg
→ Datei wird als PHP interpretiert. - Ergebnis: Remote Code Execution (RCE).
7. Unterschiede in Betriebssystemen
Linux/Unix
- Trennzeichen:
/
- Ziel:
/etc/passwd
,/etc/shadow
Windows
- Trennzeichen:
\
oder/
- Ziel:
C:\Windows\win.ini
,C:\boot.ini
Angreifer probieren oft beide Varianten, um kompatibel zu sein.
8. Fehlermeldungen als Hinweise
Viele LFI-Bugs werden entdeckt, weil Entwickler Fehlermeldungen nicht unterdrücken.
Beispiel:
Warning: include(../../etc/passwd): failed to open stream: No such file or directory...
→ Verrät, dass die Anwendung include()
auf unkontrollierte Eingaben anwendet.
9. Realistische Teststrategie
Schritt 1 – Parameter finden
Achte auf Parameter wie ?page=
, ?file=
, ?include=
, ?template=
.
Schritt 2 – Traversal probieren
?page=../../../../etc/passwd
Schritt 3 – Alternative Encodings testen
?page=%2e%2e%2f%2e%2e%2fetc%2fpasswd
Schritt 4 – Wrapper nutzen
?page=php://filter/convert.base64-encode/resource=config.php
10. Typische Verteidigungs-Fehler
- Blacklist-Filter: Entwickler blocken nur
../
, Angreifer nutzen%2e%2e%2f
. - .php-Anhängsel: Entwickler hängen automatisch
.php
an – mit Null Byte Injection kann man das umgehen. - Nur Webroot prüfen: Viele glauben, Dateien außerhalb von
/var/www/html
seien sicher. Traversal beweist das Gegenteil.
Analogie: Tür mit Zahlenschloss
Ein Entwickler denkt: „Ich habe ein Zahlenschloss mit 4 Ziffern, also sicher.“
Aber Angreifer weiß: Er kann die Ziffern auch hexadezimal, doppelt encodiert oder mit Sonderzeichen eingeben.
So ist es mit LFI: Filter blockieren nur die offensichtliche Form, Angreifer nutzen kreative Kodierungen.
Was du bis hier mitnehmen solltest
- LFI basiert technisch auf unsicheren Funktionen wie
include()
,require()
,file_get_contents()
. - Angreifer nutzen Directory Traversal (
../
), Encodings und Wrapper, um Filter zu umgehen. - Null Byte Injection war ein Klassiker, heute meist gefixt.
- Mit LFI können Angreifer Dateien lesen – und mit Log Poisoning oder File Upload sogar Code ausführen.
- Fehlermeldungen und schwache Filter sind verräterisch.
Schreibe einen Kommentar