Atac asupra Trust Wallet: o extensie Chrome troianizată a sustras 8, 5 milioane dolari din peste 2.500 de portofele

Atunci când un portofel digital folosit de peste 200 de milioane de persoane este compromis, efectele se văd rapid în ecosistemul cripto: Trust Wallet a raportat că o breșă în extensia sa de browser a dus la sustragerea a aproximativ 8, 5 milioane de dolari din peste 2.500 de portofele, printr‑o versiune troianizată a extensiei publicată în Chrome Web Store pe 24 decembrie. Ca și în cazul unor incidente celebre de tip supply chain, de la SolarWinds la atacurile asupra registrului npm, acest caz ilustrează cât de fragile pot fi lanțurile software atunci când se compromit secretele dezvoltatorilor.

Trust Wallet, recunoscut pentru facilitarea stocării, trimiterii și recepționării de Bitcoin, Ethereum, Solana și mii de tokenuri, oferă atât aplicații mobile gratuite, cât și o extensie pentru browser. Compania a precizat că atacatorii au introdus un fișier JavaScript malițios în versiunea 2.68.0 a extensiei Chrome; acel cod a colectat informații sensibile din portofele și a permis efectuarea de tranzacții neautorizate. Mai grav, secrete din conturile dezvoltatorilor de pe GitHub au fost divulgate, oferind atacatorilor acces la codul sursă al extensiei și, mai crucial, la cheia API a Chrome Web Store.

Cu cheia API compromisă, atacatorii au avut acces total la API‑ul Chrome Web Store și au putut încărca builduri direct, evitând fluxul intern normal de aprobare manuală. Ulterior, actorii rău intenționați au înregistrat domeniile metrics-trustwallet.com și api.metrics-trustwallet.com pentru a găzdui codul malițios, la care făcea referire versiunea troianizată a extensiei. Spre deosebire de o injecție tipică, atacatorii au construit o ediție modificată pornind de la codul obținut din secretele GitHub, ceea ce le‑a permis să extragă date ale portofelelor fără urme de injecție directă.

Ca răspuns, Trust Wallet a revocat toate API‑urile de release pentru a opri publicarea unor versiuni compromise. Firma a raportat domeniile malițioase registrarului NiceNIC, care le‑a suspendat rapid, și a demarat procesul de compensare a utilizatorilor afectați. De asemenea, Trust Wallet a avertizat comunitatea că atacatorii se prezintă acum drept conturi de suport, trimițând formulare false de despăgubire și folosind reclame pe Telegram pentru escrocherii; recomandarea clară este să se manifeste prudență față de orice comunicare care solicită chei private sau informații sensibile.

Incidentul se leagă de campania Sha1-Hulud, un atac de tip supply chain care a vizat registrul npm, ce găzduiește peste 2 milioane de pachete. Prima etapă, la începutul lunii septembrie, a compromis peste 180 de pachete npm folosind un payload auto‑propagant și a folosit instrumente precum TruffleHog pentru a extrage secrete de dezvoltatori și chei API. O versiune ulterioară, denumită Shai-Hulud 2.0, a agravat situația, afectând peste 800 de pachete și adăugând în jur de 27.000 de pachete malițioase care colectau secrete din mediile de dezvoltare și CI/CD și le publicau pe GitHub. În ansamblu, campania a expus aproximativ 400.000 de secrete brute și a publicat date în peste 30.000 de depozite GitHub, iar la 1 decembrie peste 60% din tokenurile npm compromise erau încă valabile. Cercetătorii de la Wiz au atras atenția că atacatorii își perfecționează metodele de colectare a credențialelor prin ecosistemul npm și GitHub, semnalând riscul unor atacuri similare în viitor.

Versiunea 2.68 a extensiei Chrome a Trust Wallet a fost distribuită folosind o cheie API compromisă. Cazul reia în discuție importanța rotirii cheilor, a aplicării principiului least privilege și a implementării unor controale stricte asupra secretelor de dezvoltare: lecții confirmate atât de incidentele asupra npm, cât și de precedente supply chain precum SolarWinds. Implementarea unor scanări automate ale depozitelor, restricționarea accesului API și monitorizarea activității post‑release sunt măsuri concrete care reduc expunerea, fără a necesita investiții tehnologice imposibile. Tu ce crezi: care ar fi primul pas realist pe care echipele de dezvoltare l‑ar putea face pentru a proteja secretele din proiectele lor?

Fii primul care comentează

Lasă un răspuns

Adresa ta de email nu va fi publicată.


*