Interoperabilität im Blockchain‑Bereich erfordert Blockchain‑Brücken, die eine entscheidende Rolle spielen. Deshalb ist die Priorisierung der Sicherheit dieser Bridges unerlässlich. In diesem Blog gehen wir darauf ein.
Sicherheitslücken bei Bridges betreffen häufig unzureichende on‑chain- und off‑chain‑Validierung, fehlerhafte Handhabung nativer Tokens und Fehlkonfigurationen. Um eine robuste Verifikationslogik zu gewährleisten, empfiehlt es sich, die Bridge gegen verschiedene Angriffsvektoren gründlich zu testen.
Eine Blockchain‑Bridge ist ein Protokoll, das Interaktionen zwischen zwei Blockchains ermöglicht und nahtlose Konnektivität schafft. Sie besitzen beispielsweise Bitcoin, möchten aber DeFi‑Funktionen im Ethereum‑Netz nutzen. In einem solchen Fall erlaubt Ihnen eine Bridge, an diesen Aktivitäten teilzunehmen, ohne Ihre Bitcoin zu veräußern.
Blockchain‑Brücken arbeiten mit unterschiedlichen on‑chain‑ und off‑chain‑Validierungsmechanismen, die für Interoperabilität unerlässlich sind. Dadurch ergeben sich spezifische Sicherheitsanfälligkeiten.
Branchenschätzungen zufolge führten Angriffe auf Bridges 2022 zu Verlusten von rund 1,3 Milliarden USD und machten 36 % der Gesamtschäden dieses Jahres aus. Solche Angriffe zielen vor allem auf Cross‑Chain‑Anwendungen, denn Bridges, häufig als Smart Contracts implementiert, sammeln beim Transfer zwischen Chains große Token‑Beträge an. Dadurch werden Bridges zu attraktiven Zielen für Hacker.
Zudem bestehen Blockchain‑Brücken aus zahlreichen Komponenten, was die Angriffsfläche erheblich vergrößert. Böswillige Akteure sind stark motiviert, Schwachstellen in diesen Komponenten auszunutzen, um große Summen zu entwenden.
Um die Sicherheit von Bridges zu erhöhen, ist ein umfassendes Verständnis der gängigen Schwachstellen in ihrem Design notwendig. Vor dem Launch sollten Bridges gründlich getestet werden, um diese Schwachstellen zu erkennen und zu beheben. Die Sicherheitsrisiken lassen sich in verschiedene Bereiche unterteilen.
Die Betonung der on‑chain‑Validierung ist bei bestimmten Bridges, insbesondere solchen für spezifische dezentrale Anwendungen (DApps), gering. Diese Bridges verlassen sich auf ein zentrales Backend, das grundlegende Operationen wie Minting, Burning und Token‑Transfers ausführt, während die Validierung off‑chain erfolgt.
Andere Bridges nutzen Smart Contracts, um Nachrichten on‑chain zu validieren und Verifikationen durchzuführen. Wenn ein Nutzer Gelder in einer Chain einzahlt, erzeugt der Smart Contract eine signierte Nachricht und fügt die Signatur der Transaktion bei.
Diese Signatur dient als Nachweis der Einzahlung und wird verwendet, um die Abhebungsanfrage des Nutzers in der Ziel‑Chain zu authentifizieren. Dieser robuste Prozess mindert Sicherheitsrisiken wie Replay‑Angriffe und gefälschte Einzahlungsnachweise.
Denn dennoch kann eine Schwachstelle in der on‑chain‑Validierung es einem Angreifer ermöglichen, großen Schaden anzurichten. Verwendet eine Bridge beispielsweise einen Merkle‑Baum zur Validierung von Transaktionsnachweisen, könnte ein Angreifer gefälschte Proofs konstruieren. Dadurch würde er die Proof‑Validierung umgehen und unrechtmäßig neue Token in sein Konto minten, indem er die Schwäche im Validierungsprozess ausnutzt.
Ein verbreiteter Ansatz mancher Bridges ist die Verwendung sogenannter „Wrapped Tokens“. Transferiert ein Nutzer etwa DAI von Ethereum zur BNB Chain, werden die DAI auf dem Ethereum‑Contract zurückgezogen und ein entsprechender Betrag an Wrapped‑DAI auf der BNB Chain erzeugt.
Ist die Validierung dieses Transfers jedoch unzureichend, öffnet das Angreifern Tür und Tor. Durch das Deployen eines bösartigen Contracts und Manipulation seiner Funktionalität können Angreifer die Wrapped‑Token von der Bridge an eine fremde Adresse umleiten.
Zur erfolgreichen Ausführung eines derartigen Angriffs verlassen sich Täter darauf, dass Opfer dem Bridge‑Contract die Erlaubnis erteilen, Token via transferFrom zu verschieben. So können sie Vermögenswerte aus dem Bridge‑Contract abziehen.
Verschärfend kommt hinzu, dass viele Bridges unbegrenzte Token‑Freigaben von DApp‑Nutzern verlangen. Zwar reduziert das Gas‑Kosten, erhöht aber das Risiko, weil ein Smart Contract so unbegrenzt auf Tokens im Wallet einer Person zugreifen kann. Durch Ausnutzen fehlender Validierung und überhöhter Freigaben können Angreifer Token von ahnungslosen Nutzern abziehen.
In einigen Bridge‑Systemen spielt das Off‑Chain‑Backend eine zentrale Rolle bei der Verifikation der Legitimität von Blockchain‑Nachrichten. Hier konzentrieren wir uns auf die Verifizierung von Einzahlungs‑Transaktionen.
Eine Blockchain‑Bridge mit Off‑Chain‑Validierung funktioniert typischerweise so:
Der Backend‑Server muss sicherstellen, dass die verarbeitete Einzahlungs‑Transaktion tatsächlich stattgefunden hat und nicht gefälscht ist. Dieser Server entscheidet, ob ein Nutzer auf der Ziel‑Chain Token abheben darf, und ist daher ein hochrangiges Angriffsziel.
Der Backend‑Server muss die Struktur des emittierten Events einer Transaktion und die Contract‑Adresse, die das Event ausgesendet hat, validieren. Wird Letzteres vernachlässigt, könnte ein Angreifer einen bösartigen Contract deployen und ein Einzahlungs‑Event mit derselben Struktur wie ein legitimes Event fälschen.
Wenn der Backend‑Server nicht prüft, welche Adresse das Event gesendet hat, würde er dies als gültige Transaktion ansehen und die Nachricht signieren. Der Angreifer könnte dann den Transaktions‑Hash an das Backend senden, die Verifikation umgehen und die Token auf der Ziel‑Chain abheben.
Bridges verfolgen unterschiedliche Ansätze beim Umgang mit nativen Tokens und Utility‑Tokens. Auf Ethereum ist das native Token ETH, während die meisten Utility‑Tokens dem ERC‑20‑Standard folgen. Nutzer müssen ETH zunächst in den Bridge‑Contract einzahlen, um es auf eine andere Chain zu transferieren. Dies geschieht, indem das ETH an die Transaktion angehängt und der Betrag aus dem Feld msg.value gelesen wird.
Das Einzahlen von ERC‑20‑Tokens unterscheidet sich deutlich vom Einzahlen von ETH. Bei ERC‑20‑Einzahlungen müssen Nutzer dem Bridge‑Contract die Erlaubnis geben, ihre Tokens auszugeben. Nach der Einzahlung verbrennt der Contract entweder die Tokens des Nutzers mittels burnFrom() oder transferiert sie via transferFrom() an den Contract.
Es gibt verschiedene Herangehensweisen, die Szenarien zu unterscheiden. Eine Methode nutzt if‑else innerhalb derselben Funktion, eine andere separate Funktionen für jeden Fall. Es ist essenziell, nicht zu versuchen, ETH über die ERC‑20‑Einzahlungsfunktion einzureichen, da dies zum Verlust von Mitteln führen kann.
Bei ERC‑20‑Einzahlungsanforderungen geben Nutzer üblicherweise die Token‑Adresse als Argument an die Deposit‑Funktion. Das birgt das Risiko externer, nicht vertrauenswürdiger Aufrufe während der Transaktion. Eine gängige Gegenmaßnahme ist eine Whitelist, die nur die von der Bridge unterstützten Tokens enthält. Erlaubt man nur diese whitelisted Adressen als Argumente, werden externe Calls verhindert, da das Projektteam die Token‑Adressen bereits gefiltert hat.
Dennoch entstehen Probleme, wenn Bridges native Tokens über Chains transferieren, denn native Tokens haben keine Adresse. Stattdessen repräsentiert eine Nulladresse (0x000...0) das native Token. Das kann problematisch sein, weil das Übergeben der Nulladresse an die Funktion die Whitelist‑Prüfung umgehen kann, wenn diese fehlerhaft implementiert ist.
Wenn der Bridge‑Contract transferFrom aufruft, um Nutzer‑Vermögenswerte an den Contract zu übertragen, wird ein externer Aufruf an die Nulladresse false zurückgeben, da die Nulladresse keine transferFrom‑Funktion implementiert hat. Wird der Rückgabewert jedoch nicht korrekt behandelt, kann die Transaktion trotzdem fortlaufen, ohne dass Tokens an den Contract übertragen werden. Das ermöglicht es Angreifern, Transaktionen auszuführen, ohne Tokens an den Contract zu transferieren.
Das Whitelisting oder Blacklisting von Tokens und Adressen, das Zuweisen oder Ändern von Signern und andere kritische Konfigurationen liegen in den meisten Blockchain‑Bridges bei privilegierten Rollen. Eine korrekte Konfiguration ist essenziell, denn schon kleine Fehler können gravierende Folgen haben.
Ein Angreifer nutzte eine Fehlkonfiguration, um die Verifikation von Transfer‑Nachweisen zu umgehen. Das Projektteam implementierte ein Protokoll‑Upgrade und änderte dabei eine Variable, die den Standardwert einer vertrauenswürdigen Nachricht repräsentierte. Diese Änderung führte zu automatisch als bewiesen geltenden Nachrichten, sodass der Angreifer beliebige Nachrichten einreichen und die Verifikation passieren konnte.
Die Sicherheitsherausforderungen in einem vernetzten Blockchain‑Ökosystem lassen sich durch das Verständnis der vier zuvor beschriebenen Schwachstellen angehen. Jede Schwachstelle erfordert spezifische Maßnahmen; eine Universallösung gibt es nicht.
Allgemeingültige Richtlinien für fehlerfreie Verifikationsprozesse sind schwer zu geben, da die Validierungsanforderungen jeder Bridge variieren. Die effektivste Strategie ist umfassendes Testen, um potenzielle Angriffsvektoren zu identifizieren und die Integrität der Verifikationslogik sicherzustellen. Zusammenfassend sind strenge Tests gegen mögliche Angriffe und ein fokussiertes Vorgehen bei den verbreiteten Schwachstellen von Bridges entscheidend, um ein sicheres Umfeld zu erhalten.
Cross‑Chain‑Bridges sind aufgrund ihres hohen Wertes seit langem Ziel von Angreifern. Entwickler können das Risiko schwerer Cyberangriffe, die Bridges in den letzten Jahren heimgesucht haben, durch umfassende Tests vor dem Deployment und durch unabhängige Audits reduzieren. Bridges sind in einer Multi‑Chain‑Welt unverzichtbar, doch beim Aufbau einer Web3‑Infrastruktur muss Sicherheit an erster Stelle stehen.