Cosa abbiamo imparato sulla sicurezza segreta al AppSec Village a DEF CON 32

Se sei cresciuto negli Stati Uniti, probabilmente hai una memoria di aver frequentato un campeggio estivo. Anche se non sei mai stato, l’esperienza del campeggio di andare via da casa, imparare tutti gli stili d’arte e le arti manifatturiere, incontrare nuovi migliori amici e condurre avventure memorabili è integrato nella cultura di massa e nei media. Ogni agosto, il più grande campeggio estivo per hacker sulla terra si svolge nel caldo di Las Vegas. Quest’anno ha segnato la trentaduesima iterazione del DEF CON .

DEF CON può essere difficile spiegare senza averlo sperimentato. Certo, ci sono tracce di conversazione, workshop ufficiali e molti capture-the-flags (CTF), ma c’è molto di più. Nessun’altra conferenza contiene così tante sotto-conferenze e eventi guidati dalla comunità. Anche gli assistenti che sono stati presenti per anni dicono di non aver ancora sperimentato tutto ciò che offre.

Nonostante non ci sia un numero ufficiale pubblicato dagli organizzatori, gli eventi passati sono stati compresi tra i 25.000 e i 30.000 assistenti. Ognuno di loro porta con sé un amore per la tecnologia e molto da condividere. I corridoi sono pieni di persone che programmano hardware, scrivono software, fanno musica, condividono adesivi e fanno succedere tutto il divertimento del DEF CON.

Le Villaggi

C’erano 33 villaggi all’interno di DEF CON 32. questi coprono una vasta diversità di interessi,从 Hacking aerospaziale, Ingegneria sociale e Informazione erronea, a Red Teaming e AppSec. Ogni villaggio è organizzato in modo indipendente e offre un insieme unico di talk, workshop e attività pratiche per i partecipanti per interagire con l’area specifica della loro attenzione.

Villaggio AppSec era uno spazio prezioso all’interno della comunità più ampia di hacker e sicurezza che si concentra sulla difesa delle applicazioni che guidano tutta la nostra vita. Il tuo autore era uno dei fortunati che hanno aiutato a organizzare e gestire il Villaggio AppSec 2024.

Indovina i segreti

Tornando al Villaggio AppSec alla RSA Conference 2024, GitGuardian ha rivelato la nostra “Indovina i segreti”, un gioco a carte che simula l’esperienza di revisione del codice manuale per la ricerca di credenziali in chiaro. I giocatori sono chiesti di competere per trovare tutti gli API key nascosti, password e altri segreti in chiaro che gli aggressori potrebbero utilizzare per ottenere accesso ulteriore a una raccolta di esempi di codice, ticket Jira, file di log e messaggi Slack.

Indovina i segreti al Villaggio AppSec, modificato per far rispettare le regole fotografiche di DEF CON

Alla DEF CON, nel corso di 2 giorni, oltre 120 persone sono passate per il nostro POD all’interno del AppSec Village per sperimentare personalmente questo esercizio. Abbiamo persino creato una classifica dei leader dove i giocatori più veloci, con il minor numero di errori, hanno vinto dei premi speciali.

Le domande sulle chiavi di sicurezza più comuni

Appena le persone hanno iniziato a esaminare le carte contenenti il codice, abbiamo ricevuto una vasta gamma di domande. Crediamo sia benefico condividere alcune di queste domande, in caso non avessiate ancora sentito le risposte a queste preoccupazioni.

Ecco le 11 domande più comuni che abbiamo sentito e le nostre risposte.

1. Cosa è esattamente un commit?

Un commit è un unità di lavoro in Git, il sistema di controllo di versione utilizzato da oltre il 97% dei sviluppatori mondiali. È una fotografia del file system in un determinato momento del tempo, che include tutto il lavoro svolto dal programmatore dalla precedente commit. Se mettete i commit uno dopo l’altro, otterrete la storia di Git, che vi permette di esaminare ogni modifica fatta incrementalmente durante la vita del codice base. Uno dei segreti sicuri nel utilizzare Git è che la storia è un record permanente condiviso. Se una chiave segreta è aggiunta ad una commit e rimossa nella commit successiva, la commit con la chiave segreta rimane ancora conservata.

2. Come identificate se una cosa è una chiave segreta?

Un segreto è qualsiasi credenziale che fornisce accesso diretto a un sistema o a dati. Possono assumere la forma di chiavi API, password, certificati e token, tra gli altri. Uno dei motivi per cui è difficile riconoscerli è che vengono utilizzati in molti modi all’interno del codice e dalla riga di comando. Per esempio, all’interno di un file di configurazione, una variabile specifica può essere impostata per una chiave API. Ma per sistemi come Slack, il token API è integrato nella URL stessa, il che significa che dovreste conoscere quel sistema per sapere che è un segreto.

Molti sistemi usano numeri lunghi e unici nelle loro URL del界面的, che possono somigliare molto ai token in linea. Per esempio, le URL di Figma potrebbero sembrare contenere una stringa codificata in base64 nel percorso. tuttavia, se segui un link di Figma casuale, viene presentato un schermo di login, poiché deve essere un utente autenticato per connettersi a quella pagina. Poiché non concede automaticamente accesso al sistema ma solo identifica la posizione della pagina, un attaccante senza una foothold in Figma riceverebbe l’errore “No Access” e proseguirebbe. Questo è un’altra ragione per cui è utile adottare strumenti per identificare i segreti, poiché ci sono piattaforme in grado di determinare rapidamente la differenza tra una URL che contiene un token di autorizzazione e una che solo sembra poterlo contenere.

3. Che cosa significa Valido?

Valido, nella nostra accezione, significa che una particolare credenziale ancora funziona per consentire l’accesso al sistema o ai dati relativi. Se una segreta validità è trovata da un attaccante, può essere utilizzata immediatamente. Mentre le segrete non validità possono dare all’attaccante un quadro generale dell’architettura e dei sistemi interconnessi, solo le segrete validate offrono loro un percorso diretto verso queste risorse. Questo tipo di spostamento laterale può essere difficile da rilevare.

4. Come faccio a sapere quali segreti sono quelli giusti da cercare?

La risposta migliore è trovare e rimuovere qualsiasi segreta valida. Tuttavia, come dimostra Spot the Secrets, questo è un problema difficile da risolvere senza gli strumenti giusti. Revisioni manuali del codice o tool che dipendono solo da un semplice pattern matching può farti spendere tempo a rimedare segreti già invalidati invece di concentrarti su quelli validi. Le chiavi scadute non costituiscono una grande minaccia, quindi i tentativi per eliminarle dovrebbero avere una priorità inferiore a quelli per scoprire credenziali valide.

5. Qual è la differenza tra un segreto e del codice scritto male?

Gli attaccanti probabilmente non leggono il tuo codice la maggior parte del tempo; stanno scannerizzando per specifici modi per ottenere accesso più ampio il più velocemente possibile. Del codice scritto male può contenere molte vulnerabilità che un attaccante può utilizzare, specialmente attorno alla configurazione dell’Infrastructure as Code. Tuttavia, per sfruttare questi errori è necessario per un attaccante dedicare tempo per capire il difetto e condurre un attacco specifico contro questi problemi invece di semplicemente sfruttare le credenziali in chiaro.

I nomi delle variabili e gli username possono essere utilizzati come parte di un attacco più sofisticato. Per esempio, gli username e gli indirizzi email trovati nel codice possono essere utilizzati negli attacchi a password spray o negli tentativi di forza bruta, ma questi sono molto più facili da rilevare rispetto all’uso diretto di segreti e richiedono molto tempo all’attaccante.

6. Ma Cosa faccio una volta che trovo un segreto?

Prima di tutto, fermati e respira. capita a chiunque, quindi non siate troppo sconvolti se trovate un segreto divulgato. È buono agire con urgenza, ma non panicare e revocare un segreto trovato senza sapere cosa accadrà. questo può causare una moltitudine di altri problemi.

Consigliamo di seguire il seguente percorso:

1. Comprendere cosa il segreto apre.
2. Capire quantocritico sia ogni dato o sistema associato.
3. Controllare i vostri log per l’uso non autorizzato del segreto.
4. Determinare se è stato divulgato accesso a dati o servizi.
5. Scoprire cosa si romperà quando rotolerai il segreto.
6. Rotolare il segreto e memorizzare le nuove credenziali in sicurezza.
7. Risolvere eventuali flussi di lavoro o deployamenti di produzione rotti.
8. Rivedere l’incidente e creare un piano d’azione per evitare ulteriori divulgazioni di segreti.

Leggi ulteriori informazioni sul processo di ripristino nell’articolo “Cosa fare se riveli un segreto: come rimanere calmo e rispondere ad un incidente“.

7. La mia squadra re scrive sempre la storia di Git quando viene scoperto un segreto. È questo tutto ciò che devo fare?

Purtroppo, no. Nonostante adoriamo il passo di pulizia di Git del processo di rimediazione, è veramente l’ultimo passo e viene considerato opzionale da molte organizzazioni. Raccomandiamo di rotolare tutti i segreti mai esposti come testo in chiaro (vedere il link soprastante per consigli sulla procedura di rimediazione).

8. rimuovo solo il repo dalla pubblicazione. Non è sufficiente?

Sinceramente, noi vorremmo che fosse così, ma sfortunatamente per tutti noi, appena è stato esposto su GitHub pubblicamente, dovrebbe essere considerato sempre compromesso. GitGuardian scannerizza ognuno di nuovi commit e di eventi isPublic che si verificano sulla API pubblica di GitHub.

Questo è il modo in cui costruiamo il nostro rapporto annuale State of Secrets Sprawl e costituisce la base per l’offerta di monitoraggio pubblico GitGuardian. Anche se le nostre intenzioni sono di avvisare i committatori che hanno fatto qualcosa di potenzialmente pericoloso, non siamo gli unici attori a monitorare questa API pubblica. Dovresti sempre assumere che ci sia una copia di ogni codice o file che tu abbia mai caricato pubblicamente, creato da qualcuno che non conosci, e conservato in qualche posto che non conosci. Consigliamo sempre di rotolare tutti i segreti potenzialmente esposti.

9. Perché i falso positivi sono un problema?

Nell’esercizio Spot the Secrets, chiediamo agli utenti di trovare tutti i segreti inseriti all’interno di 100 possibili commit, Jira, Slack e schede Log, applicando una penalità di tempo per ogni falso positivo. Ogni scheda in cui il giocatore pensa erroneamente che una scheda contenga un segreto quando non lo fa subirà una penalità di 10 secondi per errore.

Mentre all’interno del contesto limitato dell’esercizio potrebbe sembrarci utile essere estremamente cauti e segnalare anche cose che non contengono segreti, in realtà questo comportamento è un tempo sprecato, sia per te, il relatore, che per chiunque abbia l’incarico di lavorare ad una soluzione.

Qualsiasi strumento o processo che genera troppe false positive porta alla fatica da allarmi. Gli utenti sono sommersi da allarmi e cominciano a ignorarli. Questo porta alla perdita di fiducia negli strumenti e ad un loro uso non consistente. Può anche bloccare il processo di riparazione complessivo e significare che alcuni segreti positivi segnalati non vengono curati in tempo.

10. Che c’è della relazione tra il nome del file e l’identificazione di un segreto?

In breve: il contesto. I segreti generici sono particolarmente difficili da trovare attraverso il pattern matching soltanto. Se c’è una lunga stringa in un file markdown, le nostre scoperte suggeriscono una probabilità elevata che sia un esempio di password, quindi probabilmente non dovresti occupartene. Se, invece, la stessa stringa compare dopo la stringa password= in un file chiamato project.env, allora c’è una probabilità molto più alta che tu abbia davvero un segreto in mano.

Il nome del file è solo uno degli elementi che consideriamo con il Pre- e Post Validation nel motore di rilevamento segreti GitGuardian e è uno dei fattori che ci aiuta a eliminare le false positive all’interno della piattaforma FP remover.

11. Le persone fanno davvero revisioni manuali del codice per trovare i segreti?

Sì. Ben il 27% dei decisori IT intervistati ha dichiarato di affidarsi a revisioni manuali del codice per porre rimedio alla dispersione di segreti, anche se il 75% ha dichiarato di essere stato colpito da una fuga di segreti.

Spot the Secrets è stato progettato per mostrare i problemi legati all’affidarsi all’uomo per individuare questi problemi. Le macchine sono molto più brave a individuare i pattern in migliaia o milioni di righe di codice.

Imparare insieme è ciò che fa la DEF CON

Alla DEF CON abbiamo imparato molte altre lezioni, tra cui rimanere idratati, dormire almeno un paio d’ore a notte e rimanere al chiuso quando fuori ci sono più di 110°F/43°C.

C’erano tantissimi interventi eccellenti in programma; non vediamo l’ora che i video siano disponibili per recuperare i contenuti che ci siamo persi mentre aiutavamo le persone a conoscere il Secrets Sprawl. Abbiamo imparato molto su come gli addetti alla sicurezza, gli sviluppatori e le persone in generale vedono questo problema e pensano alle soluzioni. Noi di GitGuardian speriamo di incorporare queste lezioni per rendere la soluzione di questo problema più accessibile e più facile per tutti noi.

Se non avete mai preso in considerazione l’idea di andare al DEF CON, ve lo consigliamo caldamente, se non altro per partecipare all’AppSec Village e per trovare la vostra tribù al campo estivo hacker.