Fughe di segreti: un passo verso la scopertasaster

Dare le chiavi di casa a dei criminali non è sicuramente la migliore idea. Ma questo è ciò che spesso accade nella maggior parte delle organizzazioni che sviluppano software moderno.

In questo primo post sulle fughe di segreti, analizzeremo perché ciò accade così spesso, quali sono le conseguenze e quali azioni intraprendere per prevenire o mitigare il problema e gestire gli incidenti di fuga di segreti.

OH MIO DIO! Ho inviato le mie chiavi di accesso al cloud a un repository pubblico

Segreti codificati nel codice sorgente o nei file di configurazione negli strumenti DevOps potrebbero finire in cattive mani. Se il segreto è commitinserito in un repository di fonti pubbliche, sei sicuramente condannato. Ma anche gli archivi privati ​​non sono sicuri, poiché i segreti vengono divulgati anche attraverso i file binari delle applicazioni, i log o il codice sorgente rubato.

In retrospettiva, è inquietante quante volte una semplice svista ha portato a una grave violazione della sicurezza. Basta cercare su Google"Perdite di chiavi AWS","Perdite di token di accesso GitHub", e così via. Non prendere questi esempi come raccomandazioni nascoste per questo o quel fornitore. Usa il tuo !

Ad esempio, il (in)famoso Attacco Codecov di aprile 2021 è stato possibile perché l'immagine Docker di Codecov conteneva credenziali git che consentivano a un utente malintenzionato di ottenere l'accesso ai repository git privati ​​di Codecov e di aggiungere una singola riga nello script bash uploader di Codecov per le variabili di ambiente della raccolta e gli URL del repository git.

Ricorda che parte della ricompensa negli attacchi sono i segreti per ottenere l’accesso a sistemi aggiuntivi e che molti attacchi investono molto su credenziali, chiavi crittografiche ed esfiltrazione di token. 

Il problema è che i segreti codificati sono un luogo comune. Nel marzo 2022 il Lapsus$ APT trapelati 189 GB del codice sorgente Samsung e di altri file sensibili. L'analisi ha rivelato che ne conteneva alcuni 6,600 segreti codificati: 90% per i sistemi interni, ma 10% per servizi e strumenti esterni come GitHub, AWS o Google. Tali segreti includevano chiavi API AWS/Twilio/Google, stringhe di connessione al database e altre informazioni sensibili. Questo è lo stato dell'arte nella maggior parte dei codici base.

Le fughe di segreti rappresentano il percorso più semplice per attacchi alla catena di fornitura

Le dipendenze dai pacchetti sono attualmente l’obiettivo più frequente, anche se non l’unico, degli attacchi alla catena di fornitura. I malintenzionati potrebbero creare un nuovo pacchetto che verrà installato nel software delle vittime (utilizzando typosquatting e altre tecniche), ma in genere cercano di infettare un pacchetto esistente aggiungendo modifiche al codice sorgente nei repository software (SCM) come GitHub, GitLab o BitBucket, oppure aggiungendo versioni dannose a registri pubblici come NPM, PyPI, RubyGems, Maven Central.

Ma è necessario inserire codice dannoso o una dipendenza dannosa nascosta in un intricato grafico delle dipendenze login credenziali come nome utente/password, token o chiavi di accesso (chiamiamole “Tasti" in breve), rispettivamente per il repository di origine di destinazione o il registro pubblico. 

I cattivi a volte ottengono le chiavi tramite Ingegneria sociale. attacco al event-stream il popolare pacchetto NPM fornisce un bell'esempio. Ma la ricerca è trapelata login credenziali o chiavi di accesso rappresentano la tecnica di attacco più frequente per gli attacchi alla catena di fornitura del software.

I repository di origine e i registri dei pacchetti sono due sistemi essenziali nella build del software pipelineMa ci sono molti strumenti in DevOps: CI/CD sistemi, strumenti per l'esecuzione di test, automazione della configurazione e del provisioning o distribuzione e rilascio. Tutti possono essere abusati per l'iniezione di codice dannoso nel software. La fuga di chiavi valide per questi strumenti porta direttamente a miseria e agonia. Immagina di far trapelare chiavi di accesso root con pieno controllo sulle tue risorse cloud pubbliche...

Le solite raccomandazioni

Non diciamo niente di nuovo qui, lo sapete tutti. Ma agite! Ricordate che i bot scansionano regolarmente tutti i dati pubblici SCM repository. Alcune raccomandazioni, senza un ordine particolare.

• Se hai responsabilità sulla gestione della sicurezza informatica, definire come devono essere gestiti i segreti nella politica di sicurezza. Ma le policy sono valide tanto quanto l'applicazione: assicurati che nella tua organizzazione siano applicate linee guida per la gestione dei segreti, inclusi non solo i team DevOps ma anche i fornitori di software, e che il piano di risposta agli incidenti della tua organizzazione contenga disposizioni per gli incidenti legati alla fuga di segreti.
• Implementare e far rispettare autenticazione a più fattori (MFA, 2FA o qualsiasi acronimo). E nessun taglio alla sicurezza: una chiave di sicurezza USB vale i pochi dollari che costa. Devi eseguire il git-push di una qualsiasi delle tue migliaia di credenziali (facile) e poi ubriacarti e lasciare le chiavi in ​​un bar con qualcosa che ti collega (le probabilità sono solo un po' più piccole, soprattutto se sei astemio).
• Utilizza un gestore di password con una password complessa e non salvata. Per la gestione dei segreti nell'uso dei sistemi Casseforti segrete. CI/CD sistemi, fornitori di cloud, SCMe altri strumenti DevOps forniscono questo servizio, ma è possibile optare per una soluzione generica Secret Vault.
• Preferire fugace token per chiavi di accesso di lunga durata. Sono più facili da revocare ed espongono una finestra più limitata al male.
• Limita il riutilizzo delle credenziali: gli aggressori riutilizzeranno le credenziali raccolte per un obiettivo in altri sistemi, un altro punto a favore dell'utilizzo di un gestore di password. I gestori di password e le casseforti segrete dovrebbero rendere il riutilizzo delle credenziali un ricordo del passato.
• Limitare e monitorare l'uso di Admin Le password. Sono abbastanza potenti da meritare un monitoraggio speciale.
• Realizzare hashing e crittografia forti. Torniamo alle chiavi USB (crittografiche), alle procedure rigorose per la trasmissione delle credenziali con partner e colleghi di lavoro, e così via.
• Utilizzare scanner dei segreti, ad esempio esegui in a pre-commit gancio per evitare perdite nei sistemi di controllo della versione, come cancello di sicurezza. Prima della cosa è importante qui. In alternativa, utilizzare scansioni post-hoc per rilevare segreti trapelati, ad esempio come controllo prima pull request si unisce. Nota: la nostra piattaforma Xygeni include uno scanner di segreti che consente entrambe le modalità di funzionamento. 
• L'alternativa manuale all'utilizzo revisioni del codice cercare segreti hardcoded ha costi più elevati e funziona a posterioricommit (ma si spera almeno prima che il segreto sia disponibile agli estranei). Ma le revisioni potrebbero rilevare segreti non convenzionali che potrebbero eludere gli scanner dei segreti.       
• Evitare accidentalmente committing file comuni con segreti per il controllo della versione con appropriato escludere modelli (come il modello `gitignore`), tenendo conto di file come .env, .npmrc, .pypirc, file temporanei... Davvero un ulteriore livello di sicurezza.
• E l'ultimo di questa lunga lista: lasciare che i fornitori di servizi cloud eseguano scansioni per individuare eventuali perdite delle loro chiavi, quando disponibili. Almeno questo può ti faccio sapere quando è avvenuta la fuga di notizie, ma la sicurezza è un must per i fornitori di servizi cloud. Questo post-hoc la scansione segreta non è molto trasparente riguardo a dove e quanto spesso viene eseguita la scansione e spesso richiede una configurazione esplicita, ma certamente è l'ultima risorsa quando tutto il resto fallisce.

OH MIO DIO! Ho inviato le mie chiavi di accesso al cloud a un repository pubblico, prendi n. 2

Potrebbe succedere anche al meglio di noi. Rimboccati le maniche !

Rinnova/revoca/disattiva immediatamente il segreto trapelato! Se il conto dispone di un’AMF decente, il rischio è molto più basso. Ciò potrebbe essere più difficile, ad esempio, con le chiavi private nei siti Web (è necessario emettere un nuovo certificato per una nuova chiave privata e revocare quella esistente), ma gli strumenti moderni dispongono di un modo rapido per rinnovare le credenziali o revocare i token. 

Segui i passaggi consigliati dal fornitore quando disponibili, ad esempio AWS in questo esempio.

Identificare la causa della perdita. Sapere come è successo è essenziale per le attività di divulgazione, analisi, contenimento e acquisizione delle lezioni apprese.

Successivamente segnala la perdita alle parti interessate, spiegando le azioni che stai intraprendendo per tappare la perdita e ridurre i danni. Non c’è modo di invertire il danno fatto, ciò che è trapelato è trapelato. Sii trasparente e informa gli altri in modo che possano agire. 

Quindi inizia con il forense. finestra di esposizione è il tempo che intercorre tra la fuga di notizie e il momento in cui il segreto non era valido. Sii pronto a leggere i registri e a monitorare eventuali attività insolite con l'account interessato durante tale periodo. Rimuovi gli account e le chiavi generati utilizzando l'account interessato. Ricorda che se l'account interessato dispone di privilegi di amministratore, la correzione è molto più complessa. 

Riscrittura della cronologia (controllo della versione). è complesso. Anche gli stati totalitari ci provano inutilmente (gioco di parole). E probabilmente irrilevante: gli hacker o i bot sui repository pubblici potrebbero aver clonato i repository o aver già estratto l’oro, in particolare se la finestra di esposizione è sufficientemente ampia. 

Se sei avventuroso e vuoi vedere tu stesso quanto tempo impiegano i robot per rilevare un segreto trapelato, i fili di allarme come Gettoni delle Canarie lasciati sperimentare. Ricorda, i bot sono nella lista nera per impostazione predefinita canarytokens.org dominio…