Dieser Artikel ist ein Community-Beitrag. Der Autor ist Minzhi He, Auditor von CertiK.

Die Meinungen in diesem Artikel sind die des Mitwirkenden/Autors und spiegeln nicht unbedingt die Ansichten der Binance Academy wider.

Zusammenfassung

Blockchain-Brücken sind entscheidend für die Interoperabilität im Blockchain-Bereich. Daher ist Ihre Sicherheit von größter Bedeutung. Zu den häufigsten Sicherheitslücken bei 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 robuste Verifizierungslogik sicherzustellen.

Einführung

Eine Blockchain-Brücke ist ein Protokoll, das zwei Blockchains verbindet, um Interaktionen zwischen ihnen zu ermöglichen. Wenn Sie über Bitcoin verfügen, aber an einer DeFi-Aktivität im Ethereum-Netzwerk teilnehmen möchten, können Sie dies mit einer Blockchain-Brücke tun, ohne Ihre Bitcoin verkaufen zu müssen.

Blockchain-Brücken sind entscheidend für die Interoperabilität im Blockchain-Bereich. Sie durchlaufen verschiedene On-Chain- und Off-Chain-Validierungen und weisen daher unterschiedliche Sicherheitslücken auf.

Warum ist Brückensicherheit so wichtig?

Typischerweise enthält eine Bridge den Token, den ein Benutzer von einer Kette auf eine andere übertragen möchte. Bridges, die oft als Smart Contracts implementiert werden, enthalten eine beträchtliche Menge an Token, wenn sich Cross-Chain-Transfers ansammeln, was sie zu lukrativen Zielen für Hacker macht.

Darüber hinaus bieten Blockchain-Brücken eine große Angriffsfläche, da sie mehrere Komponenten umfassen. Vor diesem Hintergrund betrachten böswillige Akteure kettenübergreifende Anwendungen als sehr gute Ziele für den Diebstahl großer Geldbeträge.

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

Häufige Schwachstellen in der Bridge-Sicherheit

Um die Sicherheit von Bridges zu verbessern, ist es wichtig, ihre häufigsten Schwachstellen zu verstehen und sie vor ihrer Veröffentlichung zu testen. Diese Schwachstellen können in die folgenden vier Bereiche eingeteilt werden.

Schwache On-Chain-Validierung

Bei einfachen Brücken, insbesondere solchen, die für bestimmte DApps entwickelt wurden, wird die On-Chain-Validierung auf ein Minimum beschränkt. Diese Brücken basieren auf einem zentralen Backend, um grundlegende Vorgänge wie das Prägen, Brennen und Übertragen von Token auszuführen, während alle Überprüfungen außerhalb der Kette durchgeführt werden.

Im Gegensatz dazu verwenden andere Arten von Brücken intelligente Verträge, um Nachrichten zu validieren und On-Chain-Verifizierungen durchzuführen. In diesen Fällen generiert der Smart Contract eine signierte Nachricht und gibt die Signatur in der Transaktion zurück, wenn ein Benutzer in der Kette einzahlt. Die Signatur dient als Nachweis der Einzahlung und wird verwendet, um die Auszahlungsanfrage des Benutzers auf der anderen Kette zu überprüfen. Dieser Prozess soll in der Lage sein, verschiedene Arten von Sicherheitsangriffen zu verhindern, darunter Replay-Angriffe und die Fälschung von Einzahlungsunterlagen.

Wenn es jedoch eine Schwachstelle im Validierungsprozess in der Kette gibt, kann der Angreifer großen Schaden anrichten. Wenn eine Bridge beispielsweise den Merkle-Baum zur Validierung des Transaktionsprotokolls verwendet, kann ein Angreifer gefälschte Belege generieren. Das heißt, wenn der Validierungsprozess angreifbar ist, kann der Angreifer die Quittungsvalidierung umgehen und neue Token für Ihr Konto prägen.

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

Wenn die Transaktion jedoch nicht korrekt validiert wird, kann ein Angreifer einen böswilligen Vertrag implementieren, um die verpackten Token von der Bridge an eine falsche Adresse zu leiten.

Angreifer benötigen außerdem die Zustimmung des Opfers zum Bridge-Vertrag, um Token mithilfe der „transferFrom“-Funktion zu übertragen und so Vermögenswerte aus dem Bridge-Vertrag zu entnehmen.

Leider wird dies noch dadurch verschlimmert, dass viele Bridges von DApps-Benutzern eine unbegrenzte Genehmigung von Tokens verlangen. Dies ist eine gängige Praxis, die die Gasgebühren senkt, aber zusätzliche Risiken birgt, da ein Smart Contract auf eine unbegrenzte Anzahl von Token aus der Wallet des Benutzers zugreifen kann. Angreifer können mangelnde Validierung und übermäßige Genehmigung ausnutzen, um Token von anderen Benutzern auf sich selbst zu übertragen.

Schwache Off-Chain-Validierung

In einigen Brückensystemen spielt der Off-Chain-Backend-Server eine entscheidende Rolle bei der Überprüfung der Legitimität von Nachrichten, die von der Blockchain gesendet werden. Dieses Mal konzentrieren wir uns auf die Überprüfung von Einzahlungstransaktionen.

Eine Blockchain-Brücke mit Off-Chain-Validierung funktioniert wie folgt:

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

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

  3. Der Transaktions-Hash durchläuft mehrere Validierungen durch den Server. Wenn dies als legitim erachtet wird, signiert ein Unterzeichner die Nachricht und sendet die Signatur über die API an die Benutzeroberfläche zurück.

  4. Nach Erhalt der Signatur überprüft die DApp diese und autorisiert den Benutzer, die Token aus der Zielkette zu entfernen.

Der Backend-Server muss sicherstellen, dass die von ihm verarbeitete Einzahlungstransaktion tatsächlich stattgefunden hat und keine Fälschung ist. Dieser Backend-Server bestimmt, ob der Benutzer Token auf der Zielkette abheben kann und ist daher ein begehrtes Angriffsziel für Cyberkriminelle.

Der Backend-Server muss die Struktur des von der Transaktion ausgegebenen Ereignisses sowie die Vertragsadresse, die das Ereignis ausgegeben hat, validieren. Wenn Letzteres vernachlässigt wird, könnte ein Angreifer einen böswilligen Vertrag einsetzen, um ein Einzahlungsereignis mit der gleichen Struktur wie das legitime Einzahlungsereignis zu fälschen.

Wenn der Backend-Server nicht überprüft, welche Adresse das Ereignis ausgegeben hat, könnte er es als gültige Transaktion betrachten und die Nachricht signieren. Der Angreifer könnte dann den Transaktions-Hash an das Backend senden, die Überprüfung umgehen und es schaffen, die Token aus der Zielkette zu entfernen.

Unsachgemäßer Umgang mit nativen Token

Bridges verfolgen unterschiedliche 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 entsprechen dem ERC-20-Standard.

Wenn ein Benutzer versucht, seine ETH auf eine andere Kette zu übertragen, muss er diese zunächst im Brückenvertrag hinterlegen. Um dies zu erreichen, hängt der Benutzer einfach die ETH an die Transaktion an und der ETH-Betrag kann 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 einen ERC-20-Token einzuzahlen, muss der Benutzer zunächst dem Brückenvertrag erlauben, seine Token auszugeben. Nachdem Genehmigung und Token im Brückenvertrag hinterlegt wurden, brennt der Vertrag die Token des Benutzers mit der Funktion „burnFrom()“ oder überträgt den Token des Benutzers mit der Funktion „transferFrom()“ in den Vertrag.

Eine Möglichkeit, dies zu unterscheiden, besteht darin, eine bedingte Anweisung innerhalb der Funktion selbst zu verwenden. Eine andere Möglichkeit besteht darin, zwei separate Funktionen zu erstellen, um jedes Szenario zu verarbeiten. Der Versuch, ETH über die Einzahlungsfunktion für ERC-20 einzuzahlen, kann zum Verlust von Geldern führen.

Bei der Bearbeitung von ERC-20-Einzahlungsanfragen geben Benutzer normalerweise die Token-Adresse als Eingabe für die Einzahlungsfunktion an. Dies birgt ein erhebliches Risiko, da es während der Transaktion zu unzuverlässigen externen Anrufen kommen kann. Um dieses Risiko zu minimieren, ist die Implementierung einer Whitelist, die nur von der Bridge unterstützte Token enthält, eine gängige Praxis. Als Argument können nur Adressen auf der Whitelist übergeben werden. Dies verhindert externe Aufrufe, da das Projektteam die Token-Adresse bereits preisgegeben hat.

Allerdings kann es zu Problemen kommen, wenn Bridges die kettenübergreifende Übertragung nativer Token abwickeln, da der native Token keine Adresse hat. Eine Nulladresse (0x000...0) repräsentiert den nativen Token. Dies kann problematisch sein, da die Übergabe der Adresse Null an die Funktion die Whitelist-Prüfung umgehen kann, selbst wenn sie korrekt implementiert ist.

Wenn der Brückenvertrag „transferFrom“ aufruft, um die Vermögenswerte des Benutzers auf den Vertrag zu übertragen, gibt der externe Aufruf an Adresse Null „false“ zurück, da an Adresse Null keine „transferFrom“-Funktion implementiert ist. Die Transaktion kann jedoch trotzdem stattfinden, wenn der Vertrag den zurückgegebenen Wert nicht ordnungsgemäß verarbeitet. Dies bietet Angreifern die Möglichkeit, die Transaktion auszuführen, ohne Token in den Vertrag zu übertragen.

Falsche Konfiguration

In den meisten Blockchain-Brücken ist die Person, die für das Whitelisting oder Blacklisting von Tokens und Adressen, das Zuweisen oder Ändern von Unterzeichnern und andere wichtige Konfigurationen verantwortlich ist, eine privilegierte Rolle. Es ist von entscheidender Bedeutung, sicherzustellen, dass alle Einstellungen korrekt sind, da selbst die scheinbar trivialsten Versäumnisse zu erheblichen Verlusten führen können.

Tatsächlich kam es zu einem Vorfall, bei dem der Angreifer die Überprüfung des Übertragungsprotokolls aufgrund einer Fehlkonfiguration erfolgreich umging. Das Projektteam implementierte einige Tage vor dem Hack ein Protokoll-Update, bei dem eine Variable geändert wurde. Die Variable wurde verwendet, um den Standardwert der vertrauenswürdigen Nachricht darzustellen. Diese Änderung führte dazu, dass alle Nachrichten automatisch als getestet eingestuft wurden, sodass der Angreifer eine beliebige Nachricht senden und den Überprüfungsprozess bestehen konnte.

So verbessern Sie die Brückensicherheit

Die bisher erläuterten vier häufigsten Bridge-Schwachstellen veranschaulichen die Herausforderungen bei der Gewährleistung der Sicherheit in einem vernetzten Blockchain-Ökosystem. Für den Umgang mit jeder dieser Schwachstellen gibt es wichtige Überlegungen, und es gibt keine einfache Lösung, die für alle funktioniert.

Beispielsweise ist es schwierig, allgemeine Richtlinien zur Gewährleistung eines fehlerfreien Verifizierungsprozesses bereitzustellen, da für jede Brücke eigene Verifizierungsanforderungen gelten. Der effektivste Ansatz zur Verhinderung einer Umgehung der Verifizierung besteht darin, die Bridge gründlich auf potenzielle Angriffsvektoren zu testen und sicherzustellen, dass die Verifizierungslogik robust ist.

Kurz gesagt: Es ist wichtig, gründliche Tests gegen potenzielle Angriffe durchzuführen und den häufigsten Schwachstellen in der Bridge-Sicherheit besondere Aufmerksamkeit zu widmen.

Schlussfolgerungen

Aufgrund ihres hohen Wertes sind Cross-Chain-Brücken seit langem ein Angriffsziel. Entwickler können die Sicherheit ihrer Bridges erhöhen, indem sie umfangreiche Tests vor der Bereitstellung durchführen und sich an Audits durch Dritte beteiligen, wodurch das Risiko einer Wiederholung der verheerenden Hacks, die Bridges in den letzten Jahren heimgesucht haben, verringert wird. Bridges sind für die Multichain-Welt von entscheidender Bedeutung, aber beim Entwurf und Aufbau einer effektiven Web3-Infrastruktur muss die Sicherheit Priorität haben.

Weiterführende Literatur

Was ist eine Blockchain-Brücke?

Was ist kettenübergreifende Interoperabilität?

Drei beliebte Kryptobrücken und wie sie funktionieren

Was sind verpackte Token?

Rechtlicher Hinweis und Risikowarnung: Dieser Inhalt wird „wie besehen“ nur zu allgemeinen Informations- und Bildungszwecken präsentiert, ohne Zusicherungen oder Gewährleistungen jeglicher Art. Sie sind nicht als finanzielle, rechtliche oder sonstige professionelle Beratung zu verstehen und dienen auch nicht dazu, den Kauf eines bestimmten Produkts oder einer bestimmten Dienstleistung zu empfehlen. Lassen Sie sich individuell von geeigneten Fachberatern beraten. Da dieser Artikel von einem Dritten stammt, beachten Sie bitte, dass die geäußerten Meinungen die des Dritten sind und nicht unbedingt die Meinung der Binance Academy widerspiegeln. Weitere Informationen finden Sie hier in unserem vollständigen Impressum. Die Preise digitaler Vermögenswerte können volatil sein. Der Wert einer Anlage kann sowohl fallen als auch steigen, und es kann sein, dass Sie den investierten Betrag nicht zurückerhalten. Für Ihre Anlageentscheidungen sind allein Sie verantwortlich. Die Binance Academy übernimmt keine Haftung für etwaige Verluste, die Ihnen entstehen. Dieses Material sollte nicht als finanzielle, rechtliche oder sonstige professionelle Beratung ausgelegt werden. Weitere Informationen finden Sie in unseren Nutzungsbedingungen und Risikohinweisen.