CVE-2023-6553

PHP File Inclusion führt zu RCE — Backup Migration Plugin

Plugin: Backup Migration (backup-backup) ≤ 1.3.7

CVSS: 9.8 (Kritisch)

CWE: CWE-98 — Unsachgemäße Kontrolle des Dateinamens für Include/Require-Anweisung

Authentifizierungsanforderung: Keine

Auswirkung: Remote Code Execution

---

1. Was ist diese Schwachstelle?

Backup Migration ist ein ziemlich beliebtes WordPress-Plugin (~90.000+ aktive Installationen), das Benutzern hilft, Sicherungskopien zu erstellen. Während des Backup-Prozesses läuft im Hintergrund eine Datei namens backup-heart.php - sie erhält Konfigurationsinformationen über HTTP-Header, um zu erfahren, welches Verzeichnis gesichert werden muss, wo sich die Konfigurationsdatei befindet usw.

Das Problem liegt darin, dass diese Datei den vom Client gesendeten HTTP-Headern vollständig vertraut, den Header-Wert direkt in den Dateipfad übernimmt und dann require_once() verwendet, um die Datei aus diesem Pfad zu laden. Ein Angreifer muss lediglich den Content-Dir-Header senden, der auf ein Verzeichnis mit bösartigem PHP-Code zeigt → der Server bindet diesen automatisch ein und führt ihn aus.

Es ist erwähnenswert, dass die Datei backup-heart.php keine Authentifizierung erfordert — sie prüft nur, ob die Anfragemethode POST ist, ohne irgendein Nonce oder Benutzerrechte zu verifizieren. Jeder im Internet kann eine Anfrage an sie senden.

⇒ Dies ist eine Zero-Click-Schwachstelle.

Attribut	Wert
CVE-ID	CVE-2023-6553
CVSS-Score	9.8 (Kritisch)
Plugin	backup-backup (Backup Migration) ≤ 1.3.7
Authentifizierung	Nicht erforderlich
Benutzerinteraktion	Keine (Zero-Click)
Behoben	Version 1.3.8

2. Hintergrundwissen

Datei-Inclusion in PHP

PHP verfügt über Funktionen wie include(), require(), require_once(), mit denen andere PHP-Dateien in das laufende Programm eingebunden werden. Wenn der Dateipfad, der an diese Funktionen übergeben wird, ohne Validierung aus Benutzereingaben stammt, kann ein Angreifer den Server zwingen, eine beliebige Datei einzubinden:

• LFI (Local File Inclusion): Lädt eine vorhandene Datei auf dem Server — zum Beispiel eine Logdatei, die mit PHP-Code "vergiftet" wurde.
• RFI (Remote File Inclusion): Lädt eine Datei von einem externen Server — erfordert allow_url_include=On (normalerweise standardmäßig deaktiviert).

Diese CVE fällt unter LFI — der Angreifer kontrolliert den Pfad, der an require_once() übergeben wird, und zeigt auf eine PHP-Datei, die der Angreifer auf den Server schreiben konnte.

Warum sind HTTP-Header gefährlich?

Viele Entwickler denken, HTTP-Header seien "interne" Metadaten, die nur dem Server und dem Client bekannt sind. In Wirklichkeit kontrollieren Angreifer 100% des Header-Inhalts — sie können jeden Header-Namen und -Wert festlegen. Headern zu vertrauen ist genau wie Formulareingaben zu vertrauen — es muss validiert werden.

define() und PHP-Konstanten

define('NAME', $value) erstellt eine Konstante, die in der gesamten Anwendung verwendet wird. Sobald sie per define erstellt wurde, kann der Wert nicht mehr geändert werden. Wenn $value von einem Angreifer stammt, ist jede Stelle, die diese Konstante verwendet, betroffen.

3. Quellcode-Analyse — Woher stammt die Schwachstelle?

Schritt 1: Den Sink finden

Ich begann damit, mit grep alle require- und include-Anweisungen im Plugin zu durchsuchen:

grep -rn "require\|include" includes/

Die Suchergebnisse lieferten viele require/include-Aufrufe. Beim Durchsehen waren die meisten include_once-Aufrufe in banner/misc.php und banner/views/index.php — diese gehören zum Admin-UI-Rendering-Code mit hartcodierten Pfaden, was sie nicht ausnutzbar macht.

Allerdings fielen mir 2 Zeilen in backup-heart.php auf:

includes/backup-heart.php:64:   define('BMI_INCLUDES', BMI_ROOT_DIR . 'includes');
includes/backup-heart.php:118:  require_once BMI_INCLUDES . '/bypasser.php';

Zeile 118 verwendet require_once mit der Konstante BMI_INCLUDES — wäre diese Konstante hartcodiert, wäre es sicher. Aber beim Blick auf Zeile 64 sieht man, dass BMI_INCLUDES aus einer anderen Konstante, BMI_ROOT_DIR, aufgebaut wird. Also müssen wir weitersuchen: Wo wird BMI_ROOT_DIR sein Wert zugewiesen?

Ich verwendete erneut grep, um das nachzuverfolgen:

grep -n "BMI_ROOT_DIR" includes/backup-heart.php

Ergebnisse:

Line 62: define('BMI_ROOT_DIR', $fields['content-dir']);
Line 64: define('BMI_INCLUDES', BMI_ROOT_DIR . 'includes');

Zeile 62 zeigt, dass BMI_ROOT_DIR seinen Wert aus $fields['content-dir'] bezieht. Dies ist eine Variable, kein fester Wert — wir müssen die Datei öffnen und sehen, was $fields enthält.

Schritt 2: Quellcode prüfen — Woher kommt $fields?

Ich öffnete backup-heart.php in VS Code bei Zeile 62:

// Line 62
define('BMI_ROOT_DIR', $fields['content-dir']);

// Line 64
define('BMI_INCLUDES', BMI_ROOT_DIR. 'includes');

Es ist deutlich zu sehen, dass $fields['content-dir'] direkt in define() einfließt. Nun müssen wir herausfinden, wo die Variable $fields zugewiesen wird:

// Lines 7-9: Prüft nur die POST-Methode
if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
    exit;
}

// Lines 30-33: Liest ALLE HTTP-Header aus der Anfrage
if (isFunctionEnabled('getallheaders')) {
    $fields= getallheaders();
}

// Lines 42-46: Setzt Header-Namen in Kleinbuchstaben
foreach ($fieldsas $key=> $value) {
    $buffer= $value;
    unset($fields[$key]);
    $fields[strtolower($key)] = $value;
}

An diesem Punkt wird die Ursache glasklar: $fields enthält alle HTTP-Header, die über getallheaders() abgerufen werden — vollständig vom Client kontrolliert. Es gibt kein wp_verify_nonce(), kein current_user_can(), keine Prüfung auf gültige Pfade — es wird lediglich die POST-Methode verifiziert und die Header direkt eingelesen.

Schritt 3: Angriffsablauf zusammengefasst

Angreifer sendet POST-Anfrage mit Header Content-Dir: /path/to/attacker/
    ↓
getallheaders() liest rohe Header → $fields['content-dir'] = "/path/to/attacker/"
    ↓
define('BMI_ROOT_DIR', "/path/to/attacker/")   ← keine Validierung
    ↓
define('BMI_INCLUDES', "/path/to/attacker/includes")
    ↓
require_once "/path/to/attacker/includes/bypasser.php"   ← führt PHP aus
    ↓
Angreifercode läuft mit www-data-Rechten → RCE

Zusammenfassung der Ursache: HTTP-Header → define() → require_once(), mit null Validierungsschritten dazwischen.

Schritt 4: Debugging mit Xdebug

Ich verwendete Xdebug + VS Code, um den Angriffsablauf visuell zu bestätigen. Ich setzte 2 Breakpoints bei Zeile 62 und Zeile 118 in backup-heart.php und sendete dann die Exploit-Anfrage mit curl.

Breakpoint 1 — Zeile 62:

Der Debugger hielt direkt bei define('BMI_ROOT_DIR', $fields['content-dir']) an. Die Erweiterung der Variable $fields im Variablenpanel zeigte ein Array mit 22 Elementen — das alle vom Client gesendeten HTTP-Header enthält. Insbesondere: