VoIP and Hacking

Negli ultimi anni l’ SQL injection è divenuta la principale modalità di accesso ad infrastrutture informatiche attraverso web applications vulnerabili.
Può verificarsi quando l’input dell’utente non viene adeguatamente filtrato.
Consideriamo, ad esempio, la seguente linea di codice:

"SELECT * FROM utenti WHERE name = '".$username."';"

Se la variabile $username venisse manipolata da un utente malizioso, la query SQL potrebbe fare più di quanto l’autore intendesse permettergli. Ad esempio, impostando la variabile “$username” come

pippo' or 'pippo'='pippo

restituisce la seguente query SQL:

SELECT * FROM utenti WHERE name = 'pippo' or 'pippo'='pippo';

Se tale codice venisse utilizzato in una procedura di autenticazione l’input manipolato in tal modo potrebbe venire usato per forzare la selezione di un valido identificativo utente dato il risultato dell’espressione ‘pippo’='pippo’ è sempre vero.
L’ SQL injection, di conseguenza, può essere piuttosto semplice da attuare, e tuttavia, tramite tale vettore, un attaccante può essere in grado di infiltrarsi in profondità in una infrastruttura e rimanere relativamente celato.
Quello che molti database administrators non vogliono intendere è che l’ SQL injection non consente all’ attaccante di manipolare solamente i dati di un database che costituisca il backend di una web application, ma può consentire un accesso diretto al sistema operativo sottostante.
Utilizzando funzioni come xp_cmdshell in Microsoft SQL Server, l’ SQL injection può venire sfruttato per mandare in esecuzione comandi della shell col medesimo insieme di privilegi della applicazione database, che opera molto spesso a un livello privilegiato.

Caricare malware su di un sistema è ugualmente semplice e banale.  Si trovano spesso indizi sull’uso di TFTP per il download di files nei sistemi violati.
Una altra tenica diffusa e di successo consiste nell’ usare l’ SQL injection per creare uno script FTP, e poi mandarlo in esecuzione con una linea di comando FTP. Una volta che il malware si trovi nel sistema, l’ attaccante è in grado di mandarlo in esecuzione da remoto sempre tramite l’ SQL injection.
Si è visto, in alcuni casi, l’uso della SQL injection per caricare spezzoni di 512 byte di un file eseguibile  nella tabella di un database.  L’incursore ha poi fatto in modo che il database riassemblasse gli spezzoni, nel corretto ordine, in un file esterno che veniva successivamente mandato in esecuzione in numerosi modi diversi, compresa la creazione di una nuova “stored procedure”.
Talvolta questa tecnica viene usata allorquando il ricorso a xp_cmdshell sia stato propriamente bloccato dal database administrator.

Dato che i database servers vengono spesso considerati ben protetti, hanno di solito accesso a reti interne. Se l’ attaccante controlla la macchina che ospita il database, essa viene usata come un gateway per penetrare più profondamente nella infrastruttura violata.
Localizzare altri sistemi presenti in rete che eseguano software di tipo database  (es, MS SQL Server) è pure molto semplice, specialmente se al traffico SQL viene permesso l’attraversamento di un eventuale firewall posto fra i database servers.
Gli attacchi di tipo SQL injection stanno crescendo in sofisticazione, come talvolta si può dedurre dal fatto i comandi SQL iniettati facciano uso di una qualche codifica, esadecimale o per particolare set di caratteri.
Lo sviluppo di applicazioni web che si interfaccino ad un database in modo sicuro è un obiettivo complesso che coinvolge numerose componenti. I DB Administrators dovrebbero perciò operare più direttamente a contatto coi professionisti della sicurezza nello sviluppo delle applicazioni per mitigare l’impatto della minaccia costituita dalla tecnica della SQL injection.

Send post as PDF to