L’articolo è stato aggiornato dopo la pubblicazione iniziale man mano che sono arrivati ulteriori dettagli sui problemi indicati.
Sono stati pubblicati su Full Disclosure i metodi (exploit) per attaccare i database server MySQL sfruttandone alcune vulnerabilità.
Non ho potuto verificare tutti gli exploit pubblicati in quanto non dispongo delle installazioni a cui fanno riferimento alcuni di questi metodi.
Le prove sono state fatte utilizzando come vittima un MySQL 5.1.66 a 64 bit installato dai pacchetti standard di CentOS 6, il computer attaccante è un Linux Ubuntu 12.10 collegato in LAN. Entrambi i sistemi sono aggiornati con le ultime patch disponibili. Nessuna modifica particolare è stata fatta a my.cnf sul server.
MySQL Denial of Service Zeroday PoC
Si tratta di uno script Perl che sfrutta un baco della replica di MySQL 5.5. Molto difficile che venga utilizzato come vettore d’attacco, in quanto richiede un utente valido che abbia privilegi di REPLICATION SLAVE, una cosa non comune tra i normali utenti creati in MySQL. RedHat ha assegnato a questo baco il codice CVE-2012-5614. MariaDB ha assegnato a questo baco il codice MDEV-3910.
MySQL 5.1/5.5 WiNDOWS REMOTE R00T (mysqljackpot)
Il messaggio contiene un allegato con i sorgenti C da compilare sotto Linux per attaccare un server MySQL che gira sotto Windows. Se l’attacco va a buon fine, viene aperta una shell remota con privilegi di SYSTEM. Nel pacchetto è anche incluso uno scanner per tentare varie combinazioni di utente/password. Perché funzioni l’exploit deve collegarsi al MySQL remoto con privilegi amministrativi.
MySQL Remote Preauth User Enumeration Zeroday
Non si tratta propriamente di uno zero day perché il problema è noto da anni. Questo metodo per scoprire se esiste un utente nel server si basa sul fatto che MySQL risponde ad un tentativo di accesso in modo differente a seconda se l’utente esista oppure no. L’utente non deve solamente esistere, ma deve avere la possibilità di collegarsi dalla macchina da cui parte l’attacco, quindi un attacco remoto di questo tipo non potrà enumerare (ad esempio) gli utenti che possono collegarsi solamente da localhost. Lo script ha bisogno di un file con l’elenco degli utenti da provare. Nell’ambiente di test lo script ha correttamente individuato un utente che con i privilegi di accesso. RedHat ha assegnato a questo baco il codice CVE-2012-5615. MariaDB ha assegnato a questo baco il codice MDEV-3909.
MySQL Windows Remote System Level Exploit (Stuxnet technique) 0day
Un altro metodo per ottenere una shell remota su un sistema Windows con privilegi di SYSTEM. Anche in questo caso è necessario usare un utente con privilegi amministrativi nel MySQL remoto per poter aprire una shell. Il file allegato al messaggio contiene lo stesso scanner di mysqljackpot.
MySQL (Linux) Heap Based Overrun PoC Zeroday
Questo attacco dovrebbe causare un segmentation fault sulla vittima. Sono necessarie delle credenziali di accesso valide, anche se non privilegiate. L’attacco cambia la password dell’account utilizzato e la imposta ad un valore casuale. Non sono riuscito ad ottenere un segmentation fault nell’ambiente di test. RedHat ha assegnato a questo baco il codice CVE-2012-5612. MariaDB ha assegnato a questo baco il codice MDEV-3908.
MySQL (Linux) Stack based buffer overrun PoC Zeroday
In questo caso un utente remoto qualsiasi potrebbe riuscire ad ottenere una shell con i privilegi dell’utente con cui viene eseguito il server MySQL. Non sono riuscito a riprodurlo nell’ambiente di test: lo script si collega, ma il server si rifiuta di eseguire la query con l’exploit. RedHat ha assegnato a questo baco il codice CVE-2012-5611. Questo problema è già risolto in tutte le versioni di MariaDB.
MySQL (Linux) Database Privilege Elevation Zeroday Exploit
Questo script ha effettivamente creato un utente con privilegi amministrativi ed è riuscito a crashare più volte il server per forzarne il riavvio nell’ambiente di test. Tuttavia per poter funzionare lo script ha bisogno di un utente non amministrativo che però abbia ALL PRIVILEGES … WITH GRANT OPTION su un database e FILE … WITH GRANT OPTION su tutti i database. Se il primo privilegio può essere dato o per default o dopo una richiesta, è veramente improbabile che un grantdi tipo FILE su tutti i database venga concesso con leggerezza al primo utente che capita. Il capitolo Making MySQL Secure Against Attackers del manuale di MySQL indica chiaramente che il privilegio FILE deve essere concesso con estrema parsimonia. Nei casi in cui è necessario concedere il privilegio di FILE, è possibile utilizzare l’opzione --secure-file-priv per impedire questo tipo di attacco. RedHat ha assegnato a questo baco il codice CVE-2012-5613.
Tutti questi vettori di attacco si basano sul fatto che l’amministratore del server non abbia configurato correttamente gli accessi di MySQL e del firewall che lo protegge, oppure abbia allargato troppo le maglie della sicurezza.
In line generale, l’accesso alla porta TCP di MySQL deve essere limitato agli host che ne hanno effettiva necessità e gli utenti creati devono avere il minimo di grant per funzionare correttamente.
In particolare, gli amministratori di Windows devono evitare di eseguire il servizio di MySQL con privilegi amministrativi, ma con un utente non privilegiato creato ad hoc.
Lascia un commento