Teil 3 – Reale Beispiele und Auswirkungen von LFI

—

von

Stefan
in , ,

Warum Praxisbeispiele so wichtig sind

Theorie ist gut – aber erst in der Praxis zeigt sich, wie mächtig und gefährlich LFI wirklich ist. Viele Bug-Bounty-Reports und CVEs belegen: Mit einem simplen ../ im Pfad haben Angreifer Zugriff auf sensible Daten oder übernehmen ganze Systeme.

1. Klassiker: /etc/passwd

Was ist das?

Auf Unix/Linux-Systemen enthält /etc/passwd eine Liste aller Benutzerkonten. Jede Zeile beschreibt einen User:

root:x:0:0:root:/root:/bin/bash
alice:x:1001:1001:Alice:/home/alice:/bin/bash
  • root = Administrator
  • x = Passwort (in modernen Systemen ausgelagert in /etc/shadow)
  • uid/gid = IDs
  • home = Home-Verzeichnis

Warum gefährlich?

Allein schon die Information, welche Nutzer existieren, ist Gold wert für Angreifer.
Sie wissen sofort: „Ah, es gibt den User alice. Vielleicht kann ich ihr Passwort erraten.“

Typischer Angriff

http://example.com/?file=../../../../etc/passwd

Wenn das klappt, ist es ein klarer Beweis für LFI.

2. Konfigurationsdateien (Passwörter!)

LFI wird besonders gefährlich, wenn man an Konfigurationsdateien rankommt.

Beispiele

  • .env → oft in modernen Frameworks (Laravel, Symfony, Node.js). Enthält Datenbank-Logins, API-Keys, Geheimnisse.
  • config.php → in PHP-Projekten mit db_user, db_pass.
  • settings.py (Django) oder application.yml (Spring Boot).

Folge

Mit diesen Daten kann ein Angreifer die Datenbank übernehmen oder interne APIs missbrauchen.

3. Quellcode-Leaks

Wenn der Angreifer per LFI an Quellcode-Dateien kommt (.php, .js, .py), kann er:

  • Sicherheitslogik analysieren.
  • Geheimnisse im Code entdecken (z. B. API-Schlüssel).
  • Input-Validierungen verstehen und gezielt umgehen.

Beispiel

http://example.com/?file=../../config/config.php

Antwort:

<?php
$db_host = "localhost";
$db_user = "admin";
$db_pass = "SuperSecret123";
?>

Mit diesen Daten kann er direkt auf die Datenbank zugreifen.

4. Windows-Ziele

Unter Windows sind typische Testdateien:

  • C:\Windows\win.ini
  • C:\boot.ini

Beispiel-Inhalt von win.ini:

[fonts]
[extensions]
[mci extensions]

Nicht sensibel – aber der Beweis, dass LFI funktioniert.

5. Log Poisoning → von LFI zu RCE

Idee

  1. Angreifer schreibt PHP-Code in ein Logfile (z. B. als User-Agent).
  2. Mit LFI inkludiert er dieses Log.
  3. PHP führt den eingeschleusten Code aus.

Schritt-für-Schritt

Schritt 1 – Request mit bösartigem User-Agent:

GET / HTTP/1.1
Host: victim.com
User-Agent: <?php system($_GET['cmd']); ?>

Dieser String landet in access.log.

Schritt 2 – LFI aufrufen:

http://victim.com/?file=../../logs/access.log&cmd=id

Antwort:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

→ Remote Code Execution.

Warum gefährlich?

Aus einer simplen LFI wird eine vollständige Serverübernahme.

6. File Upload + LFI

Manche Seiten erlauben Uploads, aber filtern ausführbare Dateien wie .php.
Der Angreifer lädt shell.jpg hoch – mit PHP-Code im Inneren.

  • Normaler Zugriff: http://victim.com/uploads/shell.jpg → zeigt Bild, kein Code.
  • Mit LFI: http://victim.com/?file=../../uploads/shell.jpg → Datei wird eingebunden und als PHP interpretiert.

Ergebnis: Vollständige Remote Shell.

7. Fallbeispiele aus der Praxis

a) Bug-Bounty-Report: LFI in einem CMS

Ein populäres CMS nutzte ?template= zum Laden von Seiten.
Angreifer testete:

?template=../../../../etc/passwd

→ Erfolg.
Kurz darauf: Zugriff auf config.php → Datenbank-Passwort.
Mit SQL-Zugriff konnte er sich als Admin einloggen.

b) CVE-2018-7600 („Drupalgeddon 2“)

Eine bekannte Schwachstelle in Drupal erlaubte LFI in Kombination mit Remote Code Execution. Angreifer konnten durch manipulierte Pfade beliebige Dateien einbinden und PHP-Code ausführen.

c) IoT-Geräte

Viele Router-Webinterfaces hatten unsichere include()-Aufrufe. Angreifer konnten über LFI Passwörter und Konfigurationen der Geräte auslesen.

8. Typische Kombinationen

LFI ist selten „allein“. Oft kombiniert mit:

  • Directory Traversal → für Pfade.
  • Log Poisoning → für RCE.
  • File Upload → für RCE.
  • SQL Injection → LFI verrät Konfigurationsdatenbanken.
  • Command Injection → LFI zeigt Quellcode mit versteckten Schwachstellen.

9. Auswirkungen in Zahlen

  • Informationslecks: Datenbanken, API-Schlüssel, interne Strukturen.
  • Server-Übernahme: durch LFI → RCE.
  • Account Takeover: Zugriff auf Session-Files.
  • Kosten: Viele Bug-Bounty-Reports mit Belohnungen im 4- bis 5-stelligen Bereich.

Analogie: Schlüssel im Archiv

Erinnere dich an die Bibliotheks-Analogie. Mit einfachem LFI bekommst du Bücher, die du nicht lesen darfst.
Mit Log Poisoning oder File Upload findest du aber irgendwann den Generalschlüssel zum Tresor. Und damit kannst du alles öffnen.

Was du bis hier mitnehmen solltest

  • LFI ist praktisch ausnutzbar, nicht nur theoretisch.
  • Typische Ziele: /etc/passwd, .env, config.php, win.ini.
  • Gefährlich wird’s, wenn LFI mit Log Poisoning oder Uploads kombiniert wird → Remote Code Execution.
  • Zahlreiche reale Fälle zeigen: LFI ist ein Einfallstor für komplette Systemübernahmen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert