Dieser Artikel ist ein Beitrag aus der Community. Der Autor ist Minzhi He, ein Auditor bei CertiK.

Die in diesem Artikel geäußerten Ansichten sind die des Mitwirkenden/Autors und spiegeln nicht unbedingt die Ansichten der Binance Academy wider.

Zusammenfassung

Blockchain-Brücken sind wichtig, um Interoperabilität im Blockchain-Bereich zu erreichen. Daher ist die Brückensicherheit sehr wichtig. Zu den häufigen Sicherheitslücken von Bridges gehören eine schwache On-Chain- und Off-Chain-Validierung, unsachgemäße Handhabung nativer Token und Fehlkonfigurationen. Es wird empfohlen, die Bridge gegen alle möglichen Angriffsvektoren zu testen, um eine angemessene Verifizierungslogik sicherzustellen.

Einführung

Bridge-Blockchain ist ein Protokoll, das zwei Blockchains verbindet, um eine Interaktion zwischen ihnen zu ermöglichen. Wenn Sie über Bitcoins verfügen, aber an DeFi-Aktivitäten im Ethereum-Netzwerk teilnehmen möchten, können Sie dies mit Blockchain-Brücken tun, ohne Bitcoins verkaufen zu müssen.

Blockchain-Brücken sind unerlässlich, um Interoperabilität im Blockchain-Bereich zu erreichen. Diese Brücke nutzt verschiedene On-Chain- und Off-Chain-Validierungen und weist daher verschiedene Sicherheitslücken auf.

Warum ist Brückensicherheit wichtig?

Bridges speichern normalerweise Token, die Benutzer von einer Kette auf eine andere übertragen möchten. Bridges werden oft als Smart Contracts implementiert und speichern große Mengen an Token, wenn sich Cross-Chain-Transfers ansammeln, was sie zu verlockenden Zielen für Hacker macht.

Darüber hinaus weisen Blockchain-Brücken eine große Angriffslücke auf, da sie viele Komponenten umfassen. Daher sind Kriminelle sehr motiviert, kettenübergreifende Anwendungen ins Visier zu nehmen, um große Geldbeträge abzuschöpfen.

Nach Schätzungen von CertiK haben Bridge-Angriffe im Jahr 2022 Schäden in Höhe von mehr als 1,3 Milliarden US-Dollar verursacht, was 36 % der Gesamtverluste dieses Jahres entspricht.

Häufige Sicherheitslücken von Bridges

Um die Bridge-Sicherheit zu verbessern, ist es wichtig, allgemeine Sicherheitslücken von Bridges zu verstehen und Bridges vor dem Start zu testen. Diese Schwachstellen können in vier Bereiche eingeteilt werden.

Schwache On-Chain-Validierung

Bei einfachen Brücken, insbesondere solchen, die für bestimmte DApps entwickelt wurden, ist die On-Chain-Validierung minimal. Die Brücke basiert auf einem zentralen Backend, um grundlegende Vorgänge wie Prägen, Brennen und Token-Übertragung auszuführen, während die gesamte Überprüfung außerhalb der Kette erfolgt.

Im Gegensatz dazu verwenden andere Arten von Brücken intelligente Verträge, um Nachrichten zu validieren und eine On-Chain-Verifizierung durchzuführen. Wenn ein Benutzer in dieser Situation Geld in eine Kette einzahlt, generiert der Smart Contract eine signierte Nachricht und gibt die Signatur in der Transaktion zurück. Diese Signatur dient als Einzahlungsnachweis und wird zur Überprüfung von Benutzeranfragen auf anderen Ketten verwendet. Dieser Prozess soll verschiedene Sicherheitsangriffe verhindern, darunter Replay-Angriffe und gefälschte Einzahlungsaufzeichnungen.

Wenn jedoch während des On-Chain-Validierungsprozesses eine Schwachstelle besteht, könnte ein Angreifer schweren Schaden anrichten. Wenn eine Bridge beispielsweise einen Merkle-Baum zur Validierung von Transaktionsdatensätzen verwendet, könnte ein Angreifer falsche Beweise generieren. Dies bedeutet, dass sie die Beweisvalidierung umgehen und neue Token auf ihr Konto prägen können, wenn der Validierungsprozess anfällig ist.

Einige Bridges implementieren das „Wrapped Token“-Konzept. Wenn ein Benutzer beispielsweise DAI von Ethereum an die BNB-Kette überträgt, wird sein DAI aus dem Ethereum-Vertrag entnommen und ein entsprechender Betrag an verpacktem DAI wird an die BNB-Kette ausgegeben.

Wenn diese Transaktionen jedoch nicht ordnungsgemäß validiert werden, kann ein Angreifer einen böswilligen Vertrag implementieren, um verpackte Token von der Bridge an die falsche Adresse weiterzuleiten, indem er deren Funktionalität manipuliert.

Der Angreifer verlangt außerdem, dass das Opfer dem Überbrückungsvertrag zustimmt, um Token mithilfe der „transferFrom“-Funktion zu übertragen und Vermögenswerte aus dem Überbrückungsvertrag abzuleiten.

Leider wird die Situation noch schlimmer, da die meisten Bridges eine unbegrenzte Token-Genehmigung von DApp-Benutzern erfordern. Dies ist eine gängige Praxis, die die Gasgebühren senkt, aber zusätzliche Risiken birgt, da Smart Contracts den Zugriff auf Token aus einer unbegrenzten Anzahl von Benutzer-Wallets ermöglichen. Angreifer können die fehlende Validierung und übermäßige Genehmigung ausnutzen, um Token von anderen Benutzern auf sich selbst zu übertragen.

Schwache Off-Chain-Validierung

In einigen Brückensystemen spielen Off-Chain-Backend-Server eine wichtige Rolle bei der Überprüfung der Gültigkeit von Nachrichten, die von der Blockchain gesendet werden. In diesem Fall konzentrieren wir uns auf die Überprüfung von Einzahlungstransaktionen.

Die Funktionsweise einer Blockchain-Brücke mit Off-Chain-Validierung ist wie folgt:

1. Benutzer interagieren mit der DApp, um Token in Smart Contracts in der Quellkette einzuzahlen.

2. Anschließend sendet die DApp den Hash der Einzahlungstransaktion über eine API an den Backend-Server.

3. Transaktions-Hashes erfordern eine gewisse Validierung durch den Server. Wenn sie als gültig erachtet wird, signiert der Unterzeichner die Nachricht und sendet die Signatur dann über die API an die Benutzeroberfläche zurück.

4. Nach Erhalt der Signatur überprüft die DApp diese und ermöglicht dem Benutzer dann, Token aus der Zielkette abzuheben.

Der Backend-Server muss sicherstellen, dass die verarbeitete Einzahlungstransaktion tatsächlich stattgefunden hat und nicht gefälscht wurde. Dieser Backend-Server bestimmt, ob Benutzer Token auf der Zielkette abheben können, was ihn zu einem hochwertigen Ziel für Angreifer macht.

Der Backend-Server muss die aus der Transaktion resultierende Ereignisstruktur sowie die Adresse des Vertrags, der das Ereignis generiert hat, validieren. Wenn die Vertragsadresse ignoriert wird, kann ein Angreifer einen böswilligen Vertrag implementieren, um ein Einzahlungsereignis zu fälschen, indem er dieselbe Struktur wie ein legitimes Einzahlungsereignis verwendet.

Wenn die Adresse, die das Ereignis generiert hat, nicht überprüft wird, kann der Back-End-Server davon ausgehen, dass dieser Vertrag gültig ist, und die Nachricht signieren. Anschließend kann der Angreifer den Transaktions-Hash an das Backend senden, wodurch die Überprüfung umgangen wird und es ihm ermöglicht wird, Token aus der Zielkette abzuheben.

Unsachgemäßer Umgang mit nativen Token

Bridge verfolgt verschiedene Ansätze für den Umgang mit nativen Token und Utility-Token. Im Ethereum-Netzwerk ist beispielsweise der native Token ETH und die meisten Utility-Token folgen dem ERC-20-Standard.

Wenn ein Benutzer beabsichtigt, seine ETH auf eine andere Kette zu übertragen, muss er diese zunächst im Brückenvertrag hinterlegen. Um dies zu erreichen, hängen Benutzer einfach ETH an eine Transaktion an, und dann kann der ETH-Betrag durch Lesen des Felds „msg.value“ der Transaktion abgerufen werden.

Die Einzahlung von ERC-20-Tokens unterscheidet sich stark von der Einzahlung von ETH. Um ERC-20-Token einzuzahlen, müssen Benutzer zunächst dem Brückenvertrag erlauben, ihre Token zu verwenden. Sobald er zustimmt und die Token im Brückenvertrag hinterlegt, brennt der Vertrag entweder die Token des Benutzers mithilfe der Funktion „burnFrom()“ oder überträgt die Token des Benutzers mithilfe der Funktion „transferFrom()“ in den Vertrag.

Ein Ansatz zur Unterscheidung besteht darin, if-else-Anweisungen innerhalb derselben Funktion zu verwenden. Ein anderer Ansatz besteht darin, zwei separate Funktionen zur Handhabung jedes Szenarios zu erstellen. Der Versuch, ETH über die ERC-20-Einzahlungsfunktion einzuzahlen, kann zum Verlust von Geldern führen.

Bei der Bearbeitung einer ERC-20-Einzahlungsanfrage geben Benutzer normalerweise eine Token-Adresse als Eingabe für die Einzahlungsfunktion an. Diese Aktion birgt erhebliche Risiken, da es bei Transaktionen zu nicht vertrauenswürdigen externen Aufrufen kommen kann. Die Implementierung einer Whitelist, die nur Bridge-gestützte Token enthält, ist eine gängige Praxis, um das Risiko zu minimieren. Als Argumente dürfen nur Adressen auf der Whitelist übergeben werden. Dies verhindert externe Aufrufe, da das Projektteam bereits Token-Adressen filtert.

Allerdings treten auch Probleme auf, wenn die Bridge kettenübergreifende Übertragungen nativer Token abwickelt, da native Token keine Adressen haben. Adresse Null (0x000...0) repräsentiert den ursprünglichen Token. Dies kann problematisch sein, da die Übergabe einer Nulladresse an eine Funktion die Überprüfung der Whitelist umgehen kann, selbst wenn sie falsch implementiert ist.

Wenn der Brückenvertrag „transferFrom“ aufruft, um Benutzerressourcen in den Vertrag zu übertragen, gibt der externe Aufruf an Adresse Null „false“ zurück, da in Adresse Null keine „transferFrom“-Funktion implementiert ist. Es kann jedoch dennoch zu Transaktionen kommen, wenn der Vertrag den resultierenden Wert nicht korrekt verarbeiten kann. Dies bietet Angreifern die Möglichkeit, Transaktionen auszuführen, ohne Token in den Vertrag zu übertragen.

Konfigurationsfehler

In den meisten Blockchain-Brücken ist eine privilegierte Position für das Whitelisting oder Blacklisting von Token und Adressen, das Zuweisen oder Ändern von Unterzeichnern und andere wichtige Konfigurationen verantwortlich. Es ist von entscheidender Bedeutung, sicherzustellen, dass alle Konfigurationen korrekt sind, da selbst scheinbar triviale Fehler große Verluste verursachen können.

Tatsächlich gelang es einem Angreifer bei einem Vorfall, die Überprüfung des Übertragungsdatensatzes aufgrund eines Konfigurationsfehlers zu umgehen. Das Projektteam führte mehrere Tage vor dem Hack ein Protokoll-Upgrade durch, bei dem eine Variable geändert wurde. Die Variable wird verwendet, um den Standardwert vertrauenswürdiger Nachrichten darzustellen. Diese Änderung führt dazu, dass alle Nachrichten automatisch als bestätigt gelten, sodass Angreifer nach Belieben Nachrichten senden und den Überprüfungsprozess umgehen können.

So verbessern Sie die Bridge-Sicherheit

Die vier oben beschriebenen häufigen Schwachstellen von Brücken verdeutlichen die Herausforderungen bei der Gewährleistung der Sicherheit in einem vernetzten Blockchain-Ökosystem. Es gibt wichtige Überlegungen zur Behebung jeder dieser Schwachstellen. Es gibt keine einheitliche Richtlinie, die für alles gilt.

Beispielsweise ist es schwierig, allgemeine Richtlinien zur Gewährleistung eines fehlerfreien Verifizierungsprozesses bereitzustellen, da jede Brücke einzigartige Verifizierungsanforderungen hat. Der effektivste Ansatz zur Verhinderung einer Verifizierungsumgehung besteht darin, die Bridge gründlich gegen alle möglichen Angriffsvektoren zu testen und sicherzustellen, dass die Verifizierungslogik sinnvoll ist.

Zusammenfassend ist es wichtig, strenge Tests auf potenzielle Angriffe durchzuführen und den häufigen Sicherheitslücken in Bridges besondere Aufmerksamkeit zu schenken.

Schließen

Aufgrund ihres hohen Werts sind Cross-Chain-Brücken seit langem ein Ziel für Angreifer. Bauherren können die Sicherheit von Brücken stärken, indem sie vor der Implementierung gründliche Tests durchführen und Prüfungen durch Dritte durchführen, um das Risiko kostspieliger Hackerangriffe zu verringern, die Brücken in den letzten Jahren heimgesucht haben. Brücken sind in einer Multi-Chain-Welt unerlässlich, aber Sicherheit muss beim Entwurf und Aufbau einer effektiven Web3-Infrastruktur ein vorrangiges Anliegen sein.

Weiterführende Literatur

Was ist Bridge-Blockchain?

Was ist kettenübergreifende Interoperabilität?

Drei beliebte Krypto-Brücken und wie sie funktionieren

Was sind verpackte Token?

Haftungsausschluss und Risikowarnung: Dieser Inhalt wird Ihnen „wie besehen“ nur zu allgemeinen Informations- und Bildungszwecken präsentiert, ohne Zusicherungen oder Gewährleistungen jeglicher Art. Dieser Inhalt ist weder als finanzielle, rechtliche oder sonstige professionelle Beratung zu verstehen, noch ist er als Kaufempfehlung für ein bestimmtes Produkt oder eine bestimmte Dienstleistung gedacht. Sie sollten sich von entsprechenden Fachberatern beraten lassen. Wenn es sich bei dem Artikel um einen Beitrag eines Drittautors handelt, beachten Sie bitte, dass die geäußerten Ansichten die des Drittautors sind und nicht unbedingt die Ansichten der Binance Academy widerspiegeln. Für weitere Einzelheiten lesen Sie bitte hier unseren vollständigen Haftungsausschluss. Die Preise digitaler Vermögenswerte können volatil sein. Der Wert Ihrer Anlage kann fallen oder steigen. Möglicherweise erhalten Sie den investierten Betrag nicht zurück. Sie tragen die volle Verantwortung für Ihre Anlageentscheidungen. Die Binance Academy übernimmt keine Haftung für eventuelle Verluste. Dieses Material sollte nicht als finanzielle, rechtliche oder sonstige professionelle Beratung betrachtet werden. Weitere Informationen finden Sie in unseren Nutzungsbedingungen und Risikohinweisen.