Cyber Crime: l’ormai obsoleta “SQL Injection” e l’attacco a “Zoom”

Premessa

Cosa si intende con “SQL Injection” (SQLi) e “Attacco con SQL Injection”

In parole povere, SQL è un linguaggio di database ed è l’acronimo di “Structured Query Language”. È stato progettato per sistemi di database operativi come MySQL, Oracle, Microsoft SQL Server o SQLite. D’altra parte, una “SQL injection” è un attacco informatico che prende di mira il database con l’aiuto di specifiche istruzioni SQL create per indurre il sistema a eseguire attività non avviate dall’utente e indesiderate. L’ attacco con “SQL injection” modifica il codice, dunque anche l’esito atteso, ovvero il risultato del comando impartito dall’utente.  

Un attacco con “SQL injection” riuscito è in grado di:

• Modificare, alterare o eliminare dati dal database;
• Leggere dati sensibili e riservati dal database;
• Recuperare contenuto di un file specifico presente sul “Database Management System” (DBMS);
• Eseguire operazioni riservate all’amministratore, come l’arresto del DBMS.

Senza adeguati controlli di mitigazione e misure di sicurezza, l’attacco con “SQL injection” può esporre un’applicazione ad un enorme rischio di compromissione dei dati. Può influire sulla riservatezza e sull’integrità dei dati, nonché sull’autenticazione e l’autorizzazione dell’applicazione. Può anche consentire al criminale di rubare informazioni riservate come credenziali utente, informazioni finanziarie o dati commerciali sensibili, utilizzando in modo improprio la vulnerabilità esistente in un’applicazione o in un programma. 

Tipi di attacchi SQL injection

Una “SQL Injection” può essere sfruttata in vari modi, e questi richiedono diversi livelli di conoscenza, che vanno da quella “amatoriale” a quella di veri “esperti”. Di seguito riportiamo alcuni tipi comuni di “SQL injection”:

• In-band SQL Injection
  È il tipo più comune di attacco con “SQL injection”, in cui l’aggressore utilizza lo stesso canale di comunicazione per lanciare attacchi e raccoglierne i risultati. Questa tipologia di “SQL injection” è famosa per la sua semplicità ed efficienza. Ha due sottovarianti:  

• • Error-based SQL injection: una tecnica in cui l’autore dell’attacco determina le vulnerabilità del sistema provocando deliberatamente la produzione di messaggi di errore da parte del database. Successivamente, questi messaggi di errore vengono utilizzati per ottenere i risultati completi della query e per accedere a tutte le informazioni riservate del database. Questa tecnica può essere utilizzata anche per identificare le vulnerabilità presenti in un sito Web o in un’applicazione Web al fine di ottenere informazioni aggiuntive per sviluppare nuovamente le query dannose.

• • Union-based SQL injection: con questa tecnica, l’autore dell’attacco ottiene il vantaggio di estrarre le informazioni dal database, espandendo i risultati restituiti dalla query originale. Ma l’operatore Union è utile solo nel caso in cui le query originali o nuove abbiano lo stesso numero e tipo di dati delle colonne.
• Inferential (Blind) SQL Injection: Le “Blind SQL injection” si basano, principalmente, sul comportamento del server e sui modelli di risposta (“response patterns”), di cui l’autore dell’attacco osserva da vicino gli indizi indiretti. Per realizzare questa osservazione attenta, l’aggressore invia al server i payload dei dati. Questo tipo di tecnica è chiamata “Blind SQL injection” (ovvero “SQL Injection” cieca) perché l’aggressore non ottiene i dati dal database del sito web, rendendo così impossibile vedere le informazioni sull’attacco in banda. La “Blind SQL injection” si basa su due metodi:

• Boolean: qui l’autore dell’attacco invia una query SQL al database che richiede all’applicazione di dare un risultato. Tuttavia, a seconda della query, vera o falsa, il risultato varia e, in base al risultato, le informazioni vengono modificate o rimangono le stesse, ovvero quelle della risposta HTTP. In tal modo, l’aggressore scopre se il risultato nel messaggio generato è vero o falso. 
• Time-Based: l’aggressore invia una query SQL al database, il database attende alcuni secondi per rispondere. Osservando il periodo di tempo impiegato dal database per rispondere, l’aggressore può analizzare se la query è vera o falsa. E in base a questo risultato, viene generata una risposta HTTP istantaneamente o dopo un periodo di attesa. Pertanto, senza fare affidamento sui dati del database, l’aggressore può determinare se il messaggio utilizzato ha generato un “vero” o “falso”.
• Out-of-band SQL Injection
  Si tratta dell’approccio più raro per attaccare un server SQL. Questa tecnica si basa su particolari funzionalità del database abilitato per SQL. Implica l’invio di una query DNS o HTTP al server SQL che dispone di un’istruzione SQL. In caso di successo, l’attacco “fuori banda” può trasmettere il contenuto del database, aumentare i privilegi dell’aggressore ed eseguire le stesse azioni eseguite da altri tipi di attacchi “SQL Injection”. 

Nonostante il tipo di attacco in oggetto si conosca da molti anni, le “SQL Injection” rappresentano ancora oggi, sul finire del 2020, una minaccia alla sicurezza.

Negli ultimi dieci anni si sono verificati molti attacchi “SQL injection”, e si può asserire che le “SQL injection” siano uno dei tipi di attacchi informatici maggiormente in evoluzione. 

Attualmente, come verificabile dallo studio sull’impatto di alcune minacce web eseguito dalla Akamai, gli attacchi “SQL injection” rappresentano oltre i due terzi di tutti gli attacchi alle applicazioni software. 

 

Naturalmente, vi sono una lunga serie di misure da mettere in atto per sfuggire a questo tipo di attacco. Non potendo citarli tutti – anche perché cambierebbe il tema del nostro articolo – ci limitiamo a consigliare di far eseguire il VAPT, ovvero il “Vulnerability Assessment and Penetration Testing”, da professionisti della sicurezza, onde identificare e affrontare le vulnerabilità, a livello di rete e di applicazione, prima che possano essere sfruttate da criminali.

IL CASO “ZOOM”

Le righe che seguono le dedicheremo a quanto occorso negli scorsi mesi – e risoltosi alcune settimane fa – ad una delle applicazioni più usate al mondo dal periodo della diffusione della pandemia da Covid-19.

In Italia, dal primo “lockdown” fino ad oggi, l’app “Zoom” è stata – insieme alle sue concorrenti di rango – una delle piattaforme più usate per videoconferenze, didattica a distanza etc… Tutti noi l’avremo usata almeno una volta.

L’azienda produttrice di questa app è la “Zoom Video Communications Inc.”, fondata nel 2011 da Eric Yuan. Tale azienda ha esordito – certamente – sotto silenzio, vista la scarsa diffusione dei suoi prodotti e servizi. È cresciuta col passare degli anni, anche grazie ad accordi, fusioni etc. Dal 2019 è divenuta un piccolo colosso e nel 2020 – complice anche la pandemia – ha assunto proporzioni davvero rilevanti.

Dal 2019 è quotata e compare come “ZM” nel NASDAQ.

Al solo fine di mostrare la crescita smisurata di utenti nel mondo, riportiamo – rischiando la pedanteria – la crescita del titolo “ZM” dal 15 aprile 2019 al 4 dicembre 2020:

 

2019

 

15 aprile 2019                         6,80 miliardi di dollari

22 aprile 2019                         7,26 miliardi di dollari

29 aprile 2019                         21,52 miliardi di dollari

6 maggio 2019                         21,64 miliardi di dollari

13 maggio 2019                       24,46 miliardi di dollari

20 maggio 2019                       20,73 miliardi di dollari

27 maggio 2019                       21,67 miliardi di dollari

3 giugno 2019                          25,56 miliardi di dollari

10 giugno 2019                        27,26 miliardi di dollari

17 giugno 2019                        27,31 miliardi di dollari

24 giugno 2019                        24,13 miliardi di dollari

1 luglio 2019                           24,97 miliardi di dollari

8 luglio 2019                           25,36 miliardi di dollari

15 luglio 2019                         25,38 miliardi di dollari

22 luglio 2019                         27,78 miliardi di dollari

29 luglio 2019                          25,60 miliardi di dollari

5 agosto 2019                          25,75 miliardi di dollari

12 agosto 2019                        25,29 miliardi di dollari

19 agosto 2019                        25,04 miliardi di dollari

26 agosto 2019                        25,05 miliardi di dollari

2 settembre 2019                    23,34 miliardi di dollari

9 settembre 2019                    21,55 miliardi di dollari

16 settembre 2019                  22,58 miliardi di dollari

23 settembre 2019                  20,78 miliardi di dollari

30 settembre 2019                  20,92 miliardi di dollari

7 ottobre 2019                        19,50 miliardi di dollari

14 ottobre 2019                      18,06 miliardi di dollari

21 ottobre 2019                      17,34 miliardi di dollari

28 ottobre 2019                      16,45 miliardi di dollari

4 novembre 2019                    16,32 miliardi di dollari

11 novembre 2019                  16,36 miliardi di dollari

18 novembre 2019                  17,09 miliardi di dollari

25 novembre 2019                  17,41 miliardi di dollari

2 dicembre 2019                     14,66 miliardi di dollari

9 dicembre 2019                     14,85 miliardi di dollari

16 dicembre 2019                    15,64 miliardi di dollari

23 dicembre 2019                   15,57 miliardi di dollari

30 dicembre 2019                   15,72 miliardi di dollari

 

2020

 

6 gennaio 2020                        17,08 miliardi di dollari

13 gennaio 2020                      17,65 miliardi di dollari

20 gennaio 2020                      17,06 miliardi di dollari

27 gennaio 2020                      17,83 miliardi di dollari

3 febbraio 2020                        24,81 miliardi di dollari

10 febbraio 2020                     25,46 miliardi di dollari

17 febbraio 2020                     28,48 miliardi di dollari

24 febbraio 2020                     29,39 miliardi di dollari

2 marzo 2020                          32,00 miliardi di dollari

9 marzo 2020                          30,08 miliardi di dollari

16 marzo 2020                         36,54 miliardi di dollari

23 marzo 2020                         42,46 miliardi di dollari

30 marzo 2020                         35,88 miliardi di dollari

6 aprile 2020                           34,85 miliardi di dollari

13 aprile 2020                         42,00 miliardi di dollari

20 aprile 2020                         44,45 miliardi di dollari

27 aprile 2020                         39,19 miliardi di dollari

4 maggio 2020                         43,96 miliardi di dollari

11 maggio 2020                       49,45 miliardi di dollari

18 maggio 2020                       48,38 miliardi di dollari

25 maggio 2020                       50,77 miliardi di dollari

1 giugno 2020                          58,72 miliardi di dollari

8 giugno 2020                          62,09 miliardi di dollari

15 giugno 2020                        68,87 miliardi di dollari

22 giugno 2020                        72,64 miliardi di dollari

29 giugno 2020                        74,03 miliardi di dollari

6 luglio 2020                           78,03 miliardi di dollari

13 luglio 2020                         69,73 miliardi di dollari

20 luglio 2020                         69,74 miliardi di dollari

27 luglio 2020                         71,82 miliardi di dollari

3 agosto 2020                          73,18 miliardi di dollari

10 agosto 2020                        69,27 miliardi di dollari

17 agosto 2020                        81,94 miliardi di dollari

24 agosto 2020                        84,65 miliardi di dollari

31 agosto 2020                        104,72 miliardi di dollari

7 settembre 2020                    108,33 miliardi di dollari

14 settembre 2020                  124,10 miliardi di dollari

21 settembre 2020                  140,44 miliardi di dollari

28 settembre 2020                  136,40 miliardi di dollari

5 ottobre 2020                        139,28 miliardi di dollari

12 ottobre 2020                      158,11 miliardi di dollari

19 ottobre 2020                      144,68 miliardi di dollari

26 ottobre 2020                      130,37 miliardi di dollari

2 novembre 2020                    141,46 miliardi di dollari

9 novembre 2020                    114,15 miliardi di dollari

16 novembre 2020                  124,34 miliardi di dollari

23 novembre 2020                  133,40 miliardi di dollari

30 novembre 2020                  115,97 miliardi di dollari

Al 4 dicembre 2020, ha chiuso a 117,62 miliardi di dollari[1].

 

Per rendere immediatamente comprensibile l’andamento del titolo “ZM” sul NASDAQ, riportiamo un grafico che “traduce” fedelmente le cifre riportate sopra:

Fonte: “Macrotrends”[2]

 

In genere, la “SQL Injection” è conosciutissima con riferimento ai siti web. Per prendere di mira database su server, si “iniettano” dei pezzi di codice “SQL” dove – in situazioni di normalità – non si sarebbe dovuto inserire codice, spesso preceduti da un apostrofo (‘) che li trasforma in codice eseguibile.

Nel caso di specie, ovvero di una applicazione, invece di prendere di mira un database online, ovviamente si prende di mira un database locale.

Prima di addentrarci un minimo nell’argomento, vorremmo ricordare che le “SQL Injection” sono note da lunghissimo tempo e oggi è davvero poco spiegabile come si possa essere ancora vulnerabili ad un attacco perpetrato con tale mezzo.

Come accennavamo sopra, l’obiettivo – nel caso di specie – è il database locale, più precisamente il database delle impostazioni di “Zoom”.

Tutto parte da link di questo tipo: “zoommtg://”, che sono dei link alias che inviano ad una video-call “Zoom”. Se l’applicazione è installata sul proprio device, l’alias viene inviato ad esso, altrimenti – ovvero nel caso in cui si utilizzi l’applicazione sul web – l’alias agisce tramite il browser. I link di cui parliamo sono semplicemente quelli che dobbiamo “cliccare” per unirci ad una call.

Il problema di questi link, è che accettano parametri. Chiariamo subito che “Zoom” è un’applicazione proprietaria, non è un “Open source”, dunque non possediamo il codice, che è compilato e a cui non si ha accesso. Tuttavia qualcosa è recuperabile. Ad esempio, su piattaforma Linux e MacOS esiste il comando “strings”, che permette di vedere delle “stringhe” contenute all’interno di una applicazione compilata, in breve un “binario”. Con il comando “grep” (che ricerca in uno o più file di testo le linee che corrispondono ad uno o più modelli specificati con espressioni regolari o stringhe letterali, e produce un elenco delle linee – o anche dei soli nomi di file – per cui è stata trovata corrispondenza) si possono cominciare a filtrare queste “stringhe” alla ricerca di quelle “interessanti”.

Nello studio dell’attacco, ci si è imbattuti quasi subito in parziali “queries” SQL con parametri del tipo “%S” onde inserire dei parametri presi altrove all’interno dei “%S” … “%S”. La pericolosità risiede nel fatto che nello spazio da noi lasciato con tre punti, possono essere inseriti degli input di vario tipo, ad esempio il nostro “URL”.

Il passo successivo è l’utilizzo di un qualunque “debugger” per cercare quali valori in memoria modificano le “queries” sopra accennate. Ma, ovviamente, le “queries” citate vanno prima trovate. Nel caso di specie è venuta in aiuto una “stringa” trovata dal “debugger” che ha rivelato la versione di “SQLite” utilizzata. La “SQLite” è open source, quindi si studia il codice sorgente (tutto in chiaro e online senza violazioni di alcun tipo), si vede quali vulnerabilità può avere e, anche se non ci sono vulnerabilità, si possono trovare informazioni “interessanti”. Ad esempio la funzione “sqlite3LockAndPrepare”, subito trovata nel “debugger” dell’aggressore, permette di capire quali funzioni di “SQLite” vengono eseguite durante l’esecuzione di “Zoom”.  Una funzione, in particolare, si presenta come segue:

tid=0c123897abc1231231123b

 

UPDATE zoom_kv

SET value ‘0c123897abc1231231123b’

WHERE key=’tracking.code.join.meeting’

AND section=’ZoomChat

 

Come è evidente si tratta di un parametro “tid=”. Come accennato sopra, i summenzionati “%S” … “%S” prendono dati da tutt’altra parte, viene innescata una catena di “iniezioni” e ciò rende possibile l’inserimento, all’interno di questo parametro (“tid”), di codice indesiderato.

A questo punto, teoricamente, basterebbe porre un apostrofo davanti ai parametri per renderli eseguibili. Non è stato così, in quanto il programma “Zoom” possedeva una protezione contro le “iniezioni” SQL.

Una parte della protezione di “Zoom” contro questo tipo di attacchi, consiste nel raddoppiare il numero degli apostrofi inseriti all’interno della stringa. Ciò significa che qualsiasi numero di apostrofi venga inserito, il programma lo raddoppia, così facendo si otterrà sempre un numero pari di apostrofi, impossibile ottenere un numero dispari. Con ciò il discorso dovrebbe chiudersi.

Purtroppo l’aggressore non si è fermato qui. Ha pensato a cosa sia un apostrofo e si è dato una risposta corretta: è un carattere. Il programma “Zoom” utilizza l’”encoding” del testo “UTF-8”, che è di tipo “Unicode” (e non ASCII, molto limitato).

“Unicode” ha una particolarità: i primi due numeri bit sono riservati ad un uso particolare, i restanti 6 rappresentano il carattere vero e proprio. Se il numero rappresentato da un qualunque Byte è minore di un tot, ovvero i primi due numeri “riservati” sono zero, allora viene preso in considerazione solo quel Byte, cioè solo i sei bit rimanenti, per rappresentare un carattere.

Se “SQL” riceve il Byte 0x27 (zero, ics, 27) – che rappresenta il carattere “apostrofo” – immediatamente “Zoom” lo raddoppia, quindi si fallisce. Se inserissimo, invece, \xC2 (dove, nella sintassi, il backslash serve a far considerare ciò che segue come un Byte), che rappresenta un numero molto alto, il programma si aspetta che ci sia un secondo Byte che contribuisca a rappresentare il carattere che si voglia inserire. Ovvero, il programma si aspetta che il carattere che si voglia inserire sia costituito da due Byte. IL PGROGRAMMA È HACKERATO!!! All’aggressore è bastato scrivere \xC2’ (backslash, ics, ci, due e l’apostrofo). Siccome “Zoom” non interpreta \xC2 come Byte, ma come caratteri singoli (cioè li considera come parte di una stringa), appena “vede” il nostro “apostrofo”, immediatamente lo raddoppia. Tuttavia, quell’apostrofo – non da “Zoom”, ma a livello inferiore, ovvero da SQL – viene inglobato all’interno dello 0xC2 che richiedeva due Byte per descrivere un solo carattere. Il risultato è, per alcuni, uno strano carattere, ma in realtà è il, ben noto ai giuristi, segno di paragrafo: §. Dunque è stato sufficiente aggiungere un apostrofo (§’) per ottenere il tanto cercato apostrofo “dispari”, ovvero un apostrofo solo, che chiude la stringa, rendendo possibile inserire tutto il codice che si vuole.

I danni che si possono produrre sono molteplici e gravi. Ad esempio, modificare le opzioni di “Zoom”. Nel programma si possono cambiare, ovviamente, tantissime impostazioni, tuttavia, ce n’è una particolarmente sensibile. Nell’App in oggetto c’è un’impostazione particolarmente sensibile, che in italiano suona come: “Unisciti automaticamente alle chiamate con il video attivato quando apri un link”. Da ciò risulta chiaro che ogni volta che un utente apriva un link, l’aggressore aveva a disposizione le telecamere attivate di tutti coloro che navigavano cliccando su un link di interesse, potendo così spiare comodamente tutti coloro che avessero usato l’App “Zoom” hackerata per almeno una volta.

Fortunatamente l’azienda produttrice di “Zoom” si è attivata tempestivamente per risolvere il gravissimo problema. Pertanto ci teniamo a sottolineare che l’App “Zoom” è, da settimane, tornata ad essere sicura.

Vi sono due ordini di preoccupazioni:

• La ancora immensa vulnerabilità dei software ad “agenti patogeni” noti, alcuni, da oltre dieci anni;
• L’accelerazione degli attacchi cibernetici, soprattutto durante la pandemia, a colossi dell’industria sensibile mondiale: oltre l’attacco a “Zoom”, in questi giorni sono stati hackerati il gigante dell’industria strategica e militare italiana “Leonardo”, il gigante farmaceutico “Pfitzer” proprio durante l’uscita del vaccino anti-Covid19 e altri ancora.

Questi due ordini di preoccupazioni portano ad una riflessione, o meglio, ad una domanda di fondo che, a sua volta, si declina in vari modi: quando il mondo e, nel nostro caso, l’Italia comprenderanno che non ci si può permettere, soprattutto in riferimento alle Istituzioni e ad ogni ambito sensibile, una vulnerabilità così alta? Quando troveranno applicazione le misure che le Nazioni Unite e, soprattutto, l’Unione Europea ci impone? Non ce le chiede, ce le impone!

Chiunque conosca il web, i cosiddetti “malicious softwares”, i linguaggi di programmazione etc. è pienamente consapevole della minaccia enorme che questo habitat presenta. Tuttavia è inaccettabile che un Paese non adotti tutte le misure necessarie ed obbligatorie e non investa nella cybersecurity una parte ragguardevole di risorse pur sapendo benissimo che i disastri che possono derivare da un attacco mirato e riuscito arrivano fino a paralizzarlo o paralizzarne una parte.

Bisogna, inoltre, aggiungere che i cyber attack sono una forma di terrorismo, ma a differenza di quest’ultimo, non è appannaggio quasi esclusivo di cellule, ma spessissimo vengono perpetrati da Stati canaglia con gli scopi più diversi. Per essere chiari, spesso non siamo difronte ad una guerra asimmetrica!

Come tutti i Paesi del mondo, anche l’Italia è vittima della pandemia in corso. Tuttavia, il punto di partenza dell’Italia non era e non è paragonabile a quello di altri Stati, quindi la pandemia ha messo in ginocchio un Paese che partiva già in ginocchio sotto – quasi – ogni punto di vista. Dunque l’odiosa e dolorosa pandemia non ha fatto che la funzione dell’enzima, cioè del catalizzatore di processi biologici.

Pandemia o meno, non è più possibile rimandare una POLITICA che si occupi seriamente di questioni vitali per il Paese come la cybersecurity.

 

[1] Fonte: “Macrotrends”;  https://www.macrotrends.net/stocks/charts/ZM/zoom-video-communications/market-cap

[2] Ibidem