soltanali0/cve-2024-12877-exploitDidattico demo di exploit CVE-2024-12877 per l'iniezione di oggetti PHP nel plugin GiveWP di WordPress. Include analisi della causa principale, tecniche di bypass delle regex e pratiche di sfruttamento sicure.
Settimana 66 | Autore: Ali Soltani (soltanali0)
Benvenuti alla Settimana 66 della serie GO-TO CVE, dove analizziamo le vulnerabilità, esaminiamo le cause profonde e dimostriamo tecniche pratiche di sfruttamento in un contesto educativo e sicuro.
CVE-2024-12877 è una vulnerabilità di PHP Object Injection in GiveWP, uno dei plugin di donazione WordPress più utilizzati. L'uso non sicuro di unserialize() su input controllati dall'utente consente agli attaccanti di attivare metodi magici PHP (come __wakeup()), potenzialmente portando a:
CVSS: 9.8 Critical | Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
GiveWP alimenta migliaia di siti web di beneficenza, ONG e piattaforme di raccolta fondi. Poiché gestisce dati finanziari e dei donatori sensibili, una vulnerabilità qui è di grande impatto. Un attaccante che sfrutta l'Object Injection può passare da un singolo plugin al compromettere l'intera installazione di WordPress e il server sottostante.
Causa principale: unserialize() su input non fidato.
Metodi magici PHP: PHP li invoca automaticamente durante il ciclo di vita degli oggetti:
La vulnerabilità deriva dall'uso non sicuro della funzione PHP unserialize() su input controllati dall'utente. Sebbene unserialize() sia progettato per ricostruire strutture dati PHP, ha un pericoloso effetto collaterale: quando gli oggetti vengono ricostruiti, PHP invoca automaticamente i metodi magici.
__wakeup() – attivato quando un oggetto viene unserializzato
__destruct(), __toString(), __get/__set(), __call/__callStatic() – possono essere sfruttati per esecuzione malevola
Validazione tramite Regex: GiveWP ha implementato controlli regex per rilevare input serializzati. Sebbene la nuova regex rilevi più tipi di dati, la regex non può prevenire in modo affidabile l'Object Injection.
Con un oggetto serializzato creato ad arte, l'attaccante imposta le proprietà dell'oggetto e PHP stesso esegue la logica dell'attaccante invocando i metodi magici
GiveWP ha implementato una validazione basata su regex per verificare se l'input era serializzato. Vecchia Regex (incompleta)
• Riconosceva solo array e oggetti.
• Altri tipi serializzati (stringa, int, bool, float, null) bypassavano il rilevamento.
• Riconosce tutti i tipi serializzati PHP.
• Blocca alcuni payload banali.
• Ma il problema centrale rimane: se unserialize() viene utilizzato su input dell'utente, la regex non può salvarvi.
Questo snippet è stato scritto per confrontare due diverse implementazioni regex:
• is_serialized_old() → la vecchia versione, che rileva solo array e oggetti.
• is_serialized_new() → la versione migliorata, che riconosce tutti i tipi di dati serializzati PHP (array, oggetti, stringhe, interi, booleani, float e null). Creiamo un insieme di valori di test (array, oggetto, stringa, intero, booleano, float, null), li serializziamo e poi controlliamo ciascuno con entrambe le funzioni regex. In termini semplici:
E dopo aver eseguito questo codice sul tuo dokcer, vedi nel browser questo resulte
Passo 1
Passo 2: Creare una classe vulnerabile
Questa classe ha un metodo __wakeup() che verrà eseguito automaticamente quando viene unserializzata.
Passo 3: Creare il payload
Passo 4: Output Dopo aver salvato il file in questo file puoi vedere questo exlpit
Exploit :
• Vecchia Regex: FALSE → non è riuscita a rilevare il payload.
• Nuova Regex: TRUE → lo ha rilevato come input serializzato.
• Esecuzione: Hello RCE! → Il payload è stato unserializzato e il metodo magico __wakeup() ha eseguito codice controllato dall'attaccante.
Prevenzione • Non utilizzare unserialize() su input non fidati. Sostituirlo con json_decode() o altre alternative più sicure.
• Mantenere aggiornati GiveWP e tutti i plugin WordPress.
• Distribuire un Web Application Firewall (WAF) per bloccare payload serializzati malevoli.
• Seguire il Principio del Minimo Privilegio: eseguire gli account PHP e del database con i permessi minimi richiesti.
Risultati:
Punto chiave: Non affidarsi mai alle regex per proteggere unserialize(). L'approccio più sicuro è evitare del tutto di unserializzare input non fidati.
unserialize() su input non fidati; preferire json_decode() o altre alternative sicure.Gestisco due canali Telegram dedicati alla ricerca e allo sfruttamento delle vulnerabilità:
GO-TO CVE Episodi settimanali: Ogni settimana, approfondiamo una nuova CVE e condividiamo analisi dettagliate, demo e approfondimenti. 🔗 Unisciti a noi qui
CVEdb – Archivio Exploit: Questo canale archivia exploit a 1 giorno e PoC personalizzati per CVE. Una grande risorsa per ricercatori che vogliono vedere tecniche di sfruttamento attive. 🔗 Unisciti a CVEdb
Segui i canali per rimanere aggiornato sulle ultime CVE, tecniche di sfruttamento e approfondimenti sulla ricerca sulla sicurezza.
Questo repository è strettamente per scopi educativi e di ricerca. Sfruttare le vulnerabilità senza autorizzazione è illegale e non etico. L'autore non è responsabile per un uso improprio.