Directory .git esposta

Cos’è Directory .git esposta?

Una distribuzione che copia l'albero di lavoro in una radice web copia .git con esso. Quella cartella contiene ogni commit e ogni versione di ogni file, non solo ciò che è live. Chiunque possa richiederlo può ricostruire l'intero albero dei sorgenti, compresi i segreti rimossi nei commit successivi. Richiederai /.git/ su un sito live, eseguirai git-dumper per ricostruire la fonte e leggerai da esso una password del database. Quindi bloccherai il percorso sul server web, distribuirai gli artefatti creati invece del repository e ruoterai ciò che è trapelato.

Cosa imparerai in Directory .git esposta

• Riconoscere una directory .git esposta: una distribuzione che spedisce l'intero repository alla radice web trasforma un URL pubblico in una fonte completa e nella divulgazione della cronologia
• Traccia l'attacco da un elenco /.git/ esplorabile e un .git/config leggibile, a un pull git-dumper che ricostruisce l'albero dei sorgenti, ai segreti recuperati dalla configurazione committata
• Tieni presente che .git conserva l'intera cronologia dei commit, quindi le credenziali modificate o eliminate nei commit successivi rimangono recuperabili da un repository esposto
• Applicare una soluzione duratura: distribuire gli artefatti creati anziché il repository in modo che .git non raggiunga mai la produzione e ruotare tutte le credenziali rivelate dall'esposizione
• Distinguere l'esposizione lato server di un repository sul Web dai segreti presenti nella cronologia dei commit di un repository ospitato e considerare il blocco dell'URL /.git come una soluzione tampone piuttosto che una soluzione completa

Directory .git esposta — Fasi della formazione

1. Dimensionare il bersaglio

   Oggi Bob si rivolge a Verlune, una società di analisi dei prodotti il cui dashboard viene eseguito su app.verlune.io. Inizia da dove chiunque farebbe, sul sito pubblico, per farsi un'idea di ciò che l'azienda spedisce prima di cercare un modo per entrarci. L'app stessa dice poco. Gli errori interessanti si trovano solitamente nei percorsi a cui un sito non intendeva rispondere.

2. Un percorso che non dovrebbe rispondere

   Bob richiede /.git/ direttamente sullo stesso host, un percorso che un server ben configurato non esporrebbe mai. Invece di un 404, il server risponde con un elenco di directory esplorabile. I file interni di un repository Git, HEAD , config , objects , si trovano tutti nella radice web, serviti come qualsiasi altra pagina.

3. È un vero e proprio deposito

   Bob fa clic sul file config nell'elenco. Si legge come una normale configurazione Git: l'origine remota, il ramo predefinito, le impostazioni dell'utente. Questo non è un file smarrito che qualcuno ha lasciato indietro. L'intero repository funzionante è stato inviato in produzione, quindi la sua cronologia completa è a un download di distanza.

4. Ricostruire la fonte

   Bob non fa clic manualmente sull'elenco. Punta uno strumento di dumping sulla cartella esposta, che percorre gli oggetti che serve e ricostruisce l'albero di lavoro esattamente come esiste nel repository. In pochi secondi ha il codice sorgente completo dell'app Verlune sul suo computer, la cronologia e tutto il resto.

5. Credenziali nell'origine

   Una volta ricostruito il sorgente, Bob apre la configurazione del database ripristinato. Le cose più preziose in un repository trapelato raramente sono il codice stesso, sono i segreti custoditi insieme ad esso. Non deve guardare attentamente.

6. Una password e una chiave

   Il file recuperato consegna a Bob due segreti live in testo semplice: la stringa di connessione al database di produzione, la password inclusa e una chiave API per l'API di amministrazione. Entrambi sono stati inseriti direttamente nel codice sorgente, motivo per cui un repository esposto li fa trapelare.

7. Connettiti con le credenziali trapelate

   Una credenziale trapelata è solo una teoria finché non apre qualcosa. La configurazione recuperata fornisce a Bob una stringa di connessione al database completa, host, nome, utente e password, quindi apre un client SQL e con esso si connette direttamente al database di produzione di Verlune. Nessun exploit e nessuna sessione rubata: il database si fida della password fornita dal repository.

8. La tabella dei clienti è aperta

   Connesso. Bob esegue la query ovvia e la tabella dei clienti di produzione ritorna completa: nomi, e-mail, piani e fatturazione. Sta leggendo i registri dei clienti in tempo reale di Verlune direttamente dal database, senza alcun resoconto proprio.

9. Verifica della conoscenza

   Hai appena visto un singolo URL pubblico consegnare l'intero albero dei sorgenti e i suoi segreti. Blocca il perché.

10. L'allarme del monitoraggio

    Possiedi la pipeline di distribuzione web di Verlune. Durante la notte, il controllo di monitoraggio che controlla i percorsi sensibili nella produzione è stato attivato: ha recuperato .git/config su app.verlune.io e ha ottenuto un 200. Le operazioni di sicurezza ti hanno inviato il risultato via email.