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

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

engineeringdisclosureingegneriasicurezzavulnerabilita

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.

File .env

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 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 è piaciuto e ti è stato utile ti invito ad iscriverti al mio canale Telegram. Se invece hai domande o vuoi lasciare un commento puoi contattarmi direttamente su Telegram o su Twitter. A presto!