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

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

TL;DR

Blockchain-Brücken sind entscheidend für die Interoperabilität im Blockchain-Bereich. Daher ist die Sicherheit der Brücke von größter Bedeutung. Einige häufige Sicherheitslücken bei Brücken sind schwache On-Chain- und Off-Chain-Validierung, unsachgemäßer Umgang mit nativen Token und Fehlkonfigurationen. Es wird empfohlen, die Brücke gegen alle möglichen Angriffsvektoren zu testen, um eine solide Verifizierungslogik sicherzustellen.

Einführung

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

Blockchain-Brücken sind für die Interoperabilität innerhalb des Blockchain-Raums von grundlegender Bedeutung. Sie funktionieren mithilfe verschiedener On-Chain- und Off-Chain-Validierungen und weisen daher unterschiedliche Sicherheitslücken auf.

Warum ist die Brückensicherheit so wichtig?

Eine Brücke enthält normalerweise das Token, das ein Benutzer von einer Kette auf eine andere übertragen möchte. Brücken werden oft als Smart Contracts eingesetzt und enthalten eine beträchtliche Menge an Token, da sich die kettenübergreifenden Übertragungen anhäufen, was sie zu lukrativen Zielen für Hacker macht.

Darüber hinaus bieten Blockchain-Brücken eine große Angriffsfläche, da sie aus vielen Komponenten bestehen. Vor diesem Hintergrund sind böswillige Akteure hoch motiviert, kettenübergreifende Anwendungen ins Visier zu nehmen, um große Geldsummen abzuschöpfen.

Brückenangriffe führten im Jahr 2022 zu Schäden von über 1,3 Milliarden USD, was nach Schätzungen von CertiK 36 % der Gesamtschäden des Jahres ausmachte.

Häufige Sicherheitslücken bei Bridge

Um die Sicherheit von Brücken zu verbessern, ist es wichtig, die üblichen Sicherheitslücken bei Brücken zu kennen und die Brücken vor dem Start auf diese zu testen. Diese Lücken 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 verlassen sich auf ein zentralisiertes Backend, um grundlegende Vorgänge wie Prägen, Brennen und Token-Übertragungen auszuführen, während alle Überprüfungen außerhalb der Kette durchgeführt werden.

Im Gegensatz dazu verwenden andere Arten von Brücken Smart Contracts, um Nachrichten zu validieren und Überprüfungen in der Kette durchzuführen. In diesem Szenario generiert der Smart Contract eine signierte Nachricht und gibt die Signatur in der Transaktion zurück, wenn ein Benutzer Geld in eine Kette einzahlt. Diese Signatur dient als Nachweis der Einzahlung und wird verwendet, um die Auszahlungsanforderung des Benutzers in der anderen Kette zu überprüfen. Dieser Prozess sollte in der Lage sein, verschiedene Sicherheitsangriffe zu verhindern, darunter Replay-Angriffe und gefälschte Einzahlungsdatensätze.

Wenn jedoch während des On-Chain-Validierungsprozesses eine Schwachstelle auftritt, kann der Angreifer schweren Schaden anrichten. Wenn eine Bridge beispielsweise einen Merkle-Baum zur Validierung des Transaktionsdatensatzes verwendet, kann ein Angreifer gefälschte Beweise generieren. Das bedeutet, dass er die Beweisvalidierung umgehen und neue Token auf sein Konto prägen kann, wenn der Validierungsprozess anfällig ist.

Bestimmte Brücken implementieren das Konzept „verpackter Token“. Wenn ein Benutzer beispielsweise DAI von Ethereum zur BNB-Kette überträgt, werden seine DAI aus dem Ethereum-Vertrag übernommen und eine entsprechende Menge an verpackten DAI wird auf der BNB-Kette ausgegeben.

Wenn diese Transaktion jedoch nicht ordnungsgemäß validiert wird, könnte ein Angreifer einen böswilligen Vertrag einsetzen, um die verpackten Token durch Manipulation der Funktion von der Brücke an eine falsche Adresse umzuleiten.

Die Angreifer benötigen außerdem die Zustimmung der Opfer zum Bridge-Vertrag, um mit der Funktion „transferFrom“ Token zu übertragen und so Vermögenswerte aus dem Bridge-Vertrag abzuziehen.

Leider wird dies noch dadurch verschlimmert, dass viele Brücken von DApp-Benutzern eine unbegrenzte Token-Genehmigung anfordern. 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 den Mangel an Validierung und die übermäßige Genehmigung ausnutzen, um Token von anderen Benutzern auf sich selbst zu übertragen.

Schwache Off-Chain-Validierung

In einigen Bridge-Systemen spielt der Off-Chain-Backend-Server eine entscheidende Rolle bei der Überprüfung der Legitimität von Nachrichten, die von der Blockchain gesendet werden. In diesem Fall 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 in der Quellkette einzuzahlen.

2. Die DApp sendet dann den Hash der Einzahlungstransaktion über eine API an den Backend-Server.

3. Der Transaktions-Hash wird vom Server mehreren Prüfungen unterzogen. Wenn er als legitim erachtet wird, signiert ein Unterzeichner eine 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 ermöglicht dem Benutzer, seine Token aus der Quellkette abzuheben.

Der Backend-Server muss sicherstellen, dass die von ihm verarbeitete Einzahlungstransaktion tatsächlich stattgefunden hat und nicht gefälscht wurde. Dieser Backend-Server bestimmt, ob ein Benutzer Token auf der Zielkette abheben kann und ist daher ein wertvolles Ziel für Angreifer.

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

Wenn der Backend-Server nicht überprüft, welche Adresse das Ereignis gesendet hat, betrachtet er dies als gültige Transaktion und signiert die Nachricht. Der Angreifer könnte dann den Transaktions-Hash an das Backend senden, die Überprüfung umgehen und die Token aus der Zielkette abheben.

Unsachgemäßer Umgang mit nativen Token

Brücken verfolgen unterschiedliche Ansätze beim 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 seine ETH auf eine andere Kette übertragen möchte, muss er sie zunächst in den Bridge-Vertrag einzahlen. Dazu hängt der Benutzer die ETH einfach an die Transaktion an und der ETH-Betrag kann durch Lesen des Felds „msg.value“ der Transaktion abgerufen werden.

Das Einzahlen von ERC-20-Token unterscheidet sich erheblich vom Einzahlen von ETH. Um ein ERC-20-Token einzuzahlen, muss der Benutzer dem Bridge-Vertrag zunächst erlauben, seine Token auszugeben. Nachdem er dies genehmigt und die Token in den Bridge-Vertrag eingezahlt hat, verbrennt 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, dies zu differenzieren, besteht darin, eine if-else-Anweisung innerhalb derselben Funktion zu verwenden. Ein anderer Ansatz besteht darin, zwei separate Funktionen zu erstellen, um jedes Szenario abzudecken. Der Versuch, ETH mit der ERC-20-Einzahlungsfunktion einzuzahlen, kann zum Verlust dieser Mittel führen.

Bei der Bearbeitung von ERC-20-Einzahlungsanforderungen geben Benutzer normalerweise die Token-Adresse als Eingabe für die Einzahlungsfunktion an. Dies stellt ein erhebliches Risiko dar, da während der Transaktion nicht vertrauenswürdige externe Aufrufe auftreten können. Die Implementierung einer Whitelist, die nur die von der Bridge unterstützten Token enthält, ist eine gängige Vorgehensweise zur Risikominimierung. Nur auf der Whitelist aufgeführte Adressen dürfen als Argumente übergeben werden. Dies verhindert externe Aufrufe, da das Projektteam die Token-Adresse bereits gefiltert hat.

Es können jedoch auch Probleme auftreten, wenn Bridges native Token-Cross-Chain-Übertragungen verarbeiten, da das native Token keine Adresse hat. Eine Nulladresse (0x000...0) repräsentiert das native Token. Dies kann problematisch sein, da die Übergabe der Nulladresse an die Funktion die Whitelist-Verifizierung umgehen kann, selbst wenn sie falsch implementiert ist.

Wenn der Bridge-Vertrag „transferFrom“ aufruft, um Benutzervermögen an den Vertrag zu übertragen, gibt der externe Aufruf der Nulladresse „false“ zurück, da in der Nulladresse keine „transferFrom“-Funktion implementiert ist. Die Transaktion kann jedoch dennoch erfolgen, wenn der Vertrag den Rückgabewert nicht entsprechend verarbeitet. Dies bietet Angreifern die Möglichkeit, die Transaktion auszuführen, ohne Token an den Vertrag zu übertragen.

Fehlkonfiguration

In den meisten Blockchain-Brücken ist eine privilegierte Rolle für das Whitelisting oder Blacklisting von Token und Adressen, das Zuweisen oder Ändern von Unterzeichnern und andere kritische Konfigurationen verantwortlich. Es ist von entscheidender Bedeutung, sicherzustellen, dass alle Konfigurationen korrekt sind, da selbst scheinbar unbedeutende Versehen zu erheblichen Verlusten führen können.

Tatsächlich gab es einen Vorfall, bei dem der Angreifer die Überprüfung des Übertragungsdatensatzes aufgrund einer Fehlkonfiguration erfolgreich umging. Das Projektteam führte einige Tage vor dem Hack ein Protokoll-Upgrade durch, 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 bestätigt galten, sodass ein Angreifer eine beliebige Nachricht senden und den Überprüfungsprozess umgehen konnte.

So verbessern Sie die Brückensicherheit

Die oben erläuterten vier häufigen Brückenschwachstellen veranschaulichen die Herausforderungen bei der Gewährleistung der Sicherheit in einem vernetzten Blockchain-Ökosystem. Bei der Handhabung jeder dieser Schwachstellen sind wichtige Überlegungen anzustellen, und es gibt kein einheitliches Spielbuch, das auf alle Schwachstellen anwendbar ist.

Beispielsweise ist es schwierig, allgemeine Richtlinien für einen fehlerfreien Verifizierungsprozess bereitzustellen, da jede Brücke einzigartige Verifizierungsanforderungen hat. Der effektivste Ansatz, um eine Umgehung der Verifizierung zu verhindern, besteht darin, die Brücke gründlich auf alle möglichen Angriffsmethoden zu testen und sicherzustellen, dass die Verifizierungslogik einwandfrei ist.

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

Abschließende Gedanken 

Aufgrund ihres hohen Wertes sind Cross-Chain-Brücken seit langem ein Ziel für Angreifer. Erbauer können die Sicherheit ihrer Brücken stärken, indem sie vor der Bereitstellung gründliche Tests durchführen und Audits durch Dritte durchführen. So verringern sie das Risiko der verheerenden Hackerangriffe, die Brücken in den letzten Jahren heimgesucht haben. Brücken sind in einer Multi-Chain-Welt von entscheidender Bedeutung, aber bei der Entwicklung und dem Aufbau einer effektiven Web3-Infrastruktur muss die Sicherheit ein Hauptanliegen sein.

Weitere Informationen

Was ist eine Blockchain-Brücke?

Was ist kettenübergreifende Interoperabilität?

Drei beliebte Kryptobrücken und wie sie funktionieren

Was sind Wrapped Tokens?

Haftungsausschluss und Risikowarnung: Dieser Inhalt wird Ihnen „wie besehen“ nur zu allgemeinen Informations- und Bildungszwecken präsentiert, ohne Zusicherung oder Gewährleistung jeglicher Art. Er sollte nicht als finanzieller, rechtlicher oder sonstiger professioneller Rat ausgelegt werden, noch ist er als Kaufempfehlung für ein bestimmtes Produkt oder eine bestimmte Dienstleistung gedacht. Sie sollten Ihren eigenen Rat bei geeigneten professionellen Beratern einholen. Wenn der Artikel von einem externen Beitragsautor beigesteuert wird, beachten Sie bitte, dass die geäußerten Ansichten dem externen Beitragsautor gehören und nicht unbedingt denen von Binance Academy entsprechen. Bitte lesen Sie hier unseren vollständigen Haftungsausschluss für weitere Einzelheiten. Die Preise digitaler Vermögenswerte können volatil sein. Der Wert Ihrer Investition kann fallen oder steigen, und Sie erhalten möglicherweise nicht den investierten Betrag zurück. Sie sind allein für Ihre Investitionsentscheidungen verantwortlich, und Binance Academy haftet nicht für etwaige Verluste, die Ihnen entstehen können. Dieses Material sollte nicht als finanzieller, rechtlicher oder sonstiger professioneller Rat ausgelegt werden. Weitere Informationen finden Sie in unseren Nutzungsbedingungen und Risikowarnungen.