CVE-2025-4396 - Toolkit per la SQL Injection Blind Basata sul Tempo in WordPress Relevanssi

Panoramica

Questa repository contiene un toolkit pratico di ricerca e validazione per CVE-2025-4396, una SQL Injection Blind basata sul tempo non autenticata che colpisce il plugin WordPress Relevanssi tramite il parametro cats.

Il progetto è stato realizzato per esercitazioni Purple Team autorizzate al fine di:

• validare la sfruttabilità in modo controllato,
• dimostrare diversi livelli di tradecraft dell'attaccante,
• misurare la copertura di rilevamento del SOC,
• estrarre un hash della password WordPress in modo realistico,
• e automatizzare il flusso di lavoro di cracking offline una volta recuperato l'hash.

La repository include:

• uno script di estrazione standard,
• uno script di estrazione più veloce basato su ricerca binaria,
• e uno script di supporto per preparare e craccare con Hashcat l'hash WordPress 6.8+ estratto.

Disclaimer
Questo progetto è fornito esclusivamente a scopo didattico, di validazione difensiva e di test di sicurezza autorizzati.
Non utilizzarlo contro sistemi che non possiedi o per i quali non hai esplicita autorizzazione scritta a valutare.

Ambiente di Test

• Server : Debian 11
• WordPress 6.9.1,
• plugin Relevanssi 4.24.4 (scaricato da https://wordpress.org/plugins/relevanssi/advanced/),
• POC utilizzato dal sistema operativo Kali Linux.

Descrizione della CVE

CVE-2025-4396 è una vulnerabilità di SQL Injection che colpisce la funzionalità di ricerca Relevanssi in WordPress.

Nello scenario testato, il problema è raggiungibile tramite il flusso di ricerca e più specificamente attraverso il parametro cats. Il percorso di codice vulnerabile consente a input controllati dall'attaccante di influenzare la query SQL generata dal plugin.

Poiché l'endpoint vulnerabile è accessibile senza autenticazione preventiva, la falla può essere sfruttata da un attaccante remoto per eseguire una SQL injection non autenticata.

L'impatto pratico include:

• manipolazione delle query del database,
• SQL Injection Blind basata sul tempo,
• estrazione di dati sensibili come gli hash delle password,
• e, a seconda dell'ambiente, possibile escalation dei privilegi tramite il recupero di credenziali valide.

Come Funziona la Vulnerabilità

Causa principale

La vulnerabilità esiste perché l'input controllato dall'utente proveniente da un parametro correlato alla ricerca non viene gestito in modo sicuro prima di essere incorporato in una query SQL.

In pratica, ciò significa che un attaccante può iniettare espressioni SQL nella logica delle query del backend e costringere il database a valutare condizioni aggiuntive.

Perché è Blind

La vulnerabilità viene sfruttata in modalità blind (cieca), il che significa che l'applicazione non mostra direttamente errori SQL o risultati grezzi del database.

Invece di leggere l'output della query dalla pagina, l'attaccante pone al database una serie di domande vero/falso e osserva un effetto collaterale:

• se la condizione è vera, il database resta in pausa per alcuni secondi,
• se la condizione è falsa, la risposta viene restituita immediatamente.

Perché è basata sul tempo

Lo sfruttamento si basa su funzioni SQL come SLEEP() per creare una differenza misurabile nel tempo di risposta del server.

Ciò consente a un attaccante di dedurre i dati senza mai vederli direttamente.

Ad esempio, l'attaccante può porre domande come:

• "Il primo carattere è uguale a $?"
• "Il valore ASCII del secondo carattere è maggiore di 77?"
• "I primi N caratteri corrispondono a questo modello?"

Ripetendo questo processo, l'attaccante può ricostruire un intero hash carattere per carattere.

Come Funziona lo Sfruttamento

Logica di estrazione standard

L'approccio standard scorre un set di caratteri noto e testa ogni candidato uno per uno.

Per ogni posizione nell'hash target:

1. Costruire una condizione SQL che punta a un carattere.
2. Attivare un ritardo del server solo se l'ipotesi è corretta.
3. Misurare il tempo di risposta.
4. Inviare nuovamente la stessa richiesta per ridurre i falsi positivi causati dal jitter di rete.
5. Aggiungere il carattere confermato all'hash estratto.
6. Passare alla posizione successiva.

Questo metodo è semplice e affidabile, ma relativamente lento perché può richiedere molte richieste per carattere.

Logica di estrazione con ricerca binaria

L'approccio più veloce usa la ricerca binaria sul valore ASCII di ogni carattere.

Invece di chiedere:

• "Il carattere è uguale a a?"
• "Il carattere è uguale a b?"
• "Il carattere è uguale a c?"

chiede:

• "Il valore ASCII è maggiore di 79?"
• "È maggiore di 55?"
• "È maggiore di 43?"

Questo divide lo spazio di ricerca a metà a ogni richiesta e riduce drasticamente il numero di richieste HTTP.

Risultato pratico

L'attacco consente all'operatore di estrarre il valore user_pass da wp_users, tipicamente per un ID utente WordPress scelto come:

• 1 per l'amministratore predefinito,
• o un altro ID passato da riga di comando.

Nelle versioni recenti di WordPress, questo valore può utilizzare il nuovo pipeline di password WordPress 6.8+, che combina:

• una fase di pre-hashing che usa HMAC-SHA384,
• codifica Base64,
• e un hash finale bcrypt.

Script Inclusi

1. CVE_2025_4396.py

Questo è lo script di estrazione standard.

Scopo :

Esegue una classica SQL Injection Blind basata sul tempo ed estrae l'hash target carattere per carattere usando una ricerca lineare su un charset fisso.

Caratteristiche principali :

• semplice e facile da capire,
• affidabile in ambienti stabili,
• logica di doppia verifica per ridurre i falsi positivi,
• utile come base di partenza per l'ingegneria dei rilevamenti e per dimostrazioni di PoC.

Come funziona :

Per ogni posizione del carattere:

• scorre un set di caratteri predefinito,
• costruisce una condizione SQL corrispondente a un singolo carattere,
• attende la risposta del server,
• e conferma il successo con una seconda richiesta.

Requisiti :

• python3
• requests
• urllib3

Installazione :

pip3 install requests urllib3

Utilizzo :

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

Arguments :
    -t, --target : vulnerable target URL including the injectable parameter
    -u, --userid : WordPress user ID to target
    -s, --sleep : sleep threshold in seconds
    -v, --verbose : enable debug logging

2. CVE_2025_4396_Stealth.py

Questa è l'edizione con ricerca binaria.

Scopo :

Esegue lo stesso obiettivo di estrazione dello script standard, ma sostituisce la ricerca lineare carattere per carattere con una ricerca binaria sui valori ASCII.

Caratteristiche principali :

• numero significativamente inferiore di richieste HTTP,
• impronta di rete ridotta,
• include comunque una fase di doppio controllo per prevenire falsi positivi.

Come funziona :

Per ogni posizione:

• Definire un intervallo ASCII stampabile.
• Testare il punto medio.
• Chiedere se il carattere target è maggiore di quel punto medio.
• Ridurre l'intervallo di conseguenza.
• Continuare finché non viene identificato il carattere esatto.

Requisiti :

• python3
• requests
• urllib3

Installazione :

pip3 install requests urllib3

Utilizzo :

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

Quando usarlo :

• il target è confermato vulnerabile,
• la latenza è sufficientemente stabile,
• e l'obiettivo è ridurre il volume delle richieste.

Flusso di lavoro per il cracking offline dell'hash

Una volta estratto l'hash della password da WordPress, il passo successivo è craccarlo offline.

Note sull'hashing di WordPress 6.8+. Nel flusso di lavoro testato, il valore estratto può apparire come:

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

Per Hashcat, la porzione bcrypt utilizzabile è:

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

Tuttavia, questo bcrypt non viene applicato direttamente alla password grezza. WordPress applica prima una fase di pre-elaborazione:

• trim in stile PHP sulla password candidata,
• HMAC-SHA384 usando la chiave wp-sha384,
• codifica Base64 del digest risultante,
• quindi verifica bcrypt.

Perché è necessario un passaggio di pre-hashing

Ciò significa che una wordlist normale non può essere inviata direttamente a Hashcat se si vuole riprodurre l'esatta logica di WordPress 6.8+.

Invece, ogni password candidata deve essere prima trasformata nella sua rappresentazione pre-hash compatibile con WordPress.

La repository include anche uno script "helper" che:

• accetta l'hash estratto come argomento,
• rimuove il prefisso $wp$ quando necessario,
• pre-elabora la wordlist fornita,
• genera il dizionario trasformato,
• crea opzionalmente un file di mappatura,
• avvia Hashcat automaticamente,
• riconduce il pre-hash recuperato alla password in chiaro originale.

Flusso di lavoro tipico

Estrarre l'hash :

• Esempio di risultato : $wp$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Preparare l'ambiente di cracking :

• python3
• hashcat disponibile nel PATH

Eseguire Auto_Crack.py :

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

We need to escape "$" with "\" -> bash compatibility

Linee guida per il rilevamento SOC

Il seguente contenuto di rilevamento può essere utilizzato dai team SOC per identificare tentativi di sfruttamento e misurare la maturità difensiva.

Rilevamento Sigma

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

Rilevamento Suricata

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;)

Rilevamento SPLUNK

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

Rilevamento KQL

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*)

Rilevamento EQL

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]

Lacune di rilevamento e raccomandazioni

I rilevamenti di base sopra riportati sono buoni per sfruttamento non offuscato, ma diventano più deboli quando un operatore introduce tecniche più avanzate.

La visibilità del SOC si riduce quando l'attaccante inizia a usare:

• funzioni SQL alternative invece di quelle ovvie,
• codifica URL e offuscamento basato su commenti,
• volume di richieste ridotto tramite ricerca binaria,
• jitter e tempistiche low-and-slow,
• rotazione dei proxy,
• impersonificazione del browser.

Ulteriori idee di rilevamento per il SOC :

• Rilevare traffico di ricerca insolitamente lento,
• Monitorare le richieste all'endpoint di ricerca di WordPress in cui:
  • i tempi di risposta sono ripetutamente elevati,
  • lo stesso client esegue molte richieste di ricerca,
  • o lo stesso endpoint mostra pattern di latenza anomali nel tempo.
• Generare alert su parametri di ricerca contenenti operatori codificati,
• Anche se non sono visibili parole chiave SQL ovvie, parametri di ricerca contenenti combinazioni di:
  • operatori di confronto codificati,
  • densità sospetta di parentesi,
  • logica numerica ripetuta,
  • o stringhe di query pesantemente codificate in URL.
• Correlare per endpoint, non solo per IP sorgente,
• Se l'attaccante ruota i proxy, la correlazione per IP diventa debole. Il rilevamento dovrebbe concentrarsi anche su:
  • accessi ripetuti allo stesso endpoint,
  • risposte ritardate ripetute,
  • o query di ricerca malformate ripetute che puntano alla stessa pagina WordPress.
• Usare rilevamento comportamentale a finestra lunga:
  • 30 minuti,
  • 1 ora,
  • o finestre di più ore.
• Monitorare le query lente lato database.

Struttura della repository

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

Avviso legale

Utilizzare solo in ambienti in cui si è esplicitamente autorizzati a testare. Gli autori e i contributori non si assumono alcuna responsabilità per un uso improprio.

Disclaimer
Questo progetto è fornito esclusivamente a scopo didattico, di validazione difensiva e di test di sicurezza autorizzati.
Non utilizzarlo contro sistemi che non possiedi o per i quali non hai esplicita autorizzazione scritta a valutare.