Modelli per la ricerca di un repository di origine per dati privati

5

Recentemente ho scoperto un caso in cui un collega aveva accidentalmente impegnato le proprie credenziali di accesso (host, nome utente e password) in un repository di codice sorgente locale, quindi ha trasferito queste modifiche a un repository pubblico su GitHub. Naturalmente, questo non è stato un incidente isolato: alcuni anni fa, GitHub ha ucciso la sua funzione di ricerca di codice completo dopo che le persone hanno scoperto centinaia di chiavi private e altre credenziali negli archivi pubblici .

Mi piacerebbe assicurarmi che questo genere di cose non sia accaduto in passato con nessuno dei nostri altri repository pubblici (e, nel caso abbia, per cancellare i dati privati, cambiare le password esposte, revocare le chiavi esposte, ecc.). Per me non è un problema mettere insieme uno script di shell per passare i commit a un determinato repository Git o Subversion in modo da poterli analizzare per ottenere dati privati. Ma che tipo di nome di file e modelli di testo dovrei usare? Ad esempio, voglio catturare file il cui nome suggerisce che contengono chiavi o credenziali private ( password.txt , id_dsa , id_rsa , secring.gpg , .netrc , e probabilmente molti altri standard che sto dimenticando o non ne sono nemmeno a conoscenza). C'è una lista da qualche parte che copre i casi più comuni? Allo stesso modo, mi piacerebbe scansionare il contenuto dei file di testo e di origine per i pattern che indicano le credenziali di accesso hard-coded. Forse qualcuno ha già prodotto un elenco di espressioni regolari da cui iniziare?

    
posta Psychonaut 22.06.2016 - 09:18
fonte

2 risposte

2

I file importanti variano in base al linguaggio di programmazione e all'ambiente. Ad esempio, se stai eseguendo nginx, .htaccess file, per impostazione predefinita, non influenzerà il comportamento del server. Tuttavia, quegli stessi file potrebbero davvero rovinare tutto se qualcuno ha caricato la tua applicazione in un ambiente Apache. Pertanto, è necessario personalizzare qualsiasi elenco in base alle proprie esigenze.

Ci sono alcuni file che sono probabilmente sempre considerati sensibili però:

  • Chiavi private ( id_rsa , id_dsa , *.pfx )
  • File shadow ( /etc/shadow ) - se li stai controllando nel controllo del codice sorgente senza una buona ragione, stai facendo qualcosa di sbagliato!
  • File di cronologia ( .bash_history e simili) - questi hanno spesso password che sono state digitate in modo errato o utilizzate nelle righe di comando per gli strumenti interattivi memorizzati
  • File di registro ( /var/log/* ) - di nuovo, spesso contengono dettagli che potresti dimenticare di cercare in

File più specifici che non dovrebbero essere nel controllo del codice sorgente:

  • .htaccess , .htpasswd - File di configurazione specifici di directory Apache
  • web.config - File di configurazione specifico della directory IIS
  • wp-config.php - Config di Wordpress
  • sites/*/*settings*.php - File di configurazione di Drupal
  • *.jks - File keystore
  • e così via ...

Github ha un buon esempio di contenuto del file gitignore , sebbene questi coprano anche cose che non dovrebbero essere nel controllo del codice sorgente a causa di altri motivi (ad esempio, l'output compilato non dovrebbe di solito essere nel controllo del codice sorgente, a causa di non essere fonte ...)

    
risposta data 22.06.2016 - 10:34
fonte
1

Esiste un'applicazione chiamata " OpenDLP " ( prevenzione della perdita di dati) che può essere utilizzato per setacciare la rete per dati sensibili. È basato su espressioni regolari, quindi puoi configurarlo per cercare quello che vuoi: password, parole chiave in proprietà intellettuale, numeri di previdenza sociale, carte di credito. Ciò contribuirebbe a ridurre al minimo le occorrenze di perdita di dati.

Ogni volta che eseguo il pentesting, mi piace trovare i dati nei repository. L'errore umano è sempre la causa numero di una violazione. Durante il mio pentesting, eseguo OpenDLP per aiutarmi a setacciare le condivisioni, i file server, il nome, alla ricerca di quelle che potrebbero essere le credenziali e / o le password. Non sono solo i sistemi pubblici che devono essere indirizzati, ma anche i sistemi interni, in cui un amministratore può lasciare un file di configurazione con credenziali che hanno una scarsa protezione sul file. Ciò consentirebbe a un utente malintenzionato di entrare in contatto con il client, per ridurre al minimo altri attacchi contro le credenziali (perché craccare le password se me le davano.)

Oltre a questo, non puoi davvero risolvere un problema sociale (dipendenti smemorati) con la tecnologia. La formazione e la consapevolezza non possono che andare così lontano. L'applicazione e il test di quella formazione sono ciò che conta di più. Prenditi il tempo necessario per far capire ai tuoi dipendenti: "Prima di inviare / caricare / modificare / distribuire il tuo lavoro, prenditi un momento per assicurarti di non aver divulgato informazioni sensibili. Chiunque non segua la procedura è soggetto ad un avviso, seguito da sospensione, seguito dalla risoluzione. "

    
risposta data 22.06.2016 - 14:35
fonte

Leggi altre domande sui tag