StoryChief <= 1.0.42 - Nicht authentifizierter beliebiger Datei-Upload
🚨 StoryChief <= 1.0.42 — Nicht authentifizierter beliebiger Datei-Upload (CVE-2025-7441)
ℹ️ Zusammenfassung
StoryChief (WordPress-Plugin) bis einschließlich Version 1.0.42 weist eine kritische, nicht authentifizierte Schwachstelle für beliebigen Datei-Upload über den REST-Endpunkt /wp-json/storychief/webhook auf. Ein Angreifer kann das Plugin dazu veranlassen, eine vom Angreifer kontrollierte Remote-Ressource (z. B. eine Webshell) abzurufen und im Uploads-Verzeichnis der Website zu speichern, was in vielen Standard-WordPress-Installationen die Ausführung von entferntem Code ermöglicht.
CVE: CVE-2025-7441
CVSS: 9.8 (Kritisch)
💥 Auswirkungen
Nicht authentifizierter Remote-Datei-Upload nach wp-content/uploads/YYYY/MM/.
Möglichkeit zur Remote-Code-Ausführung, wenn die hochgeladene Datei ausführbar ist (z. B. PHP).
Eine vollständige Kompromittierung der Website ist möglich, wenn WordPress so konfiguriert ist, dass es hochgeladenes PHP im Dokumentstammverzeichnis ausführt.
🧩 Grundursache der Schwachstelle
Das Plugin akzeptiert ein eingehendes JSON-Payload (Publish-Ereignis), das ein Feld featured_image -> data -> sizes -> full enthält, das auf eine beliebige URL verweist. StoryChief führt keine ausreichende Dateityp-/Inhaltsvalidierung durch und schränkt die URL-Quelle nicht ein. Dadurch kann das Plugin die Remote-Ressource abrufen und im Uploads-Verzeichnis der Website speichern. Es fehlt eine ausreichende Validierung, um das Speichern von Dateien mit ausführbarem Code zu verhindern.
🛠️ Exploit-Skript – was es tut (Zuordnung zur Schwachstelle)
Dieser Abschnitt erklärt das Exploit-Skript (separat bereitgestellt) auf hoher Ebene und ordnet jedes wichtige Verhalten der zugrunde liegenden Schwachstelle zu.
Zielnormalisierung – hängt /wp-json/storychief/webhook an, wenn eine Site-Root angegeben wird.
Shell-URL-Validierung – prüft, ob die Remote-URL erreichbar ist (HEAD/GET oder curl).
Dateinamensextraktion – verwendet den Basisnamen der Remote-URL, um den endgültigen Upload-Dateinamen abzuleiten.
Payload-Konstruktion – platziert die vom Angreifer kontrollierte URL in data.featured_image.data.sizes.full, um das Plugin zum Abrufen und Speichern der Datei zu zwingen.
HMAC-Signierung (optional) – berechnet meta.mac (HMAC-SHA256) mit einem optionalen Hex-Schlüssel; einige Server ignorieren dies oder verlangen es.
Zustellung – verwendet requests mit Wiederholungen/Backoff oder curl als Fallback, unterstützt benutzerdefinierte Header, Proxys und --no-verify.
Antwortverarbeitung – parst JSON-Antworten auf permalink/id-Schlüssel, um Erfolg zu erkennen; andernfalls wird ein Fehler gemeldet.
Ausgabe – gibt bei Erfolg den erwarteten Uploads-Pfad aus: wp-content/uploads/YYYY/MM/.
🖼️ Anforderungen an die Shell-Datei (kritisch)
Bei Verwendung einer .php-Remote-Datei (z. B.: https://attacker.example/shell.php) muss die Datei einen gültigen Bild-Header (Magic Bytes) enthalten, damit sie vom Plugin oder von der Bildverarbeitung als Bild behandelt/akzeptiert wird. Wichtige Punkte:
Verwenden Sie einen Polyglot-Ansatz: Die Datei sollte mit gültigen Bild-Magic-Bytes beginnen (z. B. JPEG, PNG oder GIF), damit naive Prüfungen und Bildhandler sie akzeptieren, während sie gleichzeitig das PHP-Payload in einem Abschnitt enthält, der unverändert auf der Festplatte verbleibt.
Häufige Bild-Magic-Bytes:
JPEG: 0xFF 0xD8 0xFF
PNG: 0x89 0x50 0x4E 0x47
GIF: ASCII "GIF89a" oder "GIF87a"
Verlassen Sie sich nicht nur auf Dateiname/Erweiterung. Viele Plugins prüfen den Dateiinhalt oder verwenden Bibliotheken (GD, ImageMagick), die die Bildintegrität verifizieren.
Umgebungsabhängig: Einige Server validieren oder kodieren Bilder weiter, wodurch injizierter Code entfernt werden kann. Testen Sie zuerst in einer autorisierten Umgebung.
Ethische Erinnerung: Veröffentlichen Sie hier KEINEN funktionierenden Webshell-Code. Erstellen und testen Sie solche Dateien nur in autorisierten Umgebungen.
▶️ Ausführung (Beispiele)
Ersetzen Sie Platzhalter durch autorisierte Ziele. Alle folgenden Beispiele verwenden eine .php-Remote-Shell-URL.
"[-] Error: shell URL is not reachable (not HTTP 200)"
"[-] Error: request failed"
"[-] Error: upload failed or endpoint returned non-JSON/HTML"
🔎 Erkennung & Kompromittierungsindikatoren (IoC)
Unerwartete POST-Anfragen an /wp-json/storychief/webhook von unbekannten IPs.
Neue Dateien in wp-content/uploads/// mit PHP- oder Bild-Erweiterungen, die eingebetteten Code enthalten.
Webserver-Logs, die ausgehende GET-Anfragen an angreiferkontrollierte Domains gefolgt von Zugriffen auf hochgeladene Dateien zeigen.
Verdächtige Bilddateien mit angehängtem oder eingebettetem Nicht-Bild-Inhalt.
🛡️ Schadensbegrenzung & Behebung
Kurzfristig:
Aktualisieren Sie StoryChief sofort auf eine gepatchte Version, sobald diese verfügbar ist.
Blockieren oder beschränken Sie /wp-json/storychief/webhook über WAF- oder Serverregeln.
Beschränken Sie ausgehende Abrufe des Servers (Egress) auf nicht vertrauenswürdige Domains.
Anleitung für Entwickler:
Validieren Sie Dateitypen und -inhalte nach jedem Remote-Abruf; verifizieren Sie Bilder mit sicheren Parsern und lehnen Sie ungültige Dateien ab.
Erfordern Sie eine Authentifizierung für Webhooks, die serverseitige Downloads oder Dateierstellung auslösen.
Stellen Sie sicher, dass die HMAC-/Signaturverifizierung implementiert und erzwungen wird.
Speichern Sie hochgeladene Inhalte außerhalb des Web-Stammverzeichnisses oder deaktivieren Sie die Ausführung hochgeladener Dateien in wp-content/uploads (Webserver-Regeln).
⚠️ Einschränkungen & Hinweise
Der Exploit-Erfolg hängt von der Serverkonfiguration, den Bildverarbeitungsbibliotheken und den Ausführungsrichtlinien des Webservers ab.
Server, die Bilder erneut verarbeiten oder kodieren, können injizierte Payloads entfernen.
Wenn das Plugin Signaturen überprüft, kann die Angabe eines falschen mac zur Ablehnung führen.
🤝 Verantwortungsvolle Nutzung
Dieses Dokument richtet sich an Verteidiger und autorisierte Tester. Verwenden Sie diese Techniken NICHT gegen Systeme, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Testgenehmigung haben. Nicht autorisierte Ausnutzung ist illegal und unethisch.
Wenn Sie das Problem an einen Anbieter oder Website-Betreiber melden, fügen Sie Reproduktionsdetails, sichere Behebungsschritte und vorgeschlagene Korrekturen bei.