Kwetsbaarheden in de beveiliging van bridges

Interoperabiliteit in de blockchainwereld vereist blockchain bridges, die een cruciale rol vervullen. Daarom is het van essentieel belang om de beveiliging van deze bridges te prioriteren. Laten we dit in onze blog bespreken.

Basisprincipes

Zwaktes in bridge-beveiliging houden vaak verband met onvoldoende on-chain en off-chain validatie, onjuiste afhandeling van native tokens en foutieve configuraties. Om robuuste verificatielogica te waarborgen, is het aan te raden de bridge grondig te testen tegen diverse aanvalsvectoren.

Wat is een blockchain bridge?

Een blockchain bridge is een protocol dat interacties tussen twee blockchains mogelijk maakt en naadloze connectiviteit faciliteert. Stel dat je Bitcoin bezit maar wilt deelnemen aan DeFi-activiteiten op het Ethereum-netwerk. In zo'n geval stelt een blockchain bridge je in staat om deel te nemen aan die activiteiten zonder je Bitcoin te liquideren.

Blockchain bridges werken door verschillende on-chain en off-chain validatiemechanismen te implementeren die essentieel zijn voor interoperabiliteit in de blockchainruimte. Daardoor hebben ze specifieke kwetsbaarheden op het gebied van beveiliging.

Waarom is bridge-beveiliging belangrijk?

Volgens schattingen in de industrie leidden bridge-aanvallen in 2022 tot ongeveer 1,3 miljard USD aan verliezen, goed voor 36% van de totale verliezen dat jaar. Deze aanvallen richten zich voornamelijk op cross-chain applicaties, aangezien bridges, vaak geïmplementeerd als smart contracts, grote tokenbalansen verzamelen bij het overdragen tussen chains. Daardoor worden bridges aantrekkelijke doelen voor hackers vanwege hun grote waarde.

Bovendien omvatten blockchain bridges tal van componenten, wat een aanzienlijk aanvalsoppervlak oplevert. Kwaadwillenden zijn sterk gemotiveerd om kwetsbaarheden in deze bridges te misbruiken om grote bedragen af te romen.

Kwetsbaarheden geassocieerd met bridges

Om de beveiliging van bridges te versterken, is het cruciaal om een goed begrip te hebben van de veelvoorkomende kwetsbaarheden die in het ontwerp kunnen ontstaan. Voordat ze live gaan, is het aan te raden bridges grondig te testen om deze kwetsbaarheden te identificeren en aan te pakken. Deze beveiligingsrisico's kunnen in verschillende categorieën worden ingedeeld.

De nadruk op on-chain validatie is voor bepaalde bridges verminderd, vooral voor bridges die zijn afgestemd op specifieke gedecentraliseerde applicaties (DApps). Deze bridges vertrouwen op een gecentraliseerde backend om fundamentele handelingen uit te voeren, zoals minten, verbranden en tokentransfers. De validatieprocessen worden ondertussen off-chain uitgevoerd.

Andere bridges gebruiken daarentegen smart contracts om berichten te valideren en verificaties on-chain uit te voeren. Wanneer een gebruiker fondsen stort op een chain, genereert het smart contract een ondertekend bericht en voegt de handtekening aan de transactie toe. 

Deze handtekening dient als bewijs van de storting en wordt vervolgens gebruikt om het opnameverzoek van de gebruiker op de doeldchain te verifiëren. Dit robuuste proces vermindert potentiële beveiligingsaanvallen, inclusief replay-aanvallen en vervalste stortingsrecords.

Desalniettemin, als er een kwetsbaarheid aanwezig is tijdens de on-chain validatiefase, kan een aanvaller deze misbruiken om aanzienlijke schade aan te richten. Als voorbeeld: bij een bridge die een Merkle-boom gebruikt voor het valideren van transactierecords, zou een aanvaller vervalste bewijzen kunnen fabriceren. Deze kwaadaardige actie zou hen in staat stellen validatie van bewijzen te omzeilen en op illegale wijze nieuwe tokens in hun account te minten, door de zwakte in het validatieproces uit te buiten.

“Wrapped Tokens” en bridge-beveiliging

Het opnemen van zogenaamde "wrapped tokens" is een veelgebruikte strategie door sommige bridges. Bijvoorbeeld: wanneer een gebruiker DAI van de Ethereum-blockchain naar de BNB Chain overzet, worden zijn DAI uit het Ethereum-contract gehaald en wordt een gelijkwaardige hoeveelheid wrapped DAI op de BNB Chain gecreëerd.

Als de validatie van deze transactie echter onvoldoende is, opent dit de deur voor potentiële aanvallers om het systeem te misbruiken. Door een kwaadaardig contract te implementeren en de functionaliteit hiervan te manipuleren, kunnen deze aanvallers de wrapped tokens van de bridge omleiden naar een ongewenst adres.

Om een dergelijke aanval succesvol uit te voeren, vertrouwen de daders erop dat slachtoffers het bridge-contract goedkeuren, zodat overdracht van tokens via de functie "transferFrom" is toegestaan. Dit stelt hen in staat om activa uit het bridge-contract leeg te halen.

Helaas wordt deze situatie verergerd door de praktijk van veel bridges om gebruikers van gedecentraliseerde applicaties te vragen om oneindige tokengoedkeuring. Hoewel deze aanpak gaskosten kan verlagen, introduceert ze extra risico's doordat een smart contract onbeperkte toegang krijgt tot tokens in de wallet van een gebruiker. Door het ontbreken van adequate validatie en de buitensporige goedkeuring kunnen aanvallers tokens van nietsvermoedende gebruikers naar zichzelf wegsluizen.

Zwakke off-chain validatie en bridge-beveiliging

In sommige bridgesystemen speelt de off-chain backendserver een kritische rol bij het verifiëren van de legitimiteit van berichten die vanaf de blockchain worden verzonden. In dit geval richten we ons op de verificatie van stortingstransacties. 

Een blockchain bridge met off-chain validatie werkt als volgt: 

• Gebruikers communiceren met de DApp om tokens naar het smart contract op de bronchain te storten.
• De DApp stuurt vervolgens de transactiehash van de storting naar de backendserver via een API.
• De transactiehash wordt door de server aan meerdere validaties onderworpen. Als het legitiem wordt geacht, ondertekent een signer een bericht en stuurt de handtekening via de API terug naar de gebruikersinterface.
• Na ontvangst van de handtekening verifieert de DApp deze en staat de gebruiker toe zijn tokens op de doeldchain op te nemen.

De backendserver moet ervoor zorgen dat de stortingstransactie die hij verwerkt daadwerkelijk heeft plaatsgevonden en niet is vervalst. Deze backendserver bepaalt of een gebruiker tokens kan opnemen op de doeldchain en is daarom een waardevol doelwit voor aanvallers.

De backendserver moet de structuur van het door de transactie uitgezonden event en het contractadres dat het event uitzond valideren. Als dat laatste wordt verwaarloosd, kan een aanvaller een kwaadaardig contract implementeren om een stortingsevent te vervalsen met dezelfde structuur als een legitiem stortingsevent. 

Als de backendserver niet verifieert welk adres het event uitzond, zou hij dit als een geldige transactie beschouwen en het bericht ondertekenen. De aanvaller kan dan de transactiehash naar de backend sturen, verificatie omzeilen en zo de tokens op de doeldchain opnemen.

Onjuiste afhandeling van native tokens

Bridges hanteren verschillende benaderingen bij de omgang met native tokens en utility tokens. In het geval van het Ethereum-netwerk is de native token ETH, terwijl de meeste utility tokens voldoen aan de ERC-20-standaard. Gebruikers moeten eerst ETH storten in het bridge-contract om het naar een andere chain over te zetten. Dit gebeurt door de ETH aan de transactie te koppelen en het bedrag uit het "msg.value"-veld op te halen.

Het storten van ERC-20 tokens verschilt aanzienlijk van het storten van ETH. Voor ERC-20-tokenstortingen moeten gebruikers toestemming geven aan het bridge-contract om hun tokens te spenderen. Nadat de tokens zijn gestort, zal het contract ofwel de tokens van de gebruiker verbranden met de functie "burnFrom()" of de tokens naar het contract overdragen met de functie "transferFrom()".

Er zijn verschillende manieren om tussen de twee scenario's te onderscheiden. De ene methode gebruikt een if-else-statement binnen dezelfde functie, terwijl een andere aparte functies voor elk scenario gebruikt. Het is cruciaal om niet te proberen ETH te storten met de ERC-20-depositfunctie, omdat dit kan leiden tot verlies van fondsen.

Bij het afhandelen van ERC-20-depositverzoeken geven gebruikers doorgaans het tokenadres als invoer aan de depositfunctie. Dit brengt echter een risico met zich mee, omdat er onbetrouwbare externe calls tijdens de transactie kunnen plaatsvinden. Om dit risico te beperken is een gangbare praktijk het implementeren van een whitelist die alleen tokens bevat die door de bridge worden ondersteund. Door alleen gewhiteliste adressen als argumenten toe te staan, worden externe calls voorkomen omdat het projectteam de tokenadressen al heeft gefilterd.

Toch kunnen er problemen ontstaan wanneer bridges cross-chain transfers van native tokens afhandelen, aangezien native tokens geen adressen hebben. In plaats daarvan wordt het nuladres (0x000...0) gebruikt om de native token te representeren. Dit kan problematisch zijn omdat het doorgeven van het nuladres aan de functie de whitelist-verificatie kan omzeilen, zelfs als die verkeerd is geïmplementeerd.

In gevallen waarin het bridge-contract "transferFrom" aanroept om gebruikersactiva naar het contract over te dragen, zal een externe call naar het nuladres false teruggeven aangezien het nuladres geen "transferFrom"-functie heeft geïmplementeerd. Als het contract de returnwaarde echter niet correct afhandelt, kan de transactie alsnog doorgaan zonder tokens naar het contract over te dragen. Dit stelt aanvallers in staat transacties uit te voeren zonder daadwerkelijk tokens naar het contract te verplaatsen.

Risico's door misconfiguratie in blockchainbeveiliging

Het toewijzen van of wijzigen van signers, het whitelisten of blacklisten van tokens en adressen en andere kritieke configuraties in de meeste blockchain bridges valt onder een bevoorrechte rol. Nauwkeurige configuratie is essentieel, want zelfs kleine slordigheden kunnen grote gevolgen hebben.

Een aanvaller misbruikte een misconfiguratie om verificatie van transferrecords te omzeilen. Het projectteam voerde een protocolupgrade uit waarbij een variabele werd aangepast. Deze variabele vertegenwoordigde de standaardwaarde van het vertrouwde bericht. Deze wijziging resulteerde in automatisch bewezen berichten, waardoor de aanvaller elk bericht kon indienen en verificatie kon passeren.

De beveiliging van bridges vergroten

Het aanpakken van beveiligingsuitdagingen in een onderling verbonden blockchain-ecosysteem vereist inzicht in de vier veelvoorkomende bridge-kwetsbaarheden die eerder zijn besproken. Elke kwetsbaarheid kent zijn eigen aandachtspunten en er is geen universele oplossing.

Bij het opstellen van foutloze verificatieprocessen is het moeilijk om generieke richtlijnen te geven vanwege de uiteenlopende verificatie-eisen van elke bridge. De meest effectieve strategie bestaat uit uitgebreide testing om potentiële aanvalsvectoren te identificeren en te mitigeren, terwijl de integriteit van de verificatielogica wordt gewaarborgd. Concluderend zijn rigoureuze tests tegen mogelijke aanvallen en een gerichte aanpak om de veelvoorkomende beveiligingskwetsbaarheden van bridges aan te pakken essentieel voor het handhaven van een veilige omgeving.

Conclusie 

Cross-chain bridges zijn al lange tijd een doelwit voor aanvallers vanwege hun aanzienlijke waarde. Builders kunnen het risico op ernstige cyberaanvallen, die bridges de afgelopen jaren hebben getroffen, verminderen door uitgebreide pre-deploy tests en deelname aan third-party audits. Bridges zijn essentieel in een wereld met meerdere chains, maar bij het ontwerpen en bouwen van Web3-infrastructuur moet beveiliging altijd voorop staan.