Questo post analizza l'attacco a Ledger come esempio di come uno spear phising abbia portato a un attacco della catena di fornitura del software (SSC) allo strumento software connect-kit utilizzato dai portafogli hardware dell'azienda, consentendo all'attore di drenare denaro per un valore di almeno $ 600,000.
Questo attacco è avvenuto alla fine di un anno afflitto da incidenti nella catena di approvvigionamento. In questo post analizziamo l’attacco, il suo impatto, come è stato gestito e quali lezioni se ne potrebbero trarre.
Ledger e gli utenti del suo portafoglio hardware sono obiettivi ovvi per i criminali informatici. I drenatori di portafogli attaccavano gli utenti di Ledger tramite tentativi di phishing sui front-end delle app di crittografia e i criminali hanno bisogno di conoscere le coordinate dell'utente per condurre le campagne di phishing. Ledger aveva un file violazione dei dati entro luglio 2023 oltre a far parte del Furto di dati di settembre 2020 sul loro e-commerce Shopify, un incidente di grande impatto. Il post”Aggiornamento: sforzi per proteggere i dati e perseguire gli spammer" mostra quanto siano profonde queste violazioni.
Ledger deve prendere sul serio la sicurezza (è una parte fondamentale della loro attività), con un laboratorio di ricerca interno (Don Jon) gestione certificazione di sicurezza del dispositivo, una bug bounty programma, bollettini di sicurezzae modellazione delle minacce. Fin qui tutto bene …
Come è stato compiuto l'attacco
Ledger ha rilevato un exploit utilizzando Ledger Kit di connessione DApp giovedì 14 dicembre 2023. Questo exploit ha iniettato codice dannoso all'interno delle applicazioni decentralizzate (DApp) basate su Ethereum che utilizzavano Ledger Connect Kit, inducendo gli utenti a firmare transazioni che prosciugano i loro portafogli.
L'exploit è stato rapidamente individuato e subito dopo è stata implementata una soluzione. Nel frattempo, un piccolo numero di utenti è caduto nell'attacco e ha firmato transazioni prosciugando il proprio portafoglio.
L'attacco è iniziato quando un ex dipendente di Ledger è rimasto vittima di un attacco di phishing che ha ottenuto l'accesso al suo account NPM tramite il token di sessione. Gli aggressori hanno pubblicato versioni dannose del file @ledgerhq/connect-kit (1.1.5, 1.1.6 e 1.1.7, ora ritirati). Gli aggressori potrebbero eseguire codice arbitrario con lo stesso livello di autorizzazioni dell'app portafoglio: gli aggressori possono drenare immediatamente i fondi degli utenti senza interazione, distribuire numerosi collegamenti di phishing per ingannare gli utenti o sfruttare il panico degli utenti convincendoli a trasferire risorse a un nuovo indirizzo , con conseguente perdita di asset dovuta al download di un portafoglio falso.
I front-end del portafoglio (dApp) in genere utilizzavano il file connect-kit-loader pacchetto da Ledger per caricare il Connect Kit in fase di esecuzione da un CDN JavaScript (jsDelivr). Sfortunatamente, l'URL https://cdn.jsdelivr.net/npm/@ledgerhq/connect-kit@1 non fissava la versione esatta (1.1.4 all'epoca), quindi quando le versioni dannose venivano caricate, venivano servite (e memorizzate nella cache) dal CDN. Inoltre, non è stato utilizzato alcun checksum per garantire che la risorsa scaricata dalla CDN fosse effettivamente quella prevista (che dovrebbe essere utilizzata durante la distribuzione del codice da una CDN). Questo schema basato sul checksum prende il nome Integrità delle sottorisorse (SR).
Il codice inserito probabilmente ha manipolato i dati delle transazioni, inducendo gli utenti a confermare pagamenti manipolati. Ad esempio, un utente che approva un pagamento tramite token per abilitare la funzionalità di un'app potrebbe invece aver visto un'approvazione per un pagamento all'indirizzo dell'hacker. Non importa quanto fosse sicuro il portafoglio hardware, i soldi venivano prosciugati.
Scoperta e investigazione
Diversi utenti hanno iniziato a postare messaggi su X (noto anche come Twitter) dicendo che il front-end di Zapper “è stato dirottato”. Il merito va a Mathew Lilley, il CTO del cryptotrader Sushi, che per primo ha messo in guardia in a Post di Twitter che un "connettore web3 comunemente utilizzato" è stato compromesso. Più tardi indicò LedgerHQ/kit di connessione come libreria compromessa, e ha dato una prima valutazione, un po' brusca:
Che cosa è successo?
— Io sono Software 🦇🔊 (@MatthewLilley) Dicembre 14, 2023
In breve, @Libro ha commesso una catena di terribili errori.
1. Stanno caricando JS da un CDN.
2. Non sono JS caricati con blocco della versione.
3. Il loro CDN è stato compromesso.
Eviterei di utilizzare QUALSIASI dApp finché i loro team non confermeranno di aver mitigato l'attacco. https://t.co/a3brXNQSx9
L'utente 0xViva ha aperto un ticket nel repository del progetto GitHub: [URGENTE] Questo repository utilizza una versione dannosa del pacchetto npm @ledgerhq/connect-kit, 1.1.7.
Il 15 dicembre 2023 il modulo di sicurezza blockchain SlowMost ha pubblicato un postazione di analisi fornendo dettagli completi delle versioni dannose.
Il portafoglio hardware Ledger non è stato compromesso, solo il Ledger Connect Kit. Tuttavia, poiché molte applicazioni utilizzano quella libreria, come SushiSwap, Zapper, MetalSwap, Harvest Finance, Revoke.cash, ecc., la portata dell’impatto è stata significativa. Secondo bittrace.io, alcune vittime, in preda al panico, hanno provato a trasferire beni a un nuovo indirizzo, ma hanno scaricato un'app di portafoglio falsa!
Lo stesso giorno, Jameson Lopp con precisione tweeted sui difetti che hanno permesso all'attacco di riuscire:
Sembra che l'incidente di sicurezza di oggi sia stato il culmine di 3 diversi fallimenti di Ledger:
- Jameson Lopp (@lopp) Dicembre 14, 2023
1. Caricamento cieco del codice senza bloccare una versione e un checksum specifici.
2. Non applicare le "regole di 2 persone" in merito alla revisione e alla distribuzione del codice.
3. Non revocare l'accesso degli ex dipendenti.
Come è stato gestito l'incidente
Il CEO di Ledger, Pascal Gauthier, ha pubblicato lo stesso giorno dell'attacco a lettera informativa fornendo ulteriori dettagli sull'incidente, il che è decisamente positivo: nascondere la testa sotto la sabbia come uno struzzo è il modo peggiore per gestire qualsiasi incidente di sicurezza informatica.
La struttura della lettera è interessante: riconosce subito l'esistenza di versioni dannose della biblioteca che drenano denaro, il che è positivo (negare la realtà è una sciocchezza):
“Oggi abbiamo riscontrato un exploit sul Ledger Connect Kit, una libreria Javascript che implementa un pulsante che consente agli utenti di connettere il proprio dispositivo Ledger a DApp di terze parti (siti Web connessi a portafoglio).
Questo exploit è stato il risultato di un ex dipendente vittima di un attacco di phishing, che ha consentito a un malintenzionato di caricare un file dannoso su NPMJS di Ledger (un gestore di pacchetti per codice Javascript condiviso tra app).
Abbiamo lavorato rapidamente, insieme al nostro partner WalletConnect, per affrontare l'exploit, aggiornando NPMJS per rimuovere e disattivare il codice dannoso entro 40 minuti dalla scoperta. Questo è un buon esempio di come il settore stia lavorando rapidamente insieme per affrontare le sfide legate alla sicurezza”.
Che cosa? Ad un ex dipendente con diritti di pubblicazione non sono state revocate le credenziali su NPM?
Il CEO ha poi enumerato i controlli di sicurezza in atto, suggerendo però che c'era qualcosa di debole nell'accesso a NPM:
“Ora, vorrei spiegare perché ciò è accaduto, come miglioreremo le nostre pratiche di sicurezza per mitigare questo rischio specifico in futuro e condividere le nostre raccomandazioni al settore, in modo da poter essere più forti insieme.
. standard la prassi di Ledger è che nessuna persona può distribuire codice senza la revisione di più parti. Abbiamo forti controlli di accesso, revisioni interne e firme multiple di codice quando si tratta della maggior parte delle parti del nostro sviluppo. Questo è il caso del 99% dei nostri sistemi interni. A qualsiasi dipendente che lascia l'azienda viene revocato l'accesso da ogni sistema Ledger.
Si è trattato di uno sfortunato incidente isolato. Ci ricorda che la sicurezza non è statica e che Ledger deve migliorare continuamente i nostri sistemi e processi di sicurezza. In quest'area, Ledger implementerà controlli di sicurezza più forti, collegando la nostra build pipeline che implementa rigoroso software supply chain security al canale distributivo NPM."
Ebbene, sembrava che l'account NPM con le autorizzazioni per pubblicare nuove versioni della libreria avesse controlli di sicurezza meno rigorosi rispetto ad altre parti della loro infrastruttura software. Incidente isolato dovuto alla sfortuna?
La fine della lettera è più standard sezione di impegno con le autorità, “dichiarazione sotto controllo” e scuse:
“Ledger ha collaborato con le autorità e sta facendo tutto il possibile per aiutare nello svolgimento di questa indagine. Ledger supporterà gli utenti interessati nell'aiutarli a trovare questo cattivo attore, assicurarli alla giustizia, tenere traccia dei fondi e collaborare con le forze dell'ordine per aiutare a recuperare i beni rubati dall'hacker. Ci rammarichiamo profondamente degli eventi accaduti oggi per le persone colpite.
La situazione ora è sotto controllo e la minaccia è passata. Comprendiamo il panico che ciò ha causato alla comunità e all’ecosistema più ampio”.
La lettera allega una cronologia, che è molto utile per gli utenti per capire come è stato scoperto l'incidente, quali azioni specifiche di contenimento e riparazione sono state intraprese e come verrà recuperato/compensato il danno subito dagli utenti interessati. Questa è la parte più specifica della moneta:
“Questa mattina CET, un ex dipendente di Ledger è rimasto vittima di un attacco di phishing che ha ottenuto l'accesso al suo account NPMJS. L'aggressore ha pubblicato una versione dannosa del Ledger Connect Kit (che interessa le versioni 1.1.5, 1.1.6 e 1.1.7). Il codice dannoso utilizzava un progetto non autorizzato WalletConnect per reindirizzare i fondi al portafoglio di un hacker. I team addetti alla tecnologia e alla sicurezza di Ledger sono stati allertati e una soluzione è stata implementata entro 40 minuti dal momento in cui Ledger ne è venuto a conoscenza. Il file dannoso è rimasto attivo per circa 5 ore, tuttavia riteniamo che il periodo in cui sono stati drenati i fondi sia stato limitato a un periodo inferiore a due ore. Ledger si è coordinato con WalletConnect che ha rapidamente disabilitato il progetto canaglia. La versione 1.1.8 del Ledger Connect Kit autentica e verificata si sta ora diffondendo ed è sicura da usare.
Per i builder che stanno sviluppando e interagendo con il codice Ledger Connect Kit: il team di sviluppo connect-kit sul progetto NPM è ora di sola lettura e non può inviare direttamente il pacchetto NPM per motivi di sicurezza. Abbiamo ruotato internamente i segreti da pubblicare su GitHub di Ledger. Sviluppatori, verificate nuovamente di utilizzare la versione più recente, la 1.1.8.
Registro, insieme a Portafoglio Connect e i nostri partner hanno segnalato l'indirizzo del portafoglio del malintenzionato. L'indirizzo è ora visibile su Chainalysis. Tether ha congelato l'USDT del cattivo attore."
In base a ciò, il contenimento è stato rapido poiché il progetto canaglia WalletConnect per il reindirizzamento dei fondi è stato prontamente disattivato. Ma anche così alcuni portafogli furono prosciugati.
Conseguenze: come ha reagito l’industria
Alcuni utenti hanno espresso rabbia nei confronti di Ledger per non essere riuscito a prevenire la compromissione, mentre altri hanno messo in guardia contro i pericoli derivanti dall'affidarsi a librerie di terze parti.
Il settore della sicurezza informatica ha una nicchia nel cybercoin. Sono note le campagne di drenaggio del portafoglio che utilizzano principalmente siti di phishing per ingannare gli utenti finali. Il solito business SaaS (Scam-as-a-Service) ha attori specializzati per il drenaggio del portafoglio, come il venditore di truffe Scolapiatti Infernale quale annunciato lo stop delle attività nel novembre 2023. Questo sembra comunque essere un false flag, secondo la recente attività vista su Dune @scamsniffer. Lo schema che seguono è stato spiegato da questo post di Group-IB:
Alcuni analisti hanno fornito indicazioni su ciò che non ha reso possibile l’attacco. Questo commento dell'utente brianddk nel ticket sul repository del progetto ci fornisce informazioni sulla causa principale:
A commento di un altro utente, HenryQW, ha sottolineato il secondo fattore che ha reso le versioni dannose in grado di propagarsi tramite CDN:
È troppo presto per vedere iniziative a lungo termine per rendere i front-end dei portafogli crittografici più resistenti agli attacchi di phishing. Sembra che sia necessario rispettare un standard simile a quello che PA-DSS ciò che fa per i fornitori di software di applicazioni di pagamento potrebbe essere accolto con favore nel settore delle criptovalute.
E ora, lezioni apprese!
È sorprendente come un portafoglio hardware, l'emblema della sicurezza crittografica, è stato violato semplicemente concedendo l’accesso alle credenziali NPM di un “ex dipendente” di Ledger (probabilmente nome utente/password senza protezione 2FA o token di accesso). Questo incidente serve a ricordarci in modo sorprendente che quando sei sotto attacco, la tua infrastruttura software deve essere protetta con la stessa cura dei tuoi prodotti software o hardware.
La maggior parte degli attacchi alla supply chain del software inizia compromettendo un account interno (spesso per uno sviluppatore o un ingegnere DevOps). Gli aggressori si muovono quindi lateralmente per violare i sistemi interni nell'infrastruttura software come CI/CD sistema o gli strumenti di distribuzione, o riescono ad aggiungere logica dannosa ai repository del codice sorgente, che potrebbe essere rilevata se è in atto una corretta gestione delle modifiche con protezione dei rami e revisioni del codice. Ma gli aggressori non hanno bisogno di andare così in profondità quando l'obiettivo è una libreria popolare pubblicata in un registro pubblico, soprattutto se possono ottenere l'accesso per pubblicare (scrivere) le credenziali. Ed è quello che è successo in questo attacco.
Autenticazione 2FA, utilizzando in particolare elementi robusti come le chiavi di sicurezza, limita il rischio con operazioni interattive. Per CI/CD pipelines, token di accesso con accesso limitato memorizzati come CI/CD secret è il modo usuale di procedere (e il token di accesso non dovrebbe essere divulgato). Sfortunatamente, sembra che il dipendente non avesse un set 2FA robusto. NPM consente organizzazioni per applicare la 2FA (ma questo è facoltativo, non predefinito), che è probabilmente ciò che dovrebbe avere Ledger. E non dimenticare di aggiungere appropriato revoca delle credenziali procedure per gli ex dipendenti, in particolare con accesso a risorse critiche come l'ambito NPM di proprietà dell'organizzazione.
Blocco della versione per le dipendenze con versioni modificate è una pratica che mitiga la diffusione di dipendenze dannose. Nel contesto dell'incidente di Ledger, le versioni della libreria che il file connect-kit-loader preso dalla CDN avrebbe dovuto essere bloccato e "non fidarti di ciò che lancia la CDN". Avere un verifica del checksum ad esempio, tramite SRI (o anche uno schema di firma digitale che autentica anche la fonte) dovrebbe essere utilizzato quando si estrae da un CDN per il caricamento dinamico del codice.
Il resto è una storia.
Per le campagne di phishing più convenzionali dirette agli utenti di portafogli, la domanda è: cosa spinge gli utenti a cadere nelle trappole tese dai criminali e a confermare transazioni che non avevano mai avuto intenzione di eseguire? I siti di phishing in questo dominio sono ben progettati e convincenti e imitano i famosi marchi di criptovalute; e offrono anche gettoni gratuiti, coniare NFT e altri premi. Evitare che gli utenti cadano in tali trappole è un problema alla ricerca di una soluzione.
E per non dimenticare il relativo criptohacking attacchi, una minaccia più generale, in cui gli avversari prendono il controllo delle infrastrutture cloud per gestire minatori di criptovaluta, spesso per monete private come Monero XMR e Zcash, con cronologie di transazioni nascoste. Il cryptojacking è rilevante perché può colpire QUALSIASI organizzazione e, sebbene il profitto per l'aggressore possa essere basso, il costo per la vittima potrebbe essere elevato (Sysdig menzionato in questa relazione che ci vogliono 53 dollari di costo per l'organizzazione vittima per ogni dollaro estratto per l'aggressore).
Referenze
- Biglietto “[URGENTE] Questo repository utilizza una versione dannosa del pacchetto npm @ledgerhq/connect-kit, 1.1.7"nel repository Github.
- Lettera del CEO di Ledger sull'incidente, 14 dicembre 2023.
- Rapporto sugli incidenti di sicurezza, di Ledger, 20 dic 2023.
- L’exploit dei registri mette in pericolo la DeFi; Sushi dice "Non interagire con NESSUNa dApp", postare CoinDesk di Oliver Knight, 14 dicembre 2023.
- Kit di attacco della catena di fornitura al registro di connessione: analisi dell'impatto e misure preventive. Post di SlowMist sull'attacco, dicembre 2023.
- Concetti di sicurezza Web3: svuotaportafogli, di Jammel Weaver, in Rektify AI, luglio 2023.
Guarda la nostra demo video
