SQL Injection: un focus sul tipo “blind”

Nelle tradizionali SQL injection, l’attaccante usa delle query per valutare la presenza di vulnerabilità nel sistema vittima.

In caso affermativo, la risposta dell’applicazione è tangibile e l’attività prosegue fornendo query malevole, atte a compromettere il sistema ed esfiltrare dati.
In alcuni casi, però, non è possibile ottenere in risposta dei dati o anche solo dei messaggi di errore. Occorre operare con metodi alternativi, se si vuole scovare una vulnerabilità.
Analizzando il comportamento dell’applicazione in relazione a specifiche tipologie di sollecitazione, l’hacker è in grado non solo di identificare delle vulnerabilità, ma anche di sfruttarle per un suo profitto esfiltrando dati.

I blind SQL injection sono una variazione dei tradizionali attacchi SQL injection, nei quali le applicazioni web vulnerabili non rispondono alle richieste con le informazioni relative.

Nei SQL injection, il database restituisce o i dati o un messaggio di errore a commento della query.

Trattasi di blind SQL injection se il database non fornisce dati alla pagina web che confermino direttamente la presenza di una vulnerabilità.

In questo caso l’attaccante ricorre ad una serie di richieste condizionali, alle quali il database risponde con ‘vero’ o ‘falso’.
Sebbene, quindi, molte tecniche utilizzabili nelle SQL injection non siano efficaci, l’attaccante può sempre ottenere l’esfiltrazione di dati con qualche step in più. Non sono efficaci, infatti, tecniche come UNION e XPATH usate spesso dagli attaccanti in altri ambiti.

L’approccio, in questa tipologia di injection, è simile a quella della scatola nera: non potendo vedere direttamente che cosa si ha difronte, si esaminano i suoi effetti a seconda delle sollecitazioni. Qui le sollecitazioni possono essere l’induzione all’errore tramite istruzioni condizionali oppure un ordine di “delay” (ritardo).

A seconda del comportamento del sistema, si riesce ad evincere la presenza di vulnerabilità e, talvolta, anche porzioni di dati.

Trattandosi di una particolare infezione SQL injection, le potenziali conseguenze di questo attacco sono simili.

Molto dipende dal contesto in cui è inserito questo attacco.
In generale, però, si evidenziano alcuni effetti comuni.

• Perdita di Confidenzialità ed Integrità.
  

  L’applicazione vittima non è più affidabile. I dati sensibili contenuti nel database vengono violati.
  La sicurezza non è più garantita agli utenti. In seguito alla violazione, l’applicazione web-based potrebbe avere comportamenti non previsti.

• Modifica dei contenuti del database.
  

  La base di dati connessa all’applicazione web viene violata. Perciò i dati in essa contenuti possono subire pesanti modifiche da parte dell’attaccante.
  Se la violazione è severa si può arrivare all’esfiltrazione ai fini di un riscatto. Nel caso delle blind SQL injection, l’esfiltrazione avviene anche tramite query di DNS appositamente forgiate.

Ci possono essere dunque gravi danni sia all’applicazione stessa che a tutti gli utenti che la utilizzano in seguito all’attacco, anche se in larga parte sono proprio gli utenti le vittime principali delle injection. Ciò non toglie che per le aziende, un attacco che sfrutta una loro piattaforma web per colpire i suoi utenti possa rappresentare un importante danno di immagine.

Ma in cosa si differenzia l’attacco Blind SQL Injection da un SQL Injection tradizionale?

Dato che non si può agire in modo diretto, l’attaccante opera con altre metodologie.
Non potendo vedere gli errori sorti grazie alle query inviate, l’hacker si basa su risposte “vero/falso”, inducendole con query apposite.

Questa tecnica è detta “content based”, basata sul contenuto.

Accade spesso, nelle web app, che i dati da mostrare a schermo siano chiamati tramite dei parametri numerici, visibili anche nell’url.

Un attaccante potrebbe pensare di verificare quanto una app sia suscettibile a injection, semplicemente forzando nella query l’espressione “AND 1=2”. In questo modo l’output logico complessivo sarà sempre “FALSE”. Se il comportamento dell’app è alterato da questo intervento, allora essa è suscettibile alle SQL Injection. Per avere conferma, l’hacker può forzare anche il “TRUE”, immettendo nella query l’espressione “AND 1=1”, che restituisce vero se la query originale ha successo.

Le eventuali discrepanze nei contenuti mostrati a schermo nei casi “TRUE” o “FALSE” rivelano la sensibilità dell’app a modifiche esterne. Le query non sono solo modificabili, ma vengono anche eseguite senza validazione.

Questa presa di coscienza è altamente pericolosa. Una volta appurata la presenza della vulnerabilità, ci possono solo essere implementazioni di sicurezza successive ad arginare l’attaccante. In mancanza di strutture di difesa, l’acquisizione dei privilegi è solo questione di tempo, una volta rivelata la debolezza.

Gli hacker utilizzano anche un’altra tecnica di blind SQL injection. Questa gioca sui tempi di attesa (time-based) prima di una risposta. I tempi di attesa, gestiti forzando le query, sono usati sia per valutare se una app è vulnerabile, sia per discernere l’output senza che questo venga necessariamente mostrato a schermo.

Nel primo caso, basta valutare i tempi di risposta del server durante il normale utilizzo. Successivamente si forzano delle query affinché la risposta venga ritardata di alcuni secondi. Se c’è discrepanza nelle prestazioni, vuol dire che l’applicazione legge ed esegue le istruzioni malevole senza procedure di sicurezza.

Analogamente, è possibile reperire informazioni importanti sul contenuto stesso del database, utilizzando i tempi di attesa come ‘rivelatori’ al posto di variabili condizionali.

Gli hacker più esperti riescono anche a decodificare, in questo modo, intere porzioni di dati. Il tutto, va ricordato, senza riscontri visivi espliciti. Grazie a questa tecnica è inoltre possibile evincere il tipo di database utilizzato. Infatti, le funzioni di delay sono specifiche a seconda del servizio. La funzione che viene accettata ed eseguita, dunque, non solo rivela la vulnerabilità ma mostra anche che tipo di database si nasconde dietro le quinte.

Come ci si può immaginare, questo tipo di attività richiede molto tempo.
Non avendo la possibilità di un riscontro diretto, i tentativi di sabotaggio si prolungano notevolmente. Tuttavia, l’innovazione è propria anche dei criminali, i quali sviluppano sovente dei processi automatizzati che offrono buoni tassi di successo.

Se le query sono eseguite in modo asincrono, le tecniche vite finora potrebbero non avere successo.

Infatti, la risposta in questo caso non dipende da condizioni di verità o dal tempo di esecuzione. L’hacker ricorre a interazioni “out-of-band”.

In questo modo, invece di carpire informazioni pezzo a pezzo, è possibile esfiltrare i dati in un colpo solo. Tendenzialmente, vengono sfruttate le query di DNS le quali, però, dipendono fortemente dal tipo di database con cui si ha a che fare. L’idea di base è quella di forzare un “lookup” tramite una specifica query, verso un indirizzo dettato dall’attaccante.

Se la applicazione è vulnerabile, i dati richiesti saranno visibili nel dominio esterno immesso dall’attaccante.

Sebbene le tecniche per rivelare le blind SQL injection siano diverse da quelle standard, la prevenzione passa dalle stesse buone norme, valide per entrambe le tipologie di ‘injection’.

‘Best Practices’ di programmazione

Sono indipendenti dal linguaggio con il quale è stata progettata l’applicazione.
Ci sono molti modi per gestire le query, con vari livelli di sicurezza.

Il minimo dovrebbe coincidere con l’uso di “prepared statements”, cioè istruzioni parametrizzate.
Questa tecnica slega l’istruzione dall’input esterno, il quale viene interpretato prima di essere inserito nella query ed eseguito.
L’URL può essere utilizzato per verificare la presenza di vulnerabilità. Per evitare che alcune modifiche ai parametri corrispondano a query corrotte, occorre implementare delle rigide procedure di sicurezza, diffidando sempre da tutto ciò che viene dall’utente o che può essere manomesso da esso.

Infine, è obbligatorio pulire gli input provenienti direttamente dall’esterno. In prima battuta è necessario filtrare caratteri speciali dalle stringhe, performando anche l’escaping dei tag HTML.
All’interno di un database, infine, è opportuno che i dati sensibili siano protetti con la crittografia. Ad una sensibile flessione delle prestazioni, corrisponde un livello ulteriore di difesa in caso di violazioni nella base di dati.

Test del codice

Testare è l’unico modo per verificare di non aver introdotto vulnerabilità in fase di programmazione.

I test attuabili sono di vario tipo, anche a seconda del punto di vista dell’azione: in alcuni casi si simula un’aggressione esterna, altre volte i test sono prodotti a stretto contatto con la fase di scrittura del codice.

In ogni caso, la prevenzione passa anche da queste procedure, le quali possono anche essere automatizzate per efficientare il processo di produzione senza rallentarlo. Da una semplice verifica della bontà di applicazione delle buone norme, si arriva anche allo stress test dell’applicazione. È frequente incontrare problemi seri nei campi di input, ad esempio.

Se l’input non è propriamente sanificato, anche il più semplice comando può compromettere l’integrità dell’applicazione.

I blind SQL injection sono una variazione sul tema principale.

Invece di valutare gli direttamente la risposta fornita dal sistema in seguito ad una richiesta, qui si deve operare indirettamente.

Per capire se un’applicazione è vulnerabile si osservano, ad esempio, eventuali variazioni nel comportamento del sistema quando vengono passate query contenenti delle condizioni vere o false.

Se l’app è suscettibile, il comportamento varierà. Una tecnica simile prevede dei time-out: se vengono rispettati, l’applicazione legge ed esegue le istruzioni esterne. Infine, query sul DNS possono rivelare dati importanti e consegnali direttamente all’aggressore.
La prevenzione, per tutti i tipi di SQL injection, passa dal rispetto delle buone norme di programmazione e arriva ad una attenta fase di testing

Cyberment Srl

Cyberment è un’azienda specializzata in consulenza di sicurezza informatica. Il nostro red team è composto da hacker etici e specialisti in cybersecurity che operano in questo settore da oltre 20 anni.

Ci occupiamo di identificare le vulnerabilità informatiche nei sistemi e nelle applicazioni web tramite servizi di Vulnerability Assessment e Penetration Test.

Siamo un’azienda di sicurezza informatica certificata ISO 9001, ISO 27001, nonché azienda etica. Abbiamo sede legale a Milano e sede operativa a Porto Mantovano, mentre Londra è il cuore del nostro reparto ricerca e sviluppo.

Se desideri conoscere in modo approfondito i nostri servizi di prevenzione dalle minacce informatiche, contattaci!