CVE-2025-4396 – Werkzeugkasten für zeitbasierte Blind-SQL-Injection in WordPress Relevanssi

Übersicht

Dieses Repository enthält einen praktischen Forschungs- und Validierungs-Werkzeugkasten für CVE-2025-4396, eine nicht authentifizierte zeitbasierte Blind-SQL-Injection, die das WordPress-Plugin Relevanssi über den cats-Parameter betrifft.

Das Projekt wurde für autorisierte Purple-Team-Einsätze entwickelt, um:

• die Ausnutzbarkeit kontrolliert zu validieren,
• verschiedene Angreifer-Taktiken zu demonstrieren,
• die Erkennungsabdeckung des SOCs zu messen,
• einen WordPress-Passwort-Hash realistisch zu extrahieren,
• und den Offline-Knack-Workflow nach der Wiederherstellung des Hashes zu automatisieren.

Das Repository enthält:

• ein Standard-Extraktionsskript,
• ein schnelleres Binärsuch-Extraktionsskript,
• und ein Hilfsskript, um den extrahierten WordPress 6.8+-Hash mit Hashcat vorzubereiten und zu knacken.

Haftungsausschluss
Dieses Projekt dient ausschließlich zu Bildungszwecken, zur defensiven Validierung und für autorisierte Sicherheitstests.
Verwenden Sie es nicht gegen Systeme, die Sie nicht besitzen oder für deren Bewertung Sie keine ausdrückliche schriftliche Genehmigung haben.

Testumgebung

• Server : Debian 11
• WordPress 6.9.1,
• Relevanssi-Plugins 4.24.4 (heruntergeladen von https://wordpress.org/plugins/relevanssi/advanced/),
• Proof of Concept (PoC) verwendet unter Kali Linux.

CVE-Beschreibung

CVE-2025-4396 ist eine SQL-Injection-Schwachstelle, die die Relevanssi-Suchfunktion in WordPress betrifft.

Im getesteten Szenario ist das Problem über den Suchworkflow erreichbar, genauer gesagt über den cats-Parameter.

Der anfällige Codepfad ermöglicht es, dass vom Angreifer kontrollierte Eingaben die vom Plugin generierte SQL-Abfrage beeinflussen.

Da der anfällige Endpunkt ohne vorherige Authentifizierung zugänglich ist, kann der Fehler von einem entfernten Angreifer ausgenutzt werden, um eine nicht authentifizierte SQL-Injection durchzuführen.

Die praktischen Auswirkungen umfassen:

• Manipulation von Datenbankabfragen,
• zeitbasierte Blind-SQL-Injection,
• Extraktion von sensiblen Daten wie Passwort-Hashes,
• und, abhängig von der Umgebung, mögliche Rechteausweitung durch Wiederherstellung gültiger Anmeldeinformationen.

Wie die Schwachstelle funktioniert

Grundursache

Die Schwachstelle besteht, weil eine vom Benutzer kontrollierte Eingabe aus einem suchbezogenen Parameter nicht sicher behandelt wird, bevor sie in eine SQL-Abfrage eingebunden wird.

In der Praxis bedeutet dies, dass ein Angreifer SQL-Ausdrücke in die Backend-Abfragelogik einschleusen und die Datenbank zwingen kann, zusätzliche Bedingungen auszuwerten.

Warum es blind ist

Die Schwachstelle wird im blinden Modus ausgenutzt, was bedeutet, dass die Anwendung SQL-Fehler oder rohe Datenbankergebnisse nicht direkt anzeigt.

Statt das Abfrageergebnis von der Seite zu lesen, stellt der Angreifer der Datenbank eine Reihe von Wahr/Falsch-Fragen und beobachtet einen Nebeneffekt:

• Wenn die Bedingung wahr ist, schläft die Datenbank für einige Sekunden,
• Wenn die Bedingung falsch ist, kommt die Antwort sofort zurück.

Warum es zeitbasiert ist

Die Ausnutzung stützt sich auf SQL-Funktionen wie SLEEP(), um einen messbaren Unterschied in der Serverantwortzeit zu erzeugen.

Dies ermöglicht es einem Angreifer, Daten abzuleiten, ohne sie jemals direkt zu sehen.

Zum Beispiel kann der Angreifer Fragen stellen wie:

• „Ist das erste Zeichen gleich $?“
• „Ist der ASCII-Wert des zweiten Zeichens größer als 77?“
• „Stimmen die ersten N Zeichen mit diesem Muster überein?“

Durch Wiederholen dieses Prozesses kann der Angreifer einen vollständigen Hash Zeichen für Zeichen rekonstruieren.

Wie die Ausnutzung funktioniert

Standard-Extraktionslogik

Der Standardansatz iteriert durch einen bekannten Zeichensatz und testet jeden Kandidaten einzeln.

Für jede Position im Ziel-Hash:

1. Erstelle eine SQL-Bedingung, die auf ein Zeichen abzielt.
2. Löse eine Serververzögerung nur aus, wenn die Vermutung korrekt ist.
3. Messe die Antwortzeit.
4. Sende dieselbe Anfrage erneut, um Fehlalarme durch Netzwerk-Jitter zu reduzieren.
5. Füge das bestätigte Zeichen an den extrahierten Hash an.
6. Gehe zur nächsten Position.

Diese Methode ist einfach und zuverlässig, aber relativ langsam, da sie viele Anfragen pro Zeichen erfordern kann.

Binärsuch-Extraktionslogik

Der schnellere Ansatz verwendet die Binärsuche auf dem ASCII-Wert jedes Zeichens.

Statt zu fragen:

• „Ist das Zeichen gleich a?“
• „Ist das Zeichen gleich b?“
• „Ist das Zeichen gleich c?“

fragt er:

• „Ist der ASCII-Wert größer als 79?“
• „Ist er größer als 55?“
• „Ist er größer als 43?“

Dies halbiert den Suchraum bei jeder Anfrage und reduziert die Anzahl der HTTP-Anfragen drastisch.

Praktisches Ergebnis

Der Angriff ermöglicht es dem Betreiber, den user_pass-Wert aus wp_users zu extrahieren, typischerweise für eine gewählte WordPress-Benutzer-ID wie:

• 1 für den Standard-Administrator,
• oder eine andere ID, die über die Befehlszeile übergeben wird.

In neueren WordPress-Versionen kann dieser Wert die neue WordPress 6.8+-Passwort-Pipeline verwenden, die Folgendes kombiniert:

• eine Vor-Hashing-Stufe mit HMAC-SHA384,
• Base64-Kodierung,
• und einen finalen bcrypt-Hash.

Enthaltene Skripte

1. CVE_2025_4396.py

Dies ist das Standard-Extraktionsskript.

Zweck:

Es führt eine klassische zeitbasierte Blind-SQL-Injection durch und extrahiert den Ziel-Hash Zeichen für Zeichen mittels einer linearen Suche über einen festen Zeichensatz.

Hauptmerkmale:

• einfach und leicht verständlich,
• zuverlässig in stabilen Umgebungen,
• Doppelverifizierungslogik zur Reduzierung von Fehlalarmen,
• nützlich als Basis für Erkennungsentwicklung und PoC-Demonstrationen.

Funktionsweise:

Für jede Zeichenposition:

• iteriert es durch einen vordefinierten Zeichensatz,
• erstellt eine SQL-Bedingung, die einem einzelnen Zeichen entspricht,
• wartet auf die Serverantwort,
• und bestätigt den Treffer mit einer zweiten Anfrage.

Anforderungen:

• python3
• requests
• urllib3

Installation:

pip3 install requests urllib3

Verwendung:

python3 CVE_2025_4396.py -t "https://target.local/?s=test&cats=" -u 1 -s 3 -v

Arguments :
    -t, --target : anfällige Ziel-URL einschließlich des injizierbaren Parameters
    -u, --userid : anzugreifende WordPress-Benutzer-ID
    -s, --sleep : Schwellwert für die Verzögerung in Sekunden
    -v, --verbose : Debug-Logging aktivieren

2. CVE_2025_4396_Stealth.py

Dies ist die Binärsuch-Version.

Zweck:

Es verfolgt das gleiche Extraktionsziel wie das Standard-Skript, ersetzt jedoch die lineare Zeichen-für-Zeichen-Suche durch eine Binärsuche auf ASCII-Werte.

Hauptmerkmale:

• deutlich weniger HTTP-Anfragen,
• geringerer Netzwerk-Fußabdruck,
• enthält dennoch einen Doppelprüfungsschritt zur Vermeidung von Fehlalarmen.

Funktionsweise:

Für jede Position:

• Definiere einen druckbaren ASCII-Bereich.
• Teste den Mittelpunkt.
• Frage, ob das Zielzeichen größer als dieser Mittelpunkt ist.
• Reduziere den Bereich entsprechend.
• Fahre fort, bis das genaue Zeichen identifiziert ist.

Anforderungen:

• python3
• requests
• urllib3

Installation:

pip3 install requests urllib3

Verwendung:

python3 CVE_2025_4396_Stealth.py -t "https://target.local/?s=test&cats=" -u 1 -s 3 -v

Wann verwenden:

• Das Ziel ist als anfällig bestätigt,
• Die Latenz ist stabil genug,
• und das Ziel ist die Reduzierung des Anfragevolumens.

Offline-Hash-Knack-Workflow

Sobald der Passwort-Hash aus WordPress extrahiert wurde, besteht der nächste Schritt darin, ihn offline zu knacken.

Hinweise zum Hashing in WordPress 6.8+. Im getesteten Workflow kann der extrahierte Wert wie folgt aussehen:

$wp$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Für Hashcat ist der verwendbare bcrypt-Teil:

$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Dieser bcrypt wird jedoch nicht direkt auf das rohe Passwort angewendet. WordPress wendet zunächst eine Vorverarbeitungsstufe an:

• Trimmen im PHP-Stil am Kandidatenpasswort,
• HMAC-SHA384 unter Verwendung des Schlüssels wp-sha384,
• Base64-Kodierung des resultierenden Digests,
• dann bcrypt-Verifizierung.

Warum ein Vor-Hashing-Schritt notwendig ist

Das bedeutet, dass eine normale Wortliste nicht direkt an Hashcat gesendet werden kann, wenn Sie die genaue WordPress 6.8+-Logik reproduzieren möchten.

Stattdessen muss jedes Kandidatenpasswort zunächst in seine WordPress-kompatible Vor-Hash-Darstellung transformiert werden.

Das Repository enthält auch ein "Hilfsskript", das:

• den extrahierten Hash als Argument akzeptiert,
• bei Bedarf das $wp$-Präfix entfernt,
• die bereitgestellte Wortliste vorverarbeitet,
• das transformierte Wörterbuch generiert,
• optional eine Mapping-Datei erstellt,
• Hashcat automatisch startet,
• den wiederhergestellten Vor-Hash zurück zum ursprünglichen Klartext-Passwort auflöst.

Typischer Workflow

Hash extrahieren:

• Beispielergebnis : $wp$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Knack-Umgebung vorbereiten:

• python3
• hashcat und im PATH verfügbar

Führen Sie Auto_Crack.py aus:

python3 Auto_Crack.py -H '\$wp\$2y\$10\$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.' -w /usr/share/wordlists/rockyou.txt

Wir müssen "$" mit "\" escapen -> Bash-Kompatibilität

SOC-Erkennungsleitfaden

Der folgende Erkennungsinhalt kann von SOC-Teams verwendet werden, um Ausnutzungsversuche zu identifizieren und den defensiven Reifegrad zu messen.

Sigma-Erkennung

title: Potential Time-Based Blind SQLi (CVE-2025-4396 Relevanssi)
id: 5a8a1c93-5c74-4b5b-a620-8e1c3e41ab5d
status: experimental
description: Detects HTTP GET requests containing typical Time-Based Blind SQL injection payloads often used to exploit CVE-2025-4396 in the WordPress Relevanssi plugin (bypassing comma filters).
author: n3fhara
date: 2026-03-18
tags:
    - attack.initial_access
    - attack.t1190
    - cve.2025-4396
logsource:
    category: webserver
detection:
    selection_endpoint:
        cs-uri-query|contains:
            - 's='
            - 'cats='
            - 'tags='
    selection_payload:
        cs-uri-query|contains:
            - 'SLEEP('
            - 'WAITFOR'
            - 'SUBSTRING('
            - 'ASCII('
            - 'LENGTH('
    selection_bypass_indicators:
        cs-uri-query|contains:
            - 'FROM'
            - 'FOR 1'
            - '*('
    condition: selection_endpoint and selection_payload and selection_bypass_indicators
falsepositives:
    - Highly unlikely. Legitimate search queries should not contain SQL functions.
level: high

Suricata-Erkennung

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET EXPLOIT WordPress Relevanssi SQLi Attempt (CVE-2025-4396)"; flow:established,to_server; content:"GET"; http_method; content:"cats="; http_uri; pcre:"/(cats|tags)=.*(SLEEP|WAITFOR)%28.*(%2A|\*).*SUBSTRING/i"; classtype:web-application-attack; sid:1000001; rev:1; metadata:created_at 2026_03_18, cve CVE_2025_4396;)

SPLUNK-Erkennung

index=web_logs sourcetype=access_combined 
| regex uri_query="(?i)cats=|tags="
| stats count as request_count, avg(response_time) as avg_time, max(response_time) as max_time, dc(uri_query) as unique_payloads by clientip
| where request_count > 20 AND max_time > 2000
| sort - max_time

KQL-Erkennung

url.query : (*cats=* OR *tags=* OR *s=*) AND url.query : (*SLEEP* OR *WAITFOR* OR *SUBSTRING* OR *ASCII*) AND url.query : (*FROM* OR *FOR* OR *%2A*)

EQL-Erkennung

sequence by source.ip with maxspan=1m
  [network where url.path == "/" and url.query : "*cats=*" and event.duration > 2000000000]
  [network where url.path == "/" and url.query : "*cats=*" and event.duration > 2000000000]
  [network where url.path == "/" and url.query : "*cats=*" and event.duration > 2000000000]

Erkennungslücken und Empfehlungen

Die obigen Basis-Erkennungen sind gut für nicht verschleierte Ausnutzung, werden jedoch schwächer, wenn ein Betreiber fortschrittlichere Taktiken einführt.

Die SOC-Sichtbarkeit verschlechtert sich, wenn der Angreifer beginnt, Folgendes zu verwenden:

• alternative SQL-Funktionen anstelle der offensichtlichen,
• URL-Kodierung und kommentarbasierte Verschleierung,
• reduziertes Anfragevolumen durch Binärsuche,
• Jitter und Low-and-Slow-Timing,
• Proxy-Rotation,
• Browser-Imitation.

Zusätzliche Erkennungsideen für das SOC:

• Erkennen von ungewöhnlich langsamen Suchverkehr,
• Überwachen von Anfragen an den WordPress-Such-Endpunkt, bei denen:
  • Antwortzeiten wiederholt erhöht sind,
  • derselbe Client viele Suchanfragen durchführt,
  • oder derselbe Endpunkt im Laufe der Zeit abnormale Latenzmuster zeigt.
• Alarmieren bei Suchparametern, die codierte Operatoren enthalten,
• Selbst wenn keine offensichtlichen SQL-Schlüsselwörter sichtbar sind, Suchparameter, die Kombinationen enthalten von:
  • codierten Vergleichsoperatoren,
  • verdächtiger Klammerndichte,
  • wiederholter numerischer Logik,
  • oder stark URL-codierten Abfragezeichenfolgen.
• Korrelieren nach Endpunkt, nicht nur nach Quell-IP,
• Wenn der Angreifer Proxys rotiert, wird die IP-Korrelation schwach. Die Erkennung sollte sich auch konzentrieren auf:
  • wiederholten Zugriff auf denselben Endpunkt,
  • wiederholte verzögerte Antworten,
  • oder wiederholte fehlerhafte Suchanfragen, die auf dieselbe WordPress-Seite abzielen.
• Verwenden Sie verhaltensbasierte Erkennung mit langen Zeitfenstern:
  • 30 Minuten,
  • 1 Stunde,
  • oder mehrstündige Fenster.
• Überwachen Sie datenbankseitig langsame Abfragen

Repository-Struktur

.
├── CVE_2025_4396.py
├── CVE_2025_4396_Stealth.py
├── Auto_Crack.py
├── README.md
└── relevanssi.4.24.4.zip

Rechtlicher Hinweis

Nur in Umgebungen verwenden, in denen Sie ausdrücklich zum Testen berechtigt sind. Die Autoren und Mitwirkenden übernehmen keine Haftung für Missbrauch.

Haftungsausschluss
Dieses Projekt wird ausschließlich zu Bildungszwecken, zur defensiven Validierung und für autorisierte Sicherheitstests bereitgestellt.
Verwenden Sie es nicht gegen Systeme, die Sie nicht besitzen oder für deren Bewertung Sie keine ausdrückliche schriftliche Genehmigung haben.