Anche se non tutti i lettori sono a conoscenza delle azioni svolte dai principali gruppi hacker, tra i quali, i più famosi e attivi sono Anonymous e LulzSec, avranno sicuramente sentito parlare degli attacchi condotti a numerosi siti e servizi sul web, tra cui, recentemente, la violazione dei dati personali degli utenti registrati sul sito Sony Pictures. Vi siete mai chiesti come vengono condotti, a livello pratico, questi attacchi?

Per perpretare i loro attacchi, i gruppi hacker utilizzano in genere diversi tipi di tecniche e strumenti, più o meno sofisticati. Non è ovviamente nostra intenzione esaminarli tutti, o fornire un manuale per gli stessi; piuttosto, può essere utile e interessante esaminare le tecniche usate più frequentemente: in fondo molti di noi hanno e gestiscono un proprio sito web, per cui può far comodo sapere in anticipo se questo può avere delle falle a livello di sicurezza e se può essere facilmente violato. Le tecniche di attacco più diffuse sono fondamentalmente due: il DDoS - (Distributed) Denial of Service, e l'SQLI - SQL Injection: vediamo in cosa consistono.

Attacco Distributed Denial of Service (DDoS)

Questo tipo di attacco si verifica quando un sistema, tipicamente un web server, riceve contemporaneamente un numero così elevato di richieste da causare un sovraccarico del server stesso, che può arrivare a bloccarsi o addirittura a eseguire lo shutdown. L'obiettivo di questo tipo di attacco sta proprio nel suo nome ("diniego del servizio"): cioè far sì che un sito o un servizio web non sia più raggiungibile/utilizzabile dagli utenti e dai visitatori. La negazione del servizio, per molti tipi di applicazioni e attività commerciali, rappresenta una potenziale perdita economica non trascurabile (si pensi, ad esempio, a un sito per la prenotazione dei viaggi in aereo o in treno). Storicamente, questo tipo di attacco ha sempre riscontrato un notevole successo, in quanto per un server web è virtualmente impossibile sapere se una richiesta di accesso arriva da un utente legittimo oppure da un attacco hacker - quest'informazione sarà infatti disponibile solo quando la richiesta sarà già stata processata. Il termine "Distributed" sta inoltre a indicare che l'attacco è condotto simultaneamente da più hacker, sparsi in diversi paesi del mondo, che si sincronizzano per coordinare ed attuare l'attacco ciascuno con un proprio computer collegato a Internet. Non solo, data la sua natura di attacco "brutale", il DDoS si presta ad essere eseguito non solo da computer controllati dall'uomo, ma anche e soprattutto da applicazioni software che eseguono autonomamente e automaticamente l'attacco (si parla in questo caso di computer "zombie"). Se poi un'applicazione zombie fosse in grado di installarsi su una vasta quantità di computer in giro per il mondo (magari a insaputa degli ignari utenti), si potrebbero facilmente comprendere gli effetti devastanti (e a costo "quasi zero") di questo tipo di attacco. Questo è uno dei tanti motivi per cui è conveniente utilizzare un antivirus e un programma in grado di rilevare applicazioni malware.

Attacco SQL Injection (SQLI)

Questo tipo di attacco sfrutta la vulnerabilità di alcune tecniche web comunemente adottate, combinate tipicamente con una scarsa sicurezza a livello di database. L'SQLI può portare a conseguenze assai disastrose, dall'utilizzo non autorizzato di un account esistente, fino alla violazione di informazioni contenute su un database.

Particolare interesse ha destato un attacco di questo tipo condotto dal gruppo Lulz Security (LulzSec) ai danni della Sony Pictures (link alla notizia riportata sul sito BBC). Il sito della Sony è stato attaccato da questo gruppo di hacker almeno tre volte, inclusa la rete di utenti SonyPlaystation, con la compromissione dei dati di almeno 77 milioni di utenti. Come può avvenire ciò? E' molto semplice. Ogni volta che ci si connette a un sito fornendo la propria login e password, l'applicazione web eseguirà una query SQL molto simile alla seguente per verificare le credenziali dell'utente (ricordiamo che l'SQL è un linguaggio utilizzato per interrogare, "query" in inglese, o modificare un database):

SELECT UserID FROM Users WHERE UserName='mioutente' AND Password='miapassword';

Solo se la UserName e la Password inserite sono presenti nel database, verrà restituito un opportuno UserID. Ad una prima occhiata, questa query sembrerebbe avere un'aria innocente, niente di più di una semplice e tranquilla istruzione per validare l'utente. Tuttavia, operando una semplice sostituzione dei valori inseriti dall'utente, anche questa semplice query è potenzialmente in grado di portare un attacco SQLI. Supponiamo, infatti, che come nome utente sia inserita la stringa “mioutente’–-” e come password la stringa “passworderrata”. La query diventerebbe la seguente:

SELECT UserID FROM Users WHERE UserName='mioutente'--' AND Password='passworderrata'

Sapendo ora che nel linguaggio SQL una sequenza di due trattini ("--") indica l'inizio di un commento, tutto che ciò che appare dopo i due trattini (inclusi gli stessi) verrà ignorato. La query effettiva diventerà così la seguente:

SELECT UserID FROM Users WHERE UserName='mioutente'

Il risultato è lampante: nella query non è più presente il controllo sulla password! Si è così potenzialmente in grado di eseguire il login con il nome utente "mioutente" senza aver inserito (e quindi senza conoscere) la sua password! Questo è probabilmente l'esempio più semplice ed evidente di come si possa sferrare un attacco SQL injection (SQLI).

Ma ci si può premunire nei confronti di un attacco SQLI?

La risposta è affermativa: gli attacchi SQLI, quando vengolo portati a termine con successo, sono sempre attribuibili a negligenze e/o a uno sviluppo poco responsabile delle applicazioni software. Tuttavia, i danni portati da questi attacchi possono anche essere consistenti, a seconda dei privilegi di lettura/scrittura che il database sul web server assegna alle applicazioni web. Riferendosi sempre all'esempio precedente, supponiamo che come nome utente si inseriscano i valori "utentepippo'--", "admin'--", o qualunque altro nome utente: se questi utenti sono effettivamente nel database, si può eseguire istantaneamente il login con queste utenze senza conoscerne la password ed eritando i "privilegi" assegnati a quell'utente (se tra questi privilegi c'è quello in scrittura, gli effetti possono essere facilmente immaginabili). Supponiamo ora che nel database esista l'utente "Gianni" (o un altro nome utente qualsiasi, sceglietene un altro, se preferite), e che esista la tabella "Users" (molto plausibile come ipotesi). Modifichiamo a questo punto la query precedente nel modo seguente (il ";" in SQL permette di separare due istruzioni):

SELECT UserID FROM Users WHERE UserName='Gianni'; DROP TABLE Users;--' AND Password='passworderrata'

che equivale a:

SELECT UserID FROM Users WHERE UserName='Gianni' DROP TABLE Users

DROP in SQL equivale all'operazione di cancellazione, per cui il risultato di quest'attacco SQLI è quello di eliminare la tabella degli utenti. Poco simpatico, non vi sembra? Ovviamente, le combinazioni sono infinite, e si può lasciare spazio alla propria fantasia per immaginare cosa si potrebbe fare con questo tipo di attacchi.

Come si può prevenire un attacco SQLI?

Prevenire è meglio che curare, come dice il proverbio, e ciò è assolutamente possibile anche in questo caso. Come? Basta applicare la cosiddetta "sanitizzazione degli input" (è un brutto termine, ma è la migliore traduzione disponibile per il verbo anglosassone "sanitize"). Il processo di sanitizzazione è abbastanza semplice: esso tratta ogni singolo carattere apice (‘) in modo appropriato, in modo tale che esso non possa terminare prematuramente una stringa all'interno di un'istruzione SQL. Il concetto è quello di far precedere ogni carattere (‘) da un backslash, esattamente come si fa nelle sequenze di escape. L'esempio mioutente'-- / passworderrata viene sanitizzato nel modo seguente:

SELECT UserID FROM Users WHERE UserName='mioutente\'--' AND Password='passworderrata'

Poichè il carattere apice dopo mioutente è preceduto da un backslash, il database cercherà l'utente con nome "mioutente'--". Inoltre, poichè i trattini sono inclusi nella stringa e non nell'istruzione SQL, essi non verranno interpretati come commento SQL.

Per quanto concerne l'altro caso (Gianni'; DROP TABLE Users;-- / passworderrata) avremo:

SELECT UserID FROM Users WHERE UserName='Gianni\'; DROP TABLE Users;--' AND Password='passworderrata'

In questo caso sia il punto e virgola che i trattini saranno inclusi all'interno della stringa di ricerca e verranno utilizzati per la ricerca senza essere interpretati come comandi SQL.

Ricordiamo che il noto gruppo hacker LulSec, di cui si sa poco o nulla, ha portato i propri attacchi ai siti di Sony Pictures proprio con una semplice e singola SQL injection. Allo stesso gruppo sono attribuibili attacchi ad altri siti negli Stati Uniti, come Fox, PBS e XFactor. Questa tecniche sono largamente utilizzate anche dal gruppo Anonymous (la cui "bandiera" è mostrata nell'immagine di apertura dell'articolo), che ha sferrato una consistente campagna di attacchi rivolta a diversi siti governativi americani dopo la recente chiusura di Megavideo e Megaupload decisa dall'FBI (giudicata dal gruppo hacker come una vera e propria limitazione al libero scambio dei contenuti digitali).

In sintesi, possiamo dire che per quanto riguarda gli attacchi SQLI un rimedio c'è e gli stessi si possono prevenire (sanitizzare l'input, soprattutto il login!); per quanto riguarda invece gli attacchi DDoS, la situazione è più complessa e più difficile da risolvere (esistono comunque tecniche che possono limitare gli accessi provenienti da certi IP).

Ti potrebbe interessare anche:

Memorizziamo i dati in maniera sicura con il confidential computing

L’auto del futuro? Sempre più connessa e interattiva

Cyber-Security e Industry 4.0: stato dell’arte e trend futuri

Articoli Correlati

Microcontrollori e crittografia

Definiamo i campi di battaglia del futuro