Op 21 februari 2025 was de cryptowereld getuige van een van de grootste cryptodiefstallen 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 Bangladesh Bank-roof). 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 hadden 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 aanpassen voordat een gebruiker ook maar op "Goedkeuren" klikt. Daarom hebben we cside gebouwd. Om websites in staat te stellen afhankelijkheden 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 het deel uitmaakte van het kluiscontract.
- Ze gebruikten dit om het "master copy"-adres van de kluis te wijzigen—een belangrijk onderdeel van hoe deze specifieke wallet werkt—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.
Hier zijn de stapsgewijze technische details van hoe de Safe{Wallet} gecompromitteerd werd:
- Kwaadaardige JavaScript geïnjecteerd
- De aanvallers voegden kwaadaardige code toe aan app.safe.global/_next/static/chunks/pages/_app-4f0dcee809cce622.js. Kortgezegd: een van de gecompromitteerde ontwikkelaars heeft het naar productie gepusht.
- Gericht op executeTransaction()
- De kwaadaardige JS werd alleen geactiveerd als het een vooraf gedefinieerde lijst van ondertekenaars herkende (in dit geval de multisig-eigenaren van Bybit).
- Overschakelen naar delegatecall
- In plaats van een normale call veranderde de kwaadaardige code de operatie naar 1, wat delegatecall is. Daarmee werd de uitvoering gedelegeerd aan een contract van de aanvaller.
- De opslag van de Safe aanpassen
- Door gebruik te maken van delegatecall heeft het contract van de hacker de masterCopy-opslagslot van de Safe wallet effectief overschreven.
- Nieuw 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.
Kortom:
- Front-end-aanvallen worden onderschat Mensen richten zich vaak op back-endservers, maar een eenvoudige wijziging in de websitecode kan gebruikers ertoe verleiden van alles te ondertekenen.
- Menselijke fouten Social engineering maakt gebruik van mensen die gehaast zijn of de inhoud van e-mails vertrouwen. Een zorgvuldig opgesteld nep-bericht kan zelfs goed getraind personeel misleiden.
- Delegatecall + proxy-patronen Veel crypto-wallets en DeFi-protocollen gebruiken "proxy"-contracten voor flexibiliteit. Als een aanvaller de verwijzing echter naar zijn eigen code omzet, kan hij volledige controle overnemen.
- Misleidende interfaces De interface toonde alles als "legitiem," zodat de ondertekenaars geen idee hadden dat ze kwaadaardige transacties goedkeurden.
- Complexe systemen Zelfs met meerdere beveiligingslagen kan één enkele fout in gebruikersbewustzijn of front-end-integriteit alles doen instorten.
Waarom client-side aanvallen moeilijk te onderzoeken zijn
Wanneer hackers toeslaan via client-side code (de JavaScript en HTML die in uw webbrowser draaien), kan het achteraf verzamelen van forensisch bewijs bijzonder lastig zijn:
- 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.
- Snelle implementatie en updates:
- Moderne webapplicaties updaten of herimplementeren code regelmatig. Wanneer een aanvaller kwaadaardige scripts injecteert, kunnen ze deze net zo snel terugdraaien—waardoor er slechts een kort tijdvenster overblijft om bewijs vast te leggen.
- 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.
- 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.
- Afhankelijkheid van derden:
- Client-side code haalt vaak bestanden 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 gekoppeld. Het is mogelijk—maar het is aanzienlijk uitdagender dan het onderzoeken van een traditioneel server-side compromis, waarbij u doorgaans duidelijkere logs en directe toegang tot het gecompromitteerde systeem heeft.
Hoe cside had kunnen helpen
cside is een oplossing die first-party client-side scripts analyseert en third-party JavaScript proxiet voordat het op uw site wordt uitgevoerd. We slaan de scripts zelfs tot een jaar op en bieden volledige forensische mogelijkheden waar u vandaag een blinde vlek heeft. Als Bybit cside had gebruikt, hadden onverwachte of kwaadaardige wijzigingen in de Safe wallet-interface onderschept en geblokkeerd kunnen worden, waardoor deze aanval mogelijk volledig voorkomen had kunnen worden.
Referenties: https://x.com/lookonchain/status/1892965762186522975 https://x.com/lookonchain/status/1892971811807387877 https://x.com/lookonchain/status/1893223657838633177
