Dieser Artikel ist ein Beitrag der Community. Der Autor ist Minzhi He, 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.

In Kürze

Blockchain-Brücken sind die Grundlage für die Erreichung der Interoperabilität im Blockchain-Bereich. Daher ist die Sicherung von Brücken sehr wichtig. Zu den häufigsten Sicherheitslücken bei Bridges gehören eine schwache On-Chain- und Off-Chain-Authentifizierung, unsachgemäße Handhabung nativer Token und Fehlkonfigurationen. Die Bridge sollte getestet werden, um sicherzustellen, dass sie allen Angriffsvektoren standhält und eine ordnungsgemäße Verifizierungslogik gewährleistet ist.

Einführen

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

Blockchain-Brücken sind von grundlegender Bedeutung für die Erreichung der Interoperabilität im Blockchain-Bereich. Sie arbeiten mit unterschiedlichen On-Chain- und Off-Chain-Authentifizierungen und weisen daher unterschiedliche Sicherheitslücken auf.

Warum ist Brückensicherheit wichtig?

Bridges enthalten normalerweise Token, die Benutzer von einer Kette auf eine andere übertragen möchten. Bridges werden oft als Smart Contracts eingesetzt und halten eine beträchtliche Menge an Token bereit, da 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 aus vielen Komponenten bestehen. Aufgrund dieser Natur sind böswillige Akteure hochmotiviert, kettenübergreifende Anwendungen anzugreifen, um große Geldsummen abzuheben.

Schätzungen von CertiK zufolge führen Bridge-Angriffe im Jahr 2022 zu Verlusten von mehr als 1,3 Milliarden US-Dollar, was 36 % der Gesamtverluste des Jahres ausmacht.

Häufige Sicherheitslücken bei Bridges

Um die Bridge-Sicherheit zu verbessern, ist es wichtig, häufige Bridge-Schwachstellen zu verstehen und Bridges vor dem Start zu testen. Diese Schwachstellen können wie folgt in vier Typen eingeteilt werden.

Schwache On-Chain-Authentifizierung

Bei einfachen Brücken, insbesondere solchen, die für bestimmte DApps entwickelt wurden, ist die On-Chain-Validierung oft minimal. Diese Brücken basieren auf einem zentralen Backend, um grundlegende Vorgänge wie das Prägen, Brennen und Übertragen von Token durchzufü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 in diesem Fall ein Benutzer 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 verwendet, um die Auszahlungsanforderung eines Benutzers in einer anderen Kette zu überprüfen. Dieser Prozess wird in der Lage sein, verschiedene Sicherheitsangriffe zu verhindern, darunter Replay-Angriffe und gefälschte Einzahlungsaufzeichnungen.

Wenn es jedoch Schwachstellen im On-Chain-Authentifizierungsprozess gibt, kann ein Angreifer ernsthaften Schaden anrichten. Wenn eine Bridge beispielsweise einen Merkle-Baum zur Authentifizierung von Transaktionsdatensätzen verwendet, könnte ein Angreifer manipulierte Beweise erstellen. Dies bedeutet, dass sie die Proof-Authentifizierung umgehen und neue Token in ihre Konten einprägen können, wenn der Authentifizierungsprozess anfällig ist.

Einige Brücken implementieren das Konzept der „verpackten Token“. Wenn ein Benutzer beispielsweise DAI von Ethereum zur BNB-Kette überträgt, wird sein DAI aus dem Ethereum-Vertrag entnommen und eine entsprechende Menge verpackter DAI wird auf der BNB-Kette freigegeben.

Wenn diese Transaktion jedoch nicht ordnungsgemäß authentifiziert ist, kann ein Angreifer einen böswilligen Vertrag einsetzen, um verpackte Token von der Bridge an eine falsche Adresse weiterzuleiten, indem er die Funktionalität manipuliert.

Die Angreifer benötigen außerdem die Zustimmung des Opfers zum Überbrückungsvertrag, um die Token mithilfe der Funktion „transferFrom“ zu übertragen, um Vermögenswerte aus dem Überbrückungsvertrag abzuheben.

Leider wird die Situation noch schlimmer, da viele Bridges eine unbegrenzte Token-Genehmigung von DApp-Benutzern erfordern. Dies ist eine beliebte Methode, die die Gasgebühren senkt, aber zusätzliche Risiken birgt, da der Smart-Vertrag auf eine unbegrenzte Anzahl von Token aus der Brieftasche des Benutzers zugreifen kann. Angreifer können fehlende Authentifizierung und übermäßige Genehmigungen ausnutzen, um Token von anderen Benutzern an diese zu übertragen.

Schwache Off-Chain-Authentifizierung

In einigen Brückensystemen spielen Off-Chain-Backend-Server eine wichtige 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-Authentifizierung funktioniert wie folgt:

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

2. Diese DApp sendet dann den Hash-String der Einzahlungstransaktion über die API an den Backend-Server.

3. Der Transaktions-Hash-String unterliegt einer Servervalidierung. Wenn er als legitim erachtet wird, signiert der Unterzeichner eine Nachricht und sendet die Signatur über die API an die Benutzeroberfläche zurück.

4. Nach Erhalt einer Signatur überprüft die DApp diese und ermöglicht Benutzern, ihre Token aus der Zielkette abzuheben.

Der Backend-Server muss sicherstellen, dass die von ihm verarbeitete Einzahlungstransaktion tatsächlich stattgefunden hat und nicht manipuliert wurde. Dieser Backend-Server bestimmt, ob Benutzer Token auf der Zielkette abheben können und ist daher ein hochwertiges 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. Wenn letzteres ignoriert wird, kann ein Angreifer einen böswilligen Vertrag einsetzen, um ein Einzahlungsereignis mit derselben Struktur wie ein legitimes Einzahlungsereignis vorzutäuschen.

Wenn der Backend-Server nicht überprüft, welche Adresse das Ereignis ausgegeben hat, betrachtet er dies als gültige Transaktion und signiert die Nachricht. Der Angreifer kann dann den Transaktions-Hash an das Backend senden, die Überprüfung umgehen und es ihm ermöglichen, Token aus der Zielkette abzuheben.

Unsachgemäßer Umgang mit nativen Token

Bridges haben unterschiedliche Ansätze für den Umgang mit nativen Token und Utility-Token. Im Ethereum-Netzwerk sind beispielsweise die nativen Token ETH und die meisten Utility-Token entsprechen dem ERC-20-Standard.

Wenn Benutzer beabsichtigen, ihre ETH auf eine andere Kette zu übertragen, müssen sie diese zunächst im Brückenvertrag hinterlegen. Um dies zu erreichen, müssen Benutzer lediglich ETH an die Transaktion anhängen und den ETH-Betrag erhalten, indem sie das Feld „msg.value“ der Transaktion lesen.

Das Senden von ERC-20-Tokens unterscheidet sich erheblich vom Senden von ETH. Um einen ERC-20-Token einzuzahlen, müssen Benutzer zunächst den Brückenvertrag autorisieren, ihre Token auszugeben. Sobald sie dies genehmigt und die Token im Überbrückungsvertrag hinterlegt haben, 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, eine if-else-Anweisung innerhalb derselben Funktion zu verwenden. Ein anderer Ansatz besteht darin, zwei separate Funktionen zu erstellen, um jede Situation zu bewältigen. Der Versuch, ETH über die ERC-20-Einzahlungsfunktion einzuzahlen, kann zum Verlust dieser Gelder führen.

Bei der Bearbeitung von ERC-20-Einzahlungsanfragen geben Benutzer normalerweise Token-Adressen als Eingabe für die Einzahlungsfunktion an. Dies stellt ein erhebliches Risiko dar, da es während der Transaktion zu nicht vertrauenswürdigen externen Anrufen kommen kann. Die Implementierung einer Whitelist, die nur von der Bridge unterstützte Token enthält, ist eine beliebte Methode zur Risikominderung. Als Argumente dürfen nur Adressen auf der Whitelist übergeben werden. Dies verhindert externe Aufrufe, da das Projektteam Token-Adressen gefiltert hat.

Allerdings kann es auch zu Problemen kommen, wenn Bridges kettenübergreifende Übertragungen nativer Token abwickeln, da native Token keine Adresse haben. Die Adressnummer 0 (0x000...0) repräsentiert den ursprünglichen Token. Dies kann problematisch sein, da die Übergabe der Adresse 0 an eine Funktion die Whitelist-Verifizierung umgehen kann, selbst wenn sie falsch 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 in Adresse Null keine „transferFrom“-Funktion implementiert ist. Die Transaktion kann jedoch trotzdem stattfinden, wenn der Vertrag den Rückgabewert nicht ordnungsgemäß verarbeitet. Dies bietet Angreifern die Möglichkeit, Transaktionen durchzuführen, ohne Token in den Vertrag zu übertragen.

Falsche Konfiguration

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 wichtige Konfigurationen verantwortlich. Es ist von entscheidender Bedeutung, sicherzustellen, dass alle Konfigurationen korrekt sind, da selbst scheinbar kleine Fehler zu erheblichen Verlusten führen können.

Tatsächlich gab es ein Problem, bei dem ein Angreifer die Überprüfung des Übertragungsdatensatzes aufgrund einer Fehlkonfiguration erfolgreich umgangen hat. Das Projektteam führte einige Tage vor dem Hack ein Protokoll-Upgrade durch, bei dem eine Variable geändert wurde. Variable, die den Standardwert einer vertrauenswürdigen Nachricht darstellt. Diese Änderung führt dazu, dass alle Nachrichten automatisch als bestätigt gelten, sodass ein Angreifer eine beliebige Nachricht senden und den Überprüfungsprozess umgehen kann.

So verbessern Sie die Brückensicherheit

Die vier oben erläuterten häufigen Bridging-Schwachstellen verdeutlichen die Herausforderungen bei der Gewährleistung der Sicherheit in einem vernetzten Blockchain-Ökosystem. Für die Behebung jeder dieser Schwachstellen gibt es wichtige Überlegungen, und es gibt kein einheitliches Regelwerk, das für alle gilt.

Beispielsweise ist die Bereitstellung allgemeiner Richtlinien zur Gewährleistung eines fehlerfreien Verifizierungsprozesses eine Herausforderung, da jede Brücke ihre eigenen Verifizierungsanforderungen hat. Der effektivste Ansatz zur Verhinderung einer Umgehung der Verifizierung besteht darin, die Bridge gründlich gegen alle möglichen Angriffsvektoren zu testen und eine ordnungsgemäße Verifizierungslogik sicherzustellen.

Zusammenfassend lässt sich sagen, dass es wichtig ist, strenge Tests gegen potenzielle Angriffe durchzuführen und den häufigsten Sicherheitslücken bei Bridges besondere Aufmerksamkeit zu schenken.

Zusammenfassung

Aufgrund ihres hohen Werts sind Cross-Chain-Brücken seit langem ein Ziel für Angreifer. Entwickler können die Sicherheit ihrer Bridges erhöhen, indem sie vor der Bereitstellung gründliche Tests durchführen und sich an der Prüfung durch Dritte beteiligen, um das Risiko verheerender Angriffe zu verringern, die Bridges in den letzten Jahren heimgesucht haben. Bridges sind sehr wichtige Komponenten in einer Multi-Chain-Welt, aber Sicherheit muss beim Entwurf und Aufbau einer effektiven Web3-Infrastruktur oberste Priorität haben.

Mehr lesen:

Was ist eine Blockchain-Brücke?

Was ist kettenübergreifende Interoperabilität?

Drei beliebte Kryptowährungsbrü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. Sie sind weder als finanzielle, rechtliche oder sonstige professionelle Beratung zu verstehen, noch sind sie als Empfehlung zum Kauf eines bestimmten Produkts oder einer bestimmten Dienstleistung gedacht. Sie sollten sich selbst von geeigneten Fachberatern beraten lassen. In Fällen, in denen Artikel von Drittautoren beigesteuert werden, beachten Sie bitte, dass die geäußerten Ansichten dem Drittautor gehören 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 schwanken. Der Wert Ihrer Investition kann sowohl fallen als auch steigen und Sie erhalten möglicherweise nicht den investierten Betrag zurück. Sie allein sind für Ihre Anlageentscheidungen verantwortlich und Binance Academy haftet nicht 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.