CMS Exploitation (WordPress, Joomla, Drupal)

Difficoltà: Intermediate Time to Master: 2.5h Prerequisiti: 06-Data-Exfiltration.md Lab: HTB, macchine con CMS noto (WordPress in particolare)

Obiettivo

Un’enorme fetta del web gira su un CMS, e per quanto in 01-Reconnaissance/02-Fingerprinting.md tu abbia già imparato a riconoscere WordPress o Joomla, riconoscerlo è solo il primo passo. Il salto che manca è: una volta che sai “è WordPress 5.8 con il plugin X versione 2.1”, cosa ci fai? Questa pagina è quel salto. La buona notizia è che i CMS più diffusi hanno un ecosistema enorme di plugin/temi di terze parti, spesso mantenuti peggio del core, ed è lì che si nascondono la maggior parte delle vulnerabilità reali che troverai in lab e in engagement veri.

Concetti chiave

Perché i CMS sono un bersaglio diverso dal “solito” web target

Con un’applicazione custom studi il codice (se disponibile) o lo scopri a tentativi. Con un CMS diffuso, il codice del core e di migliaia di plugin è pubblico: il tuo lavoro diventa enumerazione precisa (quale plugin, quale versione) più ricerca di CVE noti, molto più che scoperta di bug da zero.

Superficie d’attacco tipica di un CMS

Workflow tipico

1. Conferma CMS e versione (fingerprinting già visto)
2. Enumera plugin/temi installati e le loro versioni
3. Cerca CVE noti per ogni componente versionato trovato
4. Se non c’è un CVE pronto, controlla configurazioni deboli (credenziali default, file di backup esposti, funzionalità di upload)

Strumenti

Payload / Esempi

Esempio 1: enumerazione completa WordPress con WPScan

wpscan --url http://target.com --enumerate vp,vt,u --api-token TUO_TOKEN

Output atteso:

[+] wp-super-cache
 | Location: http://target.com/wp-content/plugins/wp-super-cache/
 | Latest Version: 1.7.2 (up to date)
 [!] Title: WP Super Cache <= 1.7.1 - Unauthenticated RCE

Spiegazione: --enumerate vp,vt,u chiede plugin vulnerabili, temi vulnerabili e utenti in un colpo solo; l’API token (gratuito con registrazione su wpscan.com) sblocca il database vulnerabilità completo, senza è molto più limitato.

Esempio 2: dal plugin vulnerabile all’exploit pubblico

searchsploit wp super cache
searchsploit -m php/webapps/XXXXX.php

Spiegazione: una volta che WPScan ti dà nome e versione del plugin vulnerabile, searchsploit è il passo successivo naturale: cerchi il PoC pubblico e lo adatti al target, esattamente come faresti con qualsiasi altro exploit pubblico (vedi ../08-Exploitation-PostEx/02-RCE-Techniques.md).

Esempio 3: enumerazione utenti WordPress senza WPScan (manuale)

curl -s "http://target.com/wp-json/wp/v2/users" | jq
curl -s "http://target.com/?author=1" -I

Spiegazione: l’API REST di WordPress espone spesso gli username registrati senza autenticazione, e il vecchio trucco ?author=1 fa un redirect verso l’URL pubblico dell’autore (che rivela lo username nello slug): utile quando WPScan non è disponibile o vuoi restare più silenzioso.

Evasion / Bypass Techniques

• WPScan è rumoroso (centinaia di richieste): se la discrezione conta, limita l’enumerazione al solo --enumerate p (plugin) invece di tutto, o usa un --throttle
• Molti admin rinominano /wp-admin o /wp-login.php pensando che basti: gli endpoint dell’API REST (/wp-json/) restano comunque raggiungibili e rivelano comunque la presenza di WordPress
• Se un plugin sembra aggiornato ma il changelog pubblico mostra un CVE per la versione immediatamente precedente, verifica sempre a mano: a volte il numero di versione mostrato nel markup non coincide col file effettivamente installato

Lab Hands-On

Lab 1: HTB, macchina WordPress con plugin vulnerabile

Obiettivo: enumerare un’installazione WordPress, identificare un plugin con CVE noto e ottenere esecuzione di codice Difficulty: Medio Time: 1h

Walkthrough breve:

1. Conferma CMS/versione con fingerprinting passivo
2. Esegui WPScan con enumerazione completa di plugin/temi/utenti
3. Cerca su searchsploit/exploit-db la versione esatta del plugin vulnerabile trovato
4. Adatta e lancia l’exploit, verifica accesso ottenuto

Common Mistakes

• Fermarsi al fingerprinting del core CMS senza enumerare plugin/temi -> è quasi sempre lì che si nasconde la vulnerabilità sfruttabile, non nel core aggiornato
• Lanciare WPScan senza API token e concludere “nessuna vulnerabilità nota” -> senza token il database è molto ridotto, verifica sempre manualmente su searchsploit/exploit-db prima di escludere una versione
• Non controllare l’enumerazione utenti -> conoscere gli username validi rende molto più mirato un attacco di credential stuffing successivo (vedi 06-Authentication-Authorization/05-Credential-Attacks.md)

Link Utili

• WPScan Vulnerability Database
• Exploit-DB: WordPress

Connessioni

• Prerequisito: 06-Data-Exfiltration.md
• Prossimo Step: 08-Insecure-Deserialization.md
• Combinazione con: ../01-Reconnaissance/02-Fingerprinting.md

Checklist di padronanza

• So enumerare plugin/temi/utenti di un’installazione WordPress con WPScan
• So passare da “plugin + versione” a un exploit pubblico funzionante
• Conosco almeno un metodo di enumerazione utenti manuale, senza tool dedicati
• Capisco perché la superficie d’attacco reale di un CMS sono i plugin, non il core