Responsible disclosure: SQL Injection su portale sanitario

Hero image: ho trovato una sql injection in un portale sanitario

I dati sanitari delle persone dovrebbero essere tra i segreti meglio custoditi al mondo visto che la loro divulgazione senza esplicito consenso risulterebbe in una gravissima violazione della privacy dei pazienti. Non a caso ogni singolo dato sanitario ottenuto può valere fino a 250$ nel mercato nero .

Proprio per questo motivo mi aspetto che gli applicativi software che trattano questi dati siano protetti seguendo i più alti standard di sicurezza informatica esistenti.

Immaginate il mio stupore quando mi sono accorto che uno dei portali web utilizzati dai medici per il controllo dei proprio assistiti era vulnerabile a quello che OWASP mette al primo posto come fattore di rischio per le web app: la SQL Injection.

Per chi non sapesse di che cosa parlo, tramite un attacco di tipo SQL Injection un attaccante è in grado di eseguire dei comandi in linguaggio SQL con i quali può leggere, alterare ed eliminare qualsiasi dato presente all’interno di un database.

Non oso nemmeno immaginare le conseguenze disastrose che avrebbe potuto avere l’accesso e la divulgazione non consentita dei dati anagrafici e dei percorsi sanitari di migliaia e migliaia di pazienti.

Ma prima di procedere con i dettagli della SQL Injection mi presento: sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Iscriviti anche al mio canale Telegram in cui ogni martedì parliamo di piccole curiosità legate al mondo della tecnologia!

Cos’è una SQL Injection

Un attacco di tipo SQL Injection è un attacco che sfrutta la mancata validazione degli input digitati dall’utente per fare in modo che questi vengano interpretati come comandi per il database al fine di introdursi in un sistema informatico.

SQL infatti è un linguaggio di programmazione utilizzato per creare, modificare ed interrogare un database relazionale.

Normalmente quando un utente prova ad inserire un’istruzione SQL all’interno di un campo di input (come potrebbe esserlo il campo username di una pagina di login) il sistema si occupa di validare i dati inseriti accertandosi che non ci siano caratteri illeciti e/o facendone la traslitterazione verso una versione non dannosa (ad esempio il carattere < di solito viene convertito in &lt;).

Se questo processo di validazione dei dati immessi dall’utente non avviene potrebbe essere possibile sferrare un attacco di tra quelli appartenenti alla famiglia delle injection (a cui la SQL Injection appartiene).

Il tipico esempio di SQL Injection riportato in tutti i libri di testo è quello di una schermata di login in cui, per verificare che username e password siano corretti, viene usata la seguente query:

SELECT * FROM users WHERE username = "Foo" AND password = "bar" 

Un attaccante potrebbe aggirare questa schermata di login digitando come username Foo e come password " OR "" = ". In questo modo la query con i dati inseriti dall’utente diventerebbe:

SELECT * FROM users WHERE username = "Foo" AND password = "" OR "" = "" 

E poiché l’uguaglianza tra stringhe vuote "" = "" risulta essere sempre verificata l’attaccante si vedrebbe garantito l’accesso al sistema come un regolare utente senza che sia stato necessario conoscerne la password.

La SQL Injection sul portale

Esattamente come nell’esempio descritto poco sopra, nel portale in questione era possibile aggirare la pagina di login confezionando una stringa SQL ad-hoc e usandola come nome utente.

Per verificare l’esistenza del problema mi è bastato inserire il carattere ' nel campo username della pagina di login ottenendo come risposta la query SQL che il server ha provato ad eseguire per verificare la correttezza delle credenziali inserite.

Il messaggio d’errore restituito inserendo il carattere ‘ come username

Una volta accertata l’esistenza del problema mi sono immediatamente preoccupato di contattare chi di dovere affinché approntasse un fix per la vulnerabilità.

Timeline

20/10/2020 Mi accorgo del problema sul portale

20/10/2020 Invio email all’indirizzo di supporto generico (mai risposta)

26/10/2020 Invio email al dirigente del reparto IT che mi mette in contatto con il tecnico incaricato del portale

28/10/2020 Riporto la vulnerabilità al tecnico responsabile

11/11/2020 Mi segnalano che la vulnerabilità è stata sistemata

Conclusioni

Il problema sembra essere stato corretto e ora quando si prova ad inserire il carattere ' all’interno dei campi di login non viene più visualizzata la query SQL eseguita ma viene mostrata una semplice pagina bianca. Tutto bene quel che finisce bene.

O no?

Sinceramente ho l’impressione che il problema sia stato “risolto” semplicemente nascondendo il messaggio d’errore e lasciando la vulnerabilità esattamente dove si trova ma siccome non sono in grado di dimostrare questa mia ipotesi confido nella bontà della correzione. Avrei dormito sogni tranquilli vedendo un messaggio d’errore generico del tipo “nome utente non valido” piuttosto che una pagina bianca.

In ogni caso, vista la natura estremamente sensibile dei dati sanitari, mi auguro che le istituzioni incaricate al controllo e alla gestione di questi dati si impegnino maggiormente a garantire i più alti standard di sicurezza possibili.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Software engineer presso Slope.
Appassionato di videogame, nel tempo libero mi diletto a scrivere su questo blog.
Per non perderti nemmeno un post puoi seguirmi su Telegram!

Responsible disclosure: esposizione della cartella .git su di un sito di comparazione prezzi

responsible disclosure

Era un normalissimo Lunedì mattina. Come sempre, prima di iniziare a lavorare, stavo facendo una navigata sul web. Ero appena entrato sul sito di una compagnia di comparazione prezzi quando una notifica del browser cattura la mia attenzione: Found an exposed .git.

L’estensione del browser che utilizzo per verificare automaticamente se un sito web ha la cartella /.git esposta ne aveva appena beccato uno.

Ops, ho appena trovato una cartella .git pubblicamente accessibile

Se non sei uno sviluppatore ti starai chiedendo: “è quindi”? Se invece conosci Git sai già quanto possa essere potenzialmente grave avere la cartella .git pubblicamente accessibile.

Infatti attraverso l’accesso a quella cartella sono riuscito ad estrapolare le chiavi di accesso al database!

A livello puramente teorico, in assenza di ulteriori meccanismi di protezione, ottenere credenziali del genere potrebbe garantire ad un malintenzionato l’accesso in lettura e scrittura ai dati di tutti gli utenti della piattaforma (username, hash di password, ecc…).

Ma prima di vedere nel dettaglio che strumenti ho usato per accorgermi della vulnerabilità e come è andata a finire la storia lasciami presentare. Io sono Lorenzo Millucci e sono un ingegnere del software che ama lavorare con Symfony e a cui piace condividere in questo blog le cose che impara. Iscriviti al mio canale Telegram per non perderti nessuna notizia!

Cos’è Git?

Andiamo con ordine. La prima cosa che ti serve sapere per capire quale sia stato il problema di sicurezza è capire cosa sia Git e perché avere accesso a quella cartella è un problema di sicurezza.

Git è un popolarissimo software utilizzato dagli sviluppatori per tracciare le modifiche del codice sorgente (versionamento) creato da Linus Torvalds (il creatore di Linux) nel 2003.

Per tracciare tutti i cambiamenti all’interno di una codbase, Git mantiene tutti i (meta-)dati necessari all’interno di una cartella nascosta chiamata .git.

Normalmente Git è uno strumento utilizzato esclusivamente internamente ai team di sviluppo e i meta-dati che produce non sono accessibili pubblicamente. Può però capitare che a causa di una dimenticanza o di una cattiva configurazione del server questa cartella non venga opportunamente protetta e che sia quindi leggibile da chiunque.

Avendo accesso alla cartella .git è possibile estrapolare diverse informazioni sensibili sul sito web semplicemente guardando i file in essa contenuti:

  • .git/config: è il file di testo utilizzato da git per tracciare le informazioni generali sul repository (es. l’URL del server con il repository, l’username, le branch attive… )
  • .git/index: è il file contente l’indice di tutti i file presenti nel repository e di tutte le modifiche fatte. Il file è in formato binario ma esistono dei tool appositi in grado di leggerne il contenuto.
  • .git/objects: è la cartella che contiene tutte i file del progetto. Tutti i file sono salvati senza estensione e utilizzando l’hash SHA1 come file name. E’ da questa cartella che è possibile estrapolare dati sensibili del sito web.

Come mi accorgo di una cartella .git esposta pubblicamente?

Ora che hai capito cos’è Git ti chiederai come si fa a verificare se la cartella .git è pubblicamente accessibile su una web-app.

Il metodo più semplice (e più macchinoso) per verificare se una cartella .git è esposta pubblicamente è quello di provare a modificare l’URL della pagina aggiungendo di volta in volta il percorso alla cartella .git nel seguente modo:

  • https://example.com/.git/config
  • https://example.com/.git/HEAD
  • https://example.com/.git/logs/HEAD
  • https://example.com/.git/index

Siccome farlo manualmente è una scocciatura è possibile scaricare un estensione del browser (per Firefox e Chrome) chiamata DotGit che permette di effettuare la verifica automaticamente. Nel caso in cui i file sono pubblicamente accessibili l’estensione lo farà presente immediatamente con una notifica.

Che ci faccio con la cartella .git?

Ora arriva la parte divertente. Una volta che ho trovato una cartella Git esposta tutto quello che devo fare è utilizzare un software chiamato GitTools per scaricare ed estrarre automaticamente tutto il codice lasciato incustodito.

Per scaricare il contenuto della cartella .git basta dare il comando:

./Dumper/gitdumper.sh https://example.com/.git/ /output-directory/

Siccome spesso i repository vengono compressi può succedere che i dati scaricati non siano immediatamente leggibili. Proprio per questa evenienza i GitTools mettono a disposizione un altro strumento che permette di carpire quanta più informazione possibile dal repository scaricato.
Per usare questo strumento il comando da utilizzare è:

 ./Extractor/extractor.sh /output-directory/ /output-directory-extracted/

Una volta che il tool avrà finito di estrarre il contenuto della cartella sarà possibile esplorare il codice sorgente. A seconda dell’applicazione web è possibile cercare all’interno del codice chiavi di accesso, credenziali hardcodate, nuovi endpoint segreti, ecc…

Disclosure

Ma ritorniamo a Lunedì mattina. Avevo appena ricevuto la notifica da parte di DotGit. Ero abbastanza stupito che un sito così famoso avesse potuto commettere un errore tanto banale senza che nessuno se ne accorgesse.

Così ho provato a vedere cosa ci fosse all’interno del repository utilizzando i GitTools e mi sono accorto che tra i file c’era il file di configurazione .env contenete le chiavi di accesso ai vari database del sito.

Uno dei “pericolosi” file che contengono le chiavi di accesso ai database. Naturalmente ho oscurato i dati sensibili

Io non ho provato a connettermi ai vari database del sito visto che il mio interesse era puramente “accademico” e visto che molto probabilmente sono protetti da ulteriori meccanismi di protezione. Tutto quello che ho fatto è stato segnalare la vulnerabilità al supporto tecnico del sito che si è rivelato svelto a rispondermi e a risolvere il problema.

Timeline

  • Lunedì 22/06/2020 navigando prima di attaccare al lavoro mi accorgo della vulnerabilità;
  • Lunedì 22/06/2020 11:24 contatto il supporto del sito per segnalare la vulnerabilità;
  • Lunedì 22/06/2020 13:05 mi risponde il responsabile tecnico del sito;
  • Lunedì 22/06/2020 13:17 segnalo il problema al responsabile;
  • Lunedì 22/06/2020 15:21 il supporto mi segnala che il problema è stato risolto.

Conclusioni

Alla fine tutto bene quel che finisce bene. Sfortunatamente il problema di lasciare cartelle .git esposte è più comune di quanto si pensi. Tanto è vero che anche OWASP (il progetto che ha come scopo la sicurezza delle applicazioni web) lo inserisce tra i requisiti da verificare per garantire la protezione da accessi indesiderati ai siti web.

In ogni caso l’assistenza si è dimostrata rapida ed efficace nel risolvere il problema e mi piace pensare che ora il web sia diventato un po’ più sicuro anche per merito mio.

Nonostante il problema sia stato gestito e risolto in maniera impeccabile l’azienda in questione mi ha chiesto di non divulgare il suo nome e di conseguenza non è riportato da nessuna parte nell’articolo.


Se questo post ti è stato utile puoi farmelo sapere lasciando un commento qui sotto oppure scrivendomi direttamente a t.me/lorenzomillucci.
Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!

Software engineer presso Slope.
Appassionato di videogame, nel tempo libero mi diletto a scrivere su questo blog.
Per non perderti nemmeno un post puoi seguirmi su Telegram!