L’incidente Binance da 6,3 miliardi di dollari: cosa è successo e come ridurre il rischio

Le conclusioni preliminari di Binance descrivono compromissioni di computer dei dipendenti a giugno e settembre, seguite il 20 ottobre da un’intrusione più ampia attraverso strumenti interni di IA. Gli attaccanti hanno raggiunto i computer di due colleghi e trovato un token per distribuire container. Il 29 ottobre lo hanno usato per distribuire codice malevolo che ha raggiunto i sistemi di firma dei wallet e avviato trasferimenti non autorizzati.

Gli attaccanti hanno usato il servizio di firma anche per creare una delega EIP-7702, ossia un’autorizzazione che consente a codice sotto il loro controllo di agire per conto di un wallet Ethereum. Questo permesso esisteva sulla blockchain, indipendentemente dai sistemi di prelievo di Binance. Sospendere i prelievi non poteva eliminarlo. Binance doveva revocarlo separatamente sulla blockchain.

La distinzione importante è tra fermare un’attività e rimuovere l’autorità che la rende possibile. Sostituire un dispositivo, revocare una credenziale di deployment e annullare un permesso in un altro sistema affrontano parti diverse dell’intrusione.

Un portatile, un sistema di deployment e un servizio sensibile svolgono funzioni diverse. Il rischio cresce quando l’accesso a uno apre automaticamente quello successivo. Un token rubato può consentire a un attaccante di sostituire del software. Quel software può poi agire con permessi che il dipendente non ha mai avuto direttamente.

Quattro domande aiutano a individuare dove interrompere questa progressione:

1. Esposizione delle credenziali. Quale accesso alla produzione può ottenere un attaccante dal dispositivo di un dipendente?
2. Privilegi di deployment. Chi può modificare il codice eseguito con quell’accesso?
3. Autorizzazione del servizio. Quali azioni accetterà un servizio sensibile da quel codice?
4. Accesso persistente. Quali nuovi permessi potrebbero rimanere dopo la disattivazione dell’account originale?

L’obiettivo è limitare il passaggio di autorità tra i sistemi e identificare e revocare qualsiasi accesso aggiuntivo creato durante un’intrusione. Le sezioni seguenti esaminano quattro controlli che contribuiscono a questo obiettivo.

Controllo 1. Ridurre le credenziali che un portatile può esporre

Una credenziale è utile a un attaccante perché un altro sistema la accetta come prova di autorità. Conservare meno credenziali di produzione sui dispositivi dei dipendenti riduce ciò che può essere rubato quando uno strumento, un repository o una sessione del browser viene compromesso.

Per il lavoro ordinario, un dipendente ha spesso bisogno del permesso di richiedere un’operazione, come il riavvio di un servizio. La credenziale che la esegue può rimanere associata a un’identità di esecuzione separata. Ridurre l’esposizione significa quindi sia eliminare le copie inutili sia gestire le credenziali rimanenti:

• Sostituire, quando possibile, l’accesso diretto ordinario con operazioni definite in modo preciso.
• Usare identità separate per compiti diversi e limitarne ambito e durata.
• Mantenere un inventario delle credenziali, dei loro responsabili e delle modalità di revoca.

Questo applica il principio delle linee guida OWASP sulla gestione dei segreti: ridurre la gestione manuale dei segreti e concedere solo l’accesso necessario a ciascuna identità. Una postazione compromessa espone così meno credenziali riutilizzabili e chi risponde all’incidente sa chi gestisce quelle ancora da revocare.

Controllo 2. Trattare i diritti di deployment come privilegi di produzione

Un segreto può essere nascosto a una persona ma disponibile al codice che distribuisce. Chi può modificare quel codice potrebbe leggere il segreto, chiamare un’API interna o agire come account di servizio dell’applicazione. L’accesso al deployment va quindi valutato in base ai permessi del carico di lavoro risultante.

Le linee guida OWASP sulla sicurezza CI/CD considerano modifiche al repository, configurazione delle pipeline e host di esecuzione come parti dello stesso problema di sicurezza. La protezione deve coprire il codice prima del deployment e i suoi permessi dopo:

• Richiedere una revisione del codice di produzione e proteggere il branch del repository eseguito dall’automazione.
• Controllare le modifiche alle definizioni delle attività, alle dipendenze e agli input di avvio, oltre che allo script principale.
• Concedere ai carichi di lavoro solo le credenziali e l’accesso di rete necessari alla loro funzione.

Due insiemi di controlli devono operare insieme. I permessi sul repository e sul deployment determinano chi può modificare il codice. Politiche separate per identità, host e rete limitano ciò che quel codice può fare durante l’esecuzione. L’archiviazione centralizzata dei segreti riduce l’esposizione, mentre queste politiche vincolano il programma che usa il segreto.

Controllo 3. Autorizzare l’operazione, non solo il chiamante

Un servizio di firma può mantenere nascosta la chiave privata e accettare comunque una richiesta di firma dannosa. La stessa distinzione vale per un database o un’API cloud: autenticare un carico di lavoro identifica il chiamante, mentre l’autorizzazione decide cosa può fare.

OWASP raccomanda di verificare l’autorizzazione a ogni richiesta e di negare l’accesso se non è esplicitamente consentito. Nel servizio ricevente significa verificare sia l’azione sia il suo obiettivo: destinatari e importi di pagamento consentiti, operazioni sul database o modifiche all’infrastruttura.

Il risultato dovrebbe essere un servizio che valuta l’azione richiesta anche quando il chiamante è già considerato attendibile. L’automazione regola come viene richiesto il lavoro. Il servizio ricevente regola quali operazioni accettare.

Controllo 4. Revocare gli accessi creati durante l’intrusione

Un attaccante può usare un’identità legittima per aggiungere un’altra credenziale o concedere ulteriori permessi. MITRE ATT&CK documenta la manipolazione degli account come un modo per mantenere o ampliare l’accesso, anche aggiungendo credenziali cloud e chiavi SSH. Disattivare la sessione originale non elimina necessariamente queste modifiche.

La delega sulla blockchain di Binance mostra perché chi risponde all’incidente deve esaminare i permessi nel sistema interessato stesso. Il contenimento deve coprire sia il punto di accesso iniziale sia l’autorità creata attraverso di esso:

• Limitare quali identità di automazione possono creare altre credenziali o concedere permessi.
• Includere account, sessioni e deleghe appena creati nel piano di risposta.
• Verificare la revoca nel sistema che applica il permesso, invece di considerare un’attività interrotta come prova del contenimento.

Seguire questi passaggi fornisce al team di risposta un insieme definito di identità e permessi da esaminare e revocare. Rende anche verificabile il contenimento: il team può controllare che ogni percorso noto verso il servizio interessato sia stato effettivamente chiuso.

Questi controlli operano su livelli diversi: il dispositivo del dipendente, il sistema di deployment, il servizio ricevente e il processo di risposta. Ognuno richiede un responsabile e un modo per verificare che le restrizioni reggano quando un altro livello viene compromesso.

Le piattaforme di gestione dell’automazione affrontano la parte del problema tra la richiesta di un dipendente e l’esecuzione in produzione. In Semaphore UI, un team può preparare un’attività definita, controllare chi può eseguirla o modificarla ed eseguirla con un’identità separata. L’autorizzazione all’interno del servizio di destinazione e la revoca dei permessi creati altrove rimangono responsabilità di quei sistemi e del team di risposta.

Consideriamo un ingegnere reperibile che deve riavviare un servizio API. Un responsabile della manutenzione prepara un playbook e un Task Template che fissano gli host di destinazione e le modalità del riavvio. L’ingegnere avvia l’attività e legge il risultato senza aprire una sessione SSH in produzione. I due percorsi seguenti eseguono lo stesso riavvio, ma affidano la credenziale di esecuzione a soggetti diversi.

Creare il flusso di riavvio richiede quattro passaggi collegati: creare un’identità di esecuzione limitata, definire cosa gli utenti possono eseguire o modificare, scegliere l’ambiente di esecuzione e rendere visibile il risultato. Una volta completati, lo stesso approccio può essere esteso ai deployment.

Una sessione operatore rubata può ancora richiedere le operazioni che quell’account è autorizzato a eseguire. Anche un riavvio consentito può interrompere un servizio se viene attivato ripetutamente. Provare il flusso configurato in staging con un account operatore realistico, verificando sia ciò che può fare sia come il team risponderebbe a un abuso:

• Permessi su attività e input. Provare i ruoli reali e le opzioni di avvio, inclusi branch, inventari e argomenti alternativi.
• Accesso oltre l’operazione prevista. Verificare l’accesso ad altri modelli, credenziali e sistemi di produzione, incluso ciò che il processo del runner può raggiungere.
• Rilevamento e impatto operativo. Confermare chi riceve i risultati, chi indaga sulle attività inattese e se esecuzioni ripetute possono causare interruzioni inaccettabili.
• Revoca. Provare la revoca di sessioni e token e identificare i permessi che l’identità di esecuzione potrebbe creare altrove.

Documentare l’accesso conservato dall’account di prova e chiudere ogni percorso che superi lo scopo dell’operazione. Al termine dell’esercizio, il team dovrebbe sapere sia cosa potrebbe fare una sessione rubata sia come rilevare e contenere quell’abuso.

I controlli di accesso operano insieme alla protezione degli endpoint e a un team che sa come rispondere. Rendere il flusso preparato abbastanza pratico da poterlo usare senza ricorrere a chiavi condivise e scorciatoie non documentate. Sostenerlo con alcune pratiche quotidiane:

• Eseguire installer sconosciuti ed esercizi di colloquio in ambienti isolati e usa e getta, senza credenziali aziendali, mount dell’host o accesso alle reti interne.
• Rendere facile segnalare tempestivamente attività sospette senza attribuire colpe. Fornire un contatto chiaro e una procedura di risposta agli incidenti.
• Rivedere gli accessi quando cambiano le mansioni, mantenere una procedura controllata per l’accesso di emergenza ed esercitarsi nella revoca prima di un incidente.

Queste pratiche collegano prevenzione, rilevamento e ripristino al lavoro quotidiano. Aiutano a mantenere il modello di accesso coerente con i cambiamenti di responsabilità e offrono al team una risposta familiare quando si verifica un evento sospetto.

La lezione centrale è limitare quanta autorità possa accumulare un’identità compromessa. Meno credenziali sui portatili, automazione revisionata, host di esecuzione limitati e autorizzazione nei servizi di produzione riducono ciascuno i percorsi che un attaccante può seguire.

Semaphore integra diversi di questi controlli in un flusso ripetibile: attività preparate, permessi separati di esecuzione e modifica, credenziali fornite centralmente e registri di esecuzione visibili. Gli operatori ottengono le azioni necessarie al loro lavoro, mentre i responsabili della manutenzione mantengono il controllo su codice e credenziali sottostanti.

Iniziare da un’operazione di produzione usata spesso: preparare il relativo modello di attività, assegnare i permessi operatore necessari e provare l’accesso risultante prima di dismettere la connessione diretta che sostituisce. La misura utile del progresso è quanto poco un attaccante possa fare con il prossimo account che comprometterà.