Bybit-aanval: $1,5 miljard gestolen via kwaadaardige JavaScript

Kort samengevat: tijdlijn van de UI-injectie in Bybit's Safe Wallet

• De signing-UI faalde: Multisig faalde niet bij Bybit. De signing-UI faalde. Aanvallers herschreven wat de ondertekenaar in de browser zag, waardoor vijf goedkeurders een delegatecall naar aanvallerscode goedkeurden zonder het te weten.
• Een jaar scriptgeschiedenis: Het kwaadaardige script vuurde alleen voor een vooraf gedefinieerde lijst ondertekenaars en verplaatste $1,5 miljard nadat de delegatecall de master copy had verwisseld. cside bewaart elk third-party script tot een jaar lang, zodat je achteraf precies de geïnjecteerde build kunt zien.
• Monitor treasury-JavaScript: Als je treasury-interface third-party JavaScript laadt, monitor die dan vandaag nog op runtime. Doet ze dat niet, ga er dan alsnog van uit dat de leverancier van de wallet-UI dat wel doet, want dat gold ook voor Safe.

Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.

Op 21 februari 2025 was de cryptowereld getuige van een van de grootste crypto-diefstallen tot nu toe. Hackers stalen $1,5 miljard van Bybit, een grote cryptobeurs. Ze maakten gebruik van social engineering, wat aantoont dat beveiliging als geheel verder gaat dan wachtwoorden en firewalls.

Onderzoeken door beveiligingsbedrijven en een officiële FBI Public Service Announcement stellen dat deze hack gelinkt is aan de Lazarus Group, een Noord-Koreaanse cybercriminele organisatie die bekendstaat om het stelen van grote geldbedragen om de activiteiten van hun land te financieren (bijv. de roof bij de Bangladesh Bank). De FBI noemt deze specifieke Noord-Koreaanse operatie "TraderTraitor."

Wat er gebeurde

Bybit gebruikt een multisignature wallet om zijn fondsen te beschermen. Een multisig-wallet is een kluis die meerdere sleutels van verschillende medewerkers nodig heeft om te openen. Geen enkele persoon kan het geld en de munten alleen verplaatsen.

De hackers kregen echter geen directe toegang tot de kluis. In plaats daarvan pasten ze de gebruikersinterface (de front end) aan die medewerkers gebruiken om transacties goed te keuren, waardoor ze de sleutelhouders misleidden om nep-transacties te ondertekenen zonder dat ze het doorhadden.

Hoe het gebeurde

1) Front-end (client-side) aanval

De aanvallers injecteerden kwaadaardige JavaScript in de website-interface waar Bybit-medewerkers normaal gesproken transacties goedkeuren. Deze kwaadaardige code was zo verborgen dat alles er op het scherm normaal uitzag, maar achter de schermen werden belangrijke details gewijzigd.

De meeste bedrijven richten zich uitsluitend op back-endbeveiliging of hardware wallets. Maar als de front end gecompromitteerd is, kan die transacties stilletjes wijzigen voordat een gebruiker ook maar op "Goedkeuren" klikt. Daarom hebben we cside gebouwd: om websites in staat te stellen dependencies in de browser van hun gebruikers te monitoren en aanvallen zoals deze te voorkomen.

De hackers gebruikten phishing-e-mails en nep-berichten om medewerkers ervan te overtuigen dat de overboekingen routinematig waren.

2) Delegatecall + proxy-truc

Hoewel Bybit een multisig-"kluis" gebruikte, veranderde de kwaadaardige JavaScript het transactietype van een normale "call" naar iets dat "delegatecall" heet.

• Delegatecall stelde de hackers in staat hun eigen code uit te voeren alsof die deel uitmaakte van het kluiscontract.
• Ze gebruikten dit om het "master copy"-adres van de kluis, een cruciaal onderdeel van hoe deze specifieke wallet werkt, te wijzigen zodat het naar het contract van de aanvallers wees.
• Met die wijziging op zijn plaats konden de aanvallers speciale "sweep"-functies uitvoeren die de kluis leegmaakten van $1,5 miljard.

Technische verdieping

Op basis van de analyse door @S1r1u5_ op X, volgt hier een stapsgewijze uitsplitsing van hoe de Safe{Wallet} gecompromitteerd werd:

1. Kwaadaardige JavaScript geïnjecteerd: de aanvallers voegden kwaadaardige code toe aan app.safe.global/_next/static/chunks/pages/_app-4f0dcee809cce622.js nadat een van de gecompromitteerde ontwikkelaars deze naar productie had gepusht.
2. Gericht op executeTransaction(): de kwaadaardige JS werd alleen geactiveerd als deze een vooraf gedefinieerde lijst van ondertekenaars herkende (in dit geval de multisig-eigenaren van Bybit).
3. Overschakelen naar delegatecall: in plaats van een normale call veranderde de kwaadaardige code de operatie naar 1, wat delegatecall is, waarmee de uitvoering werd gedelegeerd aan een contract van de aanvaller.
4. De opslag van de Safe wijzigen: door gebruik te maken van delegatecall herschreef het contract van de hacker de masterCopy-opslagslot van de Safe wallet.
5. Nieuwe master copy leegt fondsen: het nieuwe kwaadaardige "master copy"-contract bevatte de functies sweepETH() en sweepERC20(), waarmee de aanvaller $1,5 miljard aan cryptocurrency kon leegmaken.

Deze reeks gebeurtenissen stelde de aanvaller in staat alle normale multisignature-beveiligingen te omzeilen, omdat het in de wallet-interface als een geldige transactie verscheen.

Waarom client-side aanvallen moeilijk te onderzoeken zijn

Wanneer hackers toeslaan via client-side code (de JavaScript en HTML die in je webbrowser draaien), kan het achteraf verzamelen van forensisch bewijs bijzonder lastig zijn:

1. Vluchtige gegevens: browsersessies zijn van korte duur, en logs van precies welke JavaScript-bestanden werden geladen en hoe ze veranderden, kunnen onvolledig of niet-bestaand zijn. Anders dan server-side logs worden front-end logs vaak niet persistent opgeslagen.
2. Snelle implementatie en updates: moderne webapplicaties updaten of herimplementeren code regelmatig. Wanneer een aanvaller kwaadaardige scripts injecteert, kan hij die net zo snel weer terugdraaien, waardoor er slechts een kort tijdvenster overblijft om bewijs vast te leggen.
3. Beperkte serverlogs: zelfs als de server-side veilig is, vindt de echte actie plaats in de browser van de gebruiker. Standaard serverlogs kunnen aantonen dat een bestand is aangeboden, maar niet noodzakelijkerwijs welke wijzigingen in dat bestand zijn aangebracht of hoe het zich gedroeg na uitvoering.
4. Gebrek aan transparantie in versiebeheer: sommige teams houden geen openbare registratie bij van elke front-end build. Als de kwaadaardige wijziging werd geïntroduceerd via een gecompromitteerde build-pipeline, hebben forensische teams gedetailleerde versiegeschiedenissen nodig, en die kunnen slecht worden bijgehouden of gemakkelijk worden gemanipuleerd.
5. Afhankelijkheid van derden: client-side code haalt vaak content op van externe bibliotheken of CDN's. Als het kwaadaardige script via een externe dienst werd geïnjecteerd, moeten forensische teams samenwerken met externe aanbieders die mogelijk geen gedetailleerde logs bijhouden of traag zijn met medewerking.

Voor forensische onderzoekers betekent dit alles dat het reconstrueren van een client-side aanval kan inhouden dat gedeeltelijke browsercaches, developer console-logs, implementatiegeschiedenissen en beschikbare versiegegevens uit de build-pipeline aan elkaar moeten worden gepuzzeld. Het is mogelijk, maar het is aanzienlijk uitdagender dan het onderzoeken van een traditioneel server-side compromis, waarbij je doorgaans duidelijkere logs en directe toegang tot het gecompromitteerde systeem hebt.

Hoe cside had kunnen helpen

cside analyseert first-party client-side scripts en proxiet third-party JavaScript voordat het op je site wordt uitgevoerd. We slaan de scripts zelfs tot een jaar lang op, en bieden zo volledige forensische mogelijkheden waar je vandaag een blinde vlek hebt. Als Bybit cside had gebruikt, hadden onverwachte of kwaadaardige wijzigingen in de Safe wallet-interface opgemerkt en geblokkeerd kunnen worden, waardoor deze hele aanval mogelijk voorkomen had kunnen worden.

Referenties: https://x.com/lookonchain/status/1892965762186522975 https://x.com/lookonchain/status/1892971811807387877 https://x.com/lookonchain/status/1893223657838633177