Per i cacciatori di taglie di bug, i repository GitHub possono rivelare una varietà di informazioni potenzialmente utili. Possono esserci problemi con obiettivi che non sono sempre open source. A volte le informazioni che potrebbero essere utilizzate contro l'azienda bersaglio vengono erroneamente rivelate dai membri dell'organizzazione e dalle loro iniziative open source. Ti darò una rapida panoramica in questo articolo che dovrebbe iniziare a scansionare i repository GitHub per le vulnerabilità e ad eseguire ricognizioni generali.

Clonazione di massa 1

Puoi semplicemente condurre le tue ricerche su github.com, tuttavia per abilitare i test locali, ti consiglio di clonare ogni repository di destinazione. GitHubCloner di @mazen160 è un prodotto fantastico. Tutto quello che devi fare è eseguire lo script per essere pronto a partire.

$ python githubcloner.py --org organization -o /tmp/output

      
                

                    
                    
                
            

È fondamentale comprendere effettivamente il progetto a cui miri prima di iniziare un'analisi statica. Usa le funzionalità principali durante l'esecuzione del progetto. Il motivo per cui mi riferisco a questo come al "passo di Jobert" è perché ho sentito che prima di iniziare ogni caccia, Jobert usa il progetto e ottiene una buona comprensione del bersaglio prima di cercare i punti deboli.

3- Analisi manuale

Il detto "impara a farcela, poi rompilo" si applica in questa situazione. Se riesci a imparare un linguaggio di programmazione, dovresti essere in grado di comprendere i dettagli delle precauzioni di sicurezza da prendere ed evitare.

Puoi iniziare a greppare una volta che hai familiarità con il bersaglio e la sua architettura. Cerca parole chiave che ti interessano, che conosci o che sai che gli sviluppatori spesso sbagliano.

Ecco un elenco di base di alcuni dei termini di ricerca che userò durante una prima valutazione generale:

• API e chiave. (Ottieni altri endpoint e trova le chiavi API.)
• gettone
• segreto
• FARE
• parola d'ordine
• vulnerabili
• http:// e https://

• CSRF
• casuale
• hashish
• MD5, SHA-1, SHA-2, ecc.
• HMAC

Un altro passaggio fondamentale consiste nell'esaminare la cronologia dei commit. Sarai sorpreso dalla quantità di informazioni che puoi raccogliere dai commit. Ho visto collaboratori credere erroneamente di aver rimosso le credenziali mentre rimangono nella cronologia dei commit. A causa della storia di git, ho scoperto antichi endpoint che funzionano ancora. A parte le preoccupazioni attuali, potresti imbatterti in problemi storici che potrebbero essere evitati a causa di vecchi commit.

4- Strumenti

A volte l'automazione delle attività noiose può aiutarti a darti una panoramica di base su cosa cercare. È fondamentale ricordare che non dovresti mai copiare e incollare i risultati della scansione nei rapporti. Otterrai molti falsi positivi, quindi dovresti sempre indagare attentamente su eventuali problemi potenziali per assicurarti che possano essere sfruttati.

Lo strumento principale che utilizzo quando perseguo progetti Python è Bandit .

Bandit identificherà problemi comuni ma spesso restituirà falsi positivi o frutti bassi. Quindi usalo con cautela. Senza dubbio, non dovrebbe essere invocato.

$ bandit -r path/to/your/code -ll

Snyk.io è uno strumento meraviglioso per controllare le dipendenze. La piattaforma supporta un'ampia varietà di lingue.

Per la ricognizione, molti ricercatori suggeriscono di utilizzare Gitrob . Questo strumento cercherà informazioni riservate nei repository GitHub pubblici.

$ gitrob analyze acme,johndoe,janedoe

$ truffleHog https://github.com/dxa4481/truffleHog.git

Per le app Ruby on Rails, consiglio Brakeman . Brakeman è uno scanner di sicurezza ad analisi statica che può trovare un sacco di vari problemi di sicurezza nel codice.

Usa LinkFinder di Gerben Javado per trovare gli endpoint nei file JS del repository.

$ python linkfinder.py -i 'path/to/your/code/*.js' -r ^/api/ -o cli

OK, seriamente, non ingegnerizzare i proprietari del progetto.

Segnalazione dei risultati

Come sempre quando si tratta di caccia alle taglie di bug, leggi attentamente la politica del programma. Molto raramente un programma accetta report tramite GitHub. Contatta il team di sicurezza o, se possibile, utilizza una piattaforma di bug bounty come HackerOne o Bugcrowd

In una nota a margine, una cosa interessante del test white-box è che poiché hai accesso al codice può essere più facile suggerire una correzione o inviare una patch.

GRAZIE PER AVER LETTO QUESTO!