L'atac del llibre major: drenant els moneders criptogràfics de maquinari

L'atac del llibre major: drenant els moneders criptogràfics de maquinari

Aquesta publicació analitza l'atac a Ledger com a exemple de com un spear phishing va conduir a un atac de la cadena de subministrament de programari (SSC) a l'eina de kit de connexió de programari que utilitzaven els moneders de maquinari de l'empresa, permetent a l'actor drenar diners per valor de com a mínim 600,000 dòlars. 

Aquest atac va arribar al final d'un any ple d'incidents a la cadena de subministrament. En aquesta publicació analitzem l'atac, el seu impacte, com es va gestionar i quines lliçons se'n poden extreure.

Ledger i els seus usuaris de moneders de maquinari són objectius evidents per als ciberdelinqüents. Els "washers" de moneders atacaven els usuaris de Ledger mitjançant intents de phishing als front-ends de les aplicacions de criptografia, i els delinqüents necessiten conèixer les coordenades de l'usuari per impulsar les campanyes de phishing. Ledger tenia un violació de dades abans del juliol de 2023 així com formar part de la Robatori de dades del setembre del 2020 al seu comerç electrònic Shopify, un incident amb un gran impacte. La publicació “Actualització: Esforços per protegir les vostres dades i perseguir els spammers"mostra fins a quin punt van arribar aquestes bretxes.

Ledger ha de prendre's seriosament la seguretat (és una part clau del seu negoci), amb un laboratori de recerca intern (mantenir) manipulació certificació de seguretat del dispositiu, un recompensa d'errors programa, butlletins de seguretati modelització d'amenacesFins ara tot bé…

Com es va fer l'atac

Ledger va detectar una vulnerabilitat utilitzant Ledger's Kit de connexió DApp el dijous 14 de desembre de 2023. Aquest exploit injectava codi maliciós dins d'aplicacions descentralitzades (DApps) basades en Ethereum que utilitzaven el Ledger Connect Kit, enganyant els usuaris perquè signessin transaccions que buidaven les seves carteres. 

L'explotació es va detectar ràpidament i es va implementar una solució poc després. Mentrestant, un baix volum d'usuaris van caure en l'atac i van signar transaccions que van buidar la seva cartera.

L'atac va començar quan un antic empleat de Ledger va ser víctima d'un atac de phishing que va obtenir accés al seu compte NPM a través del token de sessió. Els atacants van publicar versions malicioses del  @ledgerhq/connect-kit (1.1.5, 1.1.6 i 1.1.7, ara retirades). Els atacants podien executar codi arbitrari amb el mateix nivell de permisos que l'aplicació de moneder: els atacants poden drenar immediatament els fons dels usuaris sense interacció, distribuir nombrosos enllaços de phishing per enganyar els usuaris o explotar el pànic dels usuaris convencent-los que transfereixin actius a una nova adreça, cosa que provocaria la pèrdua d'actius a causa de la descàrrega d'un moneder fals.

Els front-ends de cartera (dApps) normalment utilitzaven el carregador de kits de connexió paquet de Ledger per carregar el Connect Kit en temps d'execució des d'una CDN de JavaScript (jsDelivr). Malauradament, l'URL https://cdn.jsdelivr.net/npm/@ledgerhq/connect-kit@1 no estava fixant la versió exacta (1.1.4 en aquell moment), de manera que quan es carregaven les versions malicioses, la CDN les servia (i les emmagatzemava a la memòria cau). I no es feia servir cap suma de verificació per garantir que el recurs descarregat de la CDN fos realment l'esperat (que s'hauria d'utilitzar en distribuir codi des d'una CDN). Aquest esquema basat en la suma de verificació s'anomena Integritat dels subrecursos (SRI).

El codi injectat probablement va manipular dades de transaccions, enganyant els usuaris perquè confirméssin pagaments manipulats. Per exemple, un usuari que aprova un pagament simbòlic per habilitar la funcionalitat d'una aplicació pot haver vist en canvi una aprovació per a un pagament a l'adreça del pirata informàtic. Independentment de la seguretat del moneder de maquinari, els diners es van esgotar. 

Descobriment i Investigació

Diferents usuaris van començar a publicar missatges a X (també conegut com a Twitter) dient que el front-end de Zapper "havia estat segrestat". El mèrit és de Mathew Lilley, el CTO del criptooperador Sushi, que va ser el primer a advertir en un Twitter pal que un "connector web3 d'ús comú" s'havia compromès. Més tard va assenyalar LedgerHQ/kit de connexió com la biblioteca compromesa, i va fer una primera avaluació, una mica bruscament:

L'usuari 0xViva ha obert un tiquet al repositori del projecte GitHub: [URGENT] Aquest repositori utilitza una versió maliciosa del paquet npm @ledgerhq/connect-kit, 1.1.7.

El 15 de desembre de 2023, el formulari de seguretat de blockchain SlowMost va publicar un publicació d'anàlisi donant tots els detalls de les versions malicioses. 

El moneder de maquinari Ledger no es va veure compromès, només el kit Ledger Connect. Tanmateix, com que moltes aplicacions utilitzen aquesta biblioteca, com ara SushiSwap, Zapper, MetalSwap, Harvest Finance, Revoke.cash, etc., l'abast de l'impacte va ser significatiu. Segons bittrace.io, algunes víctimes, preses del pànic, van intentar transferir actius a una nova adreça, però van descarregar una aplicació de moneder fals! 

El mateix dia, Jameson Lopp va dir amb precisió: tuiteó sobre els defectes que van permetre que l'atac tingués èxit:

Com es va gestionar l'incident

El CEO de Ledger, Pascal Gauthier, va publicar el mateix dia de l'atac. carta de divulgació donant més detalls sobre l'incident, cosa que sens dubte és bona: amagar el cap a la sorra com un estruç és la pitjor manera de gestionar qualsevol incident de ciberseguretat. 

L'estructura de la carta és interessant: va reconèixer ràpidament l'existència de versions malicioses de la biblioteca que drenen diners, cosa que és bona (negar la realitat és una ximpleria):

"Avui hem experimentat una vulnerabilitat al Ledger Connect Kit, una biblioteca de Javascript que implementa un botó que permet als usuaris connectar el seu dispositiu Ledger a DApps (llocs web connectats a moneders) de tercers."

Aquesta vulnerabilitat va ser el resultat d'un antic empleat que va ser víctima d'un atac de phishing, que va permetre a un actor malintencionat carregar un fitxer maliciós a l'NPMJS de Ledger (un gestor de paquets per a codi Javascript compartit entre aplicacions).

Vam treballar ràpidament, juntament amb el nostre soci WalletConnect, per abordar l'explotació, actualitzant l'NPMJS per eliminar i desactivar el codi maliciós en un termini de 40 minuts des del descobriment. Aquest és un bon exemple de la indústria treballant conjuntament i ràpidament per abordar els reptes de seguretat. 

Què? A un antic empleat amb drets de publicació no li van revocar les credencials a NPM?

El CEO va enumerar els controls de seguretat establerts, però va insinuar que hi havia alguna cosa feble amb l'accés a NPM:

"Ara, m'agradaria abordar per què va passar això, com millorarem les nostres pràctiques de seguretat per mitigar aquest risc específic en el futur i compartir la nostra recomanació amb la indústria, perquè junts puguem ser més forts."

L' standard La pràctica a Ledger és que cap persona pot implementar codi sense la revisió de diverses parts. Tenim controls d'accés forts, revisions internes i signatures múltiples de codi quan es tracta de la majoria de parts del nostre desenvolupament. Aquest és el cas en el 99% dels nostres sistemes interns. A qualsevol empleat que deixi l'empresa se li revoca l'accés a tots els sistemes de Ledger.

Aquest va ser un incident aïllat i desafortunat. És un recordatori que la seguretat no és estàtica i que Ledger ha de millorar contínuament els nostres sistemes i processos de seguretat. En aquest àmbit, Ledger implementarà controls de seguretat més forts, connectant la nostra construcció... pipeline que implementa estrictes software supply chain security al canal de distribució de NPM."

Bé, semblava que el compte NPM amb permisos per publicar noves versions de la biblioteca tenia controls de seguretat menys estrictes que altres parts de la seva infraestructura de programari. Incident aïllat degut a la mala sort?

El final de la carta és més standard secció de compromís amb les autoritats, "declaració sota control" i disculpes:

«Ledger ha col·laborat amb les autoritats i està fent tot el possible per ajudar a mesura que es desenvolupa aquesta investigació. Ledger donarà suport als usuaris afectats per ajudar a trobar aquest malfactor, portar-lo davant la justícia, rastrejar els fons i treballarà amb les forces de l'ordre per ajudar a recuperar els actius robats del pirata informàtic. Lamentem profundament els esdeveniments que han tingut lloc avui per a les persones afectades.» 

La situació ja està sota control i l'amenaça ha passat. Entenem el pànic que això ha causat a la comunitat i a l'ecosistema en general.

La carta inclou un cronograma, que és molt útil perquè els usuaris entenguin com es va descobrir l'incident, quines accions específiques de contenció i remediació es van prendre i com es recuperaran/compensaran els danys als usuaris afectats. Aquesta és la part més específica de les monedes:

"Aquest matí CET, un antic empleat de Ledger va ser víctima d'un atac de phishing que va obtenir accés al seu compte NPMJS. L'atacant va publicar una versió maliciosa del Ledger Connect Kit (que afecta les versions 1.1.5, 1.1.6 i 1.1.7). El codi maliciós utilitzava un projecte WalletConnect no autoritzat per redirigir fons a una cartera de pirates informàtics." Els equips de tecnologia i seguretat de Ledger van ser alertats i es va implementar una solució en un termini de 40 minuts després que Ledger se n'adonés. El fitxer maliciós va estar actiu durant unes 5 hores, però creiem que la finestra en què es van drenar els fons es va limitar a un període inferior a dues hores.Ledger es va coordinar amb WalletConnect, que van desactivar ràpidament el projecte fraudulent. La versió 1.1.8 del kit Ledger Connect, genuïna i verificada, ja s'està propagant i és segura d'utilitzar.

Per als creadors que desenvolupen i interactuen amb el codi del Ledger Connect Kit: l'equip de desenvolupament de connect-kit del projecte NPM ara és de només lectura i no pot enviar directament el paquet NPM per motius de seguretat. Hem rotat internament els secrets per publicar-los al GitHub de Ledger. Desenvolupadors, comproveu de nou que esteu utilitzant la darrera versió, la 1.1.8.

Ledger, juntament amb WalletConnect i els nostres socis han denunciat l'adreça del moneder del malfactor. L'adreça ara és visible a Anàlisi de la cadena. Tether ha congelat l'USDT del mal actor."

Segons això, la contenció va ser ràpida, ja que el projecte nociu WalletConnect per redirigir fons va ser desactivat immediatament. Però tot i això, algunes carteres es van esgotar.

Conseqüències: com va reaccionar la indústria

Alguns usuaris van expressar la seva indignació amb Ledger per no haver aconseguit evitar el compromís, mentre que d'altres van advertir sobre els perills de confiar en biblioteques de tercers.

La indústria de la ciberseguretat té un nínxol en les cibermonedes. Són conegudes les campanyes de drenatge de moneders, que utilitzen principalment llocs de phishing per enganyar els usuaris finals. El negoci SaaS (Scam-as-a-Service) habitual té actors especialitzats en el drenatge de moneders, com el venedor d'estafes. Escurridor infernal que va anunciar l'aturada de les operacions al novembre de 2023. Això sembla ser una falsa bandera de totes maneres, segons l'activitat recent vista a Dune @scamsnifferL'esquema que segueixen s'explicava en aquesta publicació del Grup IB:

Flux de treball d'Inferno Drainer. Font: Goodbye Inferno Drainer? (…), per Group-IB.
L'atac del llibre major: drenant els moneders criptogràfics de maquinari

Alguns analistes van donar pistes sobre què no va fer possible l'atac. Això comentari de l'usuari brianddk al tiquet del repositori del projecte ens dóna informació sobre la causa arrel: 

L'atac del llibre major: drenant els moneders criptogràfics de maquinari

A comentari d'un altre usuari, HenryQW, va assenyalar la segona cosa que feia que les versions malicioses es poguessin propagar a través de la CDN:

És massa aviat per veure iniciatives a llarg termini per fer que els front-ends de les moneders criptogràfics siguin més robustos contra els atacs de phishing. Sembla que cal complir amb un standard similar al que PA-DSS ho fa per als proveïdors de programari d'aplicacions de pagament podria ser benvingut a la indústria de les criptomonedes.

I ara, lliçons apreses!

És sorprenent com una cartera de maquinari, l'epítom de la seguretat criptogràfica, va ser violat simplement per obtenir accés a les credencials de NPM d'un "exempleat" de Ledger (probablement nom d'usuari/contrasenya sense protecció 2FA o un token d'accés). Aquest incident serveix com un recordatori sorprenent que quan esteu sota pressió, la vostra infraestructura de programari s'ha de protegir amb la mateixa cura que els vostres productes de programari o maquinari.

La majoria dels atacs a la cadena de subministrament de programari comencen comprometent un compte intern (sovint per a un desenvolupador o enginyer de DevOps). Aleshores, els atacants es mouen lateralment per violar els sistemes interns de la infraestructura de programari com ara CI/CD sistema o les eines de desplegament, o aconsegueixen afegir lògica maliciosa als repositoris de codi font, cosa que es podria detectar si s'implementa una gestió adequada dels canvis amb protecció contra branques i revisions de codi. Però els atacants no necessiten aprofundir tant quan l'objectiu és una biblioteca popular publicada en un registre públic, sobretot si poden obtenir accés a les credencials de publicació (escriptura). I això és el que va passar en aquest atac. 

Autenticació 2FA, concretament l'ús d'elements robustos com ara claus de seguretat, limita el risc amb operacions interactives. Per a CI/CD pipelines, tokens d'accés amb accés limitat emmagatzemats com a CI/CD secret és el camí habitual (i el testimoni d'accés no s'hauria de filtrar). Malauradament, sembla que l'empleat no tenia un conjunt robust de 2FA. NPM permet organitzacions per aplicar la 2FA (però això és opcional, no és el valor per defecte), que probablement és el que hauria de tenir Ledger. I no us oblideu d'afegir-hi l'opció adequada revocació de credencials procediments per a antics empleats, especialment amb accés a recursos tan crítics com l'abast de la NPM propietat de l'organització.

Fixació de versions per a dependències amb canvis de versió revisats és una pràctica que mitiga la propagació de dependències malicioses. En el context de l'incident de Ledger, les versions de la biblioteca que el carregador de kits de connexió va prendre de la CDN hauria d'haver estat fixat, i "no confieu en el que llanci la CDN". Tenir un verificació de la suma de verificació p. ex., s'hauria d'utilitzar via SRI (o fins i tot un esquema de signatura digital que també autentiqui la font) quan s'extreu d'una CDN per a la càrrega dinàmica de codi.  

La resta és una història.

Per a les campanyes de phishing més convencionals dirigides als usuaris de moneders, la pregunta és: què fa que els usuaris caiguin en trampes posades pels delinqüents i confirmin transaccions que mai van tenir la intenció de realitzar? Els llocs de phishing en aquest àmbit estan ben dissenyats i són convincents, i imiten marques de criptomonedes populars; i també ofereixen fitxes gratuïtes. encunyar NFT i altres recompenses. Evitar que els usuaris caiguin en aquestes trampes és un problema que busca una solució.

I per no oblidar el relacionat criptopirateria atacs, una amenaça més general, on els adversaris prenen el control de les infraestructures del núvol per executar miners de criptomoneda, sovint per a monedes de privadesa com Monero XMR i Zcash, amb historials de transaccions ocults. El criptojacking és rellevant perquè pot afectar QUALSEVOL organització, i tot i que el benefici per a l'atacant pot ser baix, el cost per a la víctima pot ser gran (Sysdig esmentat a aquest informe que suposa un cost de 53 dòlars per a l'organització víctima per cada dòlar extret per l'atacant).

referències

Explora les funcions de Xygeni!
Mireu la nostra demostració en vídeo
sca-tools-software-composition-analyse-tools
Prioritzar, solucionar i protegir els riscos del programari
Obtén el teu compte gratuït.
No es requereix cap targeta de crèdit.

Assegura el desenvolupament i el lliurament del teu programari

amb el paquet de productes Xygeni