Welches sind h├Ąufige Sicherheitsl├╝cken von Blockchain-Br├╝cken?
Startseite
Artikel
Welches sind h├Ąufige Sicherheitsl├╝cken von Blockchain-Br├╝cken?

Welches sind h├Ąufige Sicherheitsl├╝cken von Blockchain-Br├╝cken?

Fortgeschritten
Ver├Âffentlicht Mar 22, 2023Aktualisiert Jun 15, 2023
9m

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

Die Ansichten in diesem Artikel sind die des Verfassers und entsprechen m├Âglicherweise nicht denen der Binance Academy.

TL;DR

Blockchain-Br├╝cken sind f├╝r die Interoperabilit├Ąt von Blockchains unerl├Ąsslich. Oft weisen sie jedoch Sicherheitsl├╝cken auf. Zu den h├Ąufigsten geh├Âren eine unzureichende On-Chain- und Off-Chain-Validierung, Fehler bei der Abwicklung nativer Tokens und fehlerhafte Br├╝cken-Konfigurationen. Es ist daher enorm wichtig, Blockchain-Br├╝cken auf alle m├Âglichen Arten von Angriffen zu testen und dabei sicherzustellen, dass die Pr├╝flogik stimmt.

Einführung 

Eine Blockchain-Br├╝cke (Englisch: ÔÇ×Blockhain bridgeÔÇť oder ÔÇ×Crypto bridgeÔÇť) ist ein Protokoll, das zwei Blockchains miteinander verbindet, um Interaktionen zwischen ihnen zu erm├Âglichen. Wer Bitcoins besitzt und sich an DeFi-Aktivit├Ąten im Ethereum-Netzwerk beteiligen m├Âchte, kann dies mittels einer Blockchain-Br├╝cke tun, ohne seine Bitcoins verkaufen zu m├╝ssen.┬á

Blockchain-Br├╝cken sind von grundlegender Bedeutung f├╝r die Interoperabilit├Ąt innerhalb des Blockchain-├ľkosystems. Da sie jedoch mit mehreren On-Chain- und Off-Chain-Validierungen arbeiten, weisen sie verschiedene Schwachstellen auf.

Warum die Gew├Ąhrleistung der Sicherheit von Blockchain-Br├╝cken so wichtig ist┬á

Blockchain-Br├╝cken, die h├Ąufig in Form von Smart Contracts implementiert werden, speichern in der Regel die Tokens, die Nutzer von einer Blockchain auf eine andere ├╝bertragen m├Âchten. Sie halten eine betr├Ąchtliche Menge an Tokens aus verschiedenen Cross-Chain-Transaktionen, was sie zu lukrativen Zielen f├╝r Hacker macht.┬á

Dar├╝ber hinaus bieten Blockchain-Br├╝cken aufgrund ihrer vielen Komponenten eine gro├če Angriffsfl├Ąche. Daher sind Cross-Chain-Anwendungen ein beliebtes Ziel f├╝r Hacker, die mit einem einzigen Angriff eine gro├če Menge an Kryptow├Ąhrungen erbeuten wollen.┬á

Gem├Ą├č den Sch├Ątzungen von CertiK waren 2022 mehr als 1,3 Mrd. USD an Verlusten auf die Angriffe auf Blockchain-Br├╝cken zur├╝ckzuf├╝hren, was 36% der Gesamtverluste des Jahres ausmachte.┬á

H├Ąufige Sicherheitsl├╝cken von Blockchain-Br├╝cken

Um die Sicherheit von Blockchain-Br├╝cken zu verbessern, ist es wichtig, die gr├Â├čten Schwachstellen zu identifizieren und die Protokolle vor der Einf├╝hrung entsprechend zu testen. Die h├Ąufigsten Sicherheitsl├╝cken lassen sich vier Bereichen zuordnen:┬á

Unzureichende On-Chain-Validierung

Bei einfachen Blockchain-Br├╝cken, insbesondere solchen, die f├╝r bestimmte dApps entwickelt wurden, ist die On-Chain-Validierung auf ein Minimum beschr├Ąnkt. Diese Br├╝cken nutzen ein zentrales Backend, um grundlegende Operationen wie Minting, Burning und Token-Transfers auszuf├╝hren, aber die gesamte Validierung erfolgt au├čerhalb der Blockchain.

Andere Blockchain-Br├╝cken verwenden hingegen Smart Contracts, um Nachrichten zu validieren und On-Chain-Verifizierungen durchzuf├╝hren. Wenn ein Nutzer Mittel auf eine Blockchain einzahlt, generiert der Smart Contract eine signierte Nachricht und f├╝gt die Signatur in die Transaktion ein. Diese Signatur dient als Beweis f├╝r die Einzahlung und wird zur Verifizierung des Auszahlungsantrags auf der anderen Blockchain verwendet. Solche Br├╝cken sollten in der Lage sein, verschiedene Arten von Angriffen zu erkennen und zu verhindern, darunter gef├Ąlschte Einzahlungsbelege und Replay-Angriffe.┬á

Weist der On-Chain-Validierungsprozess jedoch eine Sicherheitsl├╝cke auf, kann ein Hacker auch hier schweren Schaden anrichten. In dem Fall, dass eine Br├╝cke den Merkle-Baum f├╝r die Validierung des Transaktionsdatensatzes nutzt, k├Ânnte ein Angreifer Beweise f├Ąlschen. Er w├Ąre nun in der Lage, die Beweisvalidierung zu umgehen und neue Tokens in seinem Konto zu erstellen.

Bestimmte Blockchain-Br├╝cken verwenden sogenannte Wrapped Tokens. Wenn ein Nutzer beispielsweise DAI von Ethereum auf die BNB Chain ├╝bertr├Ągt, werden seine DAI-Coins aus dem Ethereum-Kontrakt entnommen, und eine entsprechende Menge an Wrapped-DAI wird auf der BNB Chain ausgegeben.┬á

Wird diese Transaktion jedoch nicht ordnungsgem├Ą├č validiert, k├Ânnte ein Angreifer einen b├Âsartigen Kontrakt einsetzen, um die Wrapped Tokens von der Br├╝cke an eine falsche Adresse zu leiten, indem er die Funktion manipuliert.┬á

Angreifer ben├Âtigen au├čerdem die Genehmigung des Br├╝ckenkontrakts durch das Opfer, um Tokens mit der Funktion ÔÇ×transferFromÔÇť ├╝bertragen und vom Br├╝ckenkontrakt abziehen zu k├Ânnen.┬á

Da hilft es nicht, dass viele Blockchain-Br├╝cken von dApp-Nutzern leider eine generelle Einwilligung f├╝r Token-Transfers verlangen. Dies ist eine g├Ąngige Praxis, die zwar niedrigere Gasgeb├╝hren erm├Âglicht, aber zus├Ątzliche Risiken mit sich bringt, da der Smart Contract dann auf eine unbegrenzte Anzahl von Tokens aus der Wallet des Nutzers zugreifen kann. Angreifer k├Ânnen die Sicherheitsm├Ąngel der fehlenden Validierung und der generellen Einwilligung f├╝r Token-Transfers ausnutzen, um die Kryptow├Ąhrungen anderer Nutzer auf ihre eigene Wallet zu ├╝bertragen.

Unzureichende Off-Chain-Validierung

In einigen Br├╝ckensystemen spielt der Off-Chain-Backend-Server eine entscheidende Rolle bei der Verifizierung der Legitimit├Ąt von Nachrichten, die von der Blockchain gesendet werden. Dies soll hier am Beispiel der Verifizierung von Einzahlungen aufgezeigt werden.┬á

Eine Blockchain-Br├╝cke mit Off-Chain-Validierung arbeitet folgenderma├čen:┬á

  1. Nutzer interagieren mit der dApp, um Tokens in den Smart Contract auf die Ursprungs-Blockchain zu ├╝bertragen.

  2. Die dApp sendet den Hash der Einzahlung ├╝ber eine API an den Backend-Server.

  3. Der Hash wird vom Server mehrfach ├╝berpr├╝ft. Wenn er als legitim erachtet wird, signiert ein Unterzeichner eine Nachricht und sendet die Signatur ├╝ber die API zur├╝ck an die Nutzeroberfl├Ąche.

  4. Die dApp verifiziert die Signatur und erlaubt dem Nutzer, seine Tokens von der Ursprungs-Blockchain auszuzahlen.

Der Backend-Server muss sicherstellen, dass die von ihm verarbeitete Einzahlung tats├Ąchlich erfolgt ist und es sich nicht um eine F├Ąlschung handelt. Er entscheidet, ob ein Nutzer Tokens von der Ursprungs-Blockchain auszahlen lassen kann, und ist daher ein attraktives Ziel f├╝r Angreifer.

Der Backend-Server muss die Struktur des durch die Transaktion ausgel├Âsten Ereignisses sowie die Kontraktadresse, die das Ereignis ausgel├Âst hat, validieren. Wird letzteres vernachl├Ąssigt, k├Ânnte ein Angreifer einen b├Âsartigen Kontrakt implementieren, um eine Einzahlung zu f├Ąlschen, die die gleiche Struktur wie eine legitime Einzahlung aufweist.┬á

Wenn der Backend-Server nicht ├╝berpr├╝ft, von welcher Adresse das Ereignis ausging, w├╝rde er die Transaktion als g├╝ltig betrachten und die Nachricht signieren. Der Angreifer k├Ânnte dann den Transaktions-Hash an den Backend-Server senden, um die Verifizierung zu umgehen und die Tokens von der Ursprungs-Blockchain abzuziehen.

Fehler bei der Abwicklung nativer Tokens

Blockchain-Br├╝cken implementieren unterschiedliche Ans├Ątze f├╝r native Tokens und Utility-Tokens, um Cross-Chain-Transfers durchzuf├╝hren. Zum Beispiel ist im Ethereum-Netzwerk ETH der native Coin, w├Ąhrend die meisten Utility-Tokens dem ERC-20-Standard folgen.┬á

Wenn ein Nutzer seine ETH auf eine andere Blockchain ├╝bertragen m├Âchte, muss er sie zun├Ąchst in den Br├╝ckenkontrakt einzahlen. Dazu f├╝gt er die Coins einfach an die Transaktion an. Der ETH-Betrag kann durch Abfragen des Transaktionsfeldes ÔÇ×msg.valueÔÇť abgerufen werden.

Der Einzahlungsprozess f├╝r ERC-20-Tokens unterscheidet sich erheblich von dem f├╝r ETH. Um einen ERC-20-Token auf eine andere Blockchain zu ├╝bertragen, muss der Nutzer dem Br├╝ckenkontrakt zuerst die Auszahlung seiner Tokens erlauben. Nachdem er dies genehmigt und die Tokens in den Br├╝ckenkontrakt eingezahlt hat, vernichtet der Kontrakt entweder die Tokens des Nutzers mit der Funktion ÔÇ×burnFrom()ÔÇť oder er ├╝bertr├Ągt sie mit der Funktion ÔÇ×transferFrom()ÔÇť auf sich selbst.┬á

Eine M├Âglichkeit, dies zu tun, ist die Verwendung einer ÔÇ×if-elseÔÇť-Anweisung innerhalb derselben Funktion. Eine andere M├Âglichkeit besteht darin, zwei separate Funktionen ÔÇô eine f├╝r jedes Szenario ÔÇô zu erstellen. Der Versuch, ETH ├╝ber die ERC-20-Einzahlungsfunktion einzuzahlen, kann zum Verlust der Mittel f├╝hren.

Im Rahmen der Verarbeitung von ERC-20-Einzahlungsanfragen geben die Nutzer in der Regel die Token-Adresse als Input f├╝r die Einzahlungsfunktion an. Dies stellt ein erhebliches Risiko dar, da w├Ąhrend der Transaktion ein externer Aufruf von einer nicht vertrauensw├╝rdigen Partei erfolgen kann. Eine g├Ąngige Praxis zur Risikominderung ist die Implementierung einer Whitelist, in die nur die von der Blockchain-Br├╝cke unterst├╝tzten Tokens aufgenommen werden. Nur auf der Whitelist stehende Adressen d├╝rfen als Argumente ├╝bermittelt werden. Durch dieses gezielte Herausfiltern von Token-Adressen durch das Projektteam k├Ânnen externe Aufrufe vermieden werden.

Ein weiteres Problem ergibt sich bei Cross-Chain-Transfers von ETH, da der native Token von Ethereum keine normale Adresse, sondern nur eine Nulladresse (0x000...0) besitzt. Dies ist insofern gef├Ąhrlich, als durch die ├ťbermittlung der Nulladresse an die Funktion die Whitelist-Pr├╝fung umgangen werden kann, selbst wenn diese falsch implementiert wurde.┬á

Wenn der Br├╝ckenkontrakt die Funktion ÔÇ×transferFromÔÇť aufruft, um Nutzerguthaben auf den Kontrakt zu ├╝bertragen, ergibt der externe Aufruf ÔÇ×falseÔÇť, da in der Nulladresse keine Funktion ÔÇ×transferFromÔÇť implementiert ist. Die Transaktion kann jedoch trotzdem erfolgen, wenn der Kontrakt den R├╝ckgabewert nicht angemessen handhabt. In diesem Fall haben Angreifer die M├Âglichkeit, die Transaktion auszuf├╝hren, ohne jemals irgendwelche Tokens an den Kontrakt zu ├╝bertragen.

Fehlerhafte Br├╝cken-Konfigurationen

Das Whitelisting oder Blacklisting von Tokens und Adressen, die Zuweisung oder ├änderung von Unterzeichnern und weitere grundlegende Konfigurationen sind von entscheidender Bedeutung f├╝r die Sicherheit einer Blockchain-Br├╝cke. Alle Konfigurationen m├╝ssen korrekt sein, da selbst scheinbar triviale Vers├Ąumnisse zu erheblichen Verlusten von Mitteln der Nutzer f├╝hren k├Ânnen.

In der Tat gab es einen Vorfall, bei dem ein Angreifer aufgrund einer fehlerhaften Konfiguration die Pr├╝fung der Transferaufzeichnungen erfolgreich passieren konnte. Das Projektteam f├╝hrte einige Tage vor dem Hack ein Protokoll-Upgrade durch, bei dem eine Variable ge├Ąndert wurde, die den Standardwert der vertrauensw├╝rdigen Nachricht darstellte. Diese ├änderung f├╝hrte dazu, dass alle Nachrichten automatisch als verifiziert galten, sodass ein Angreifer eine beliebige Nachricht ├╝bermitteln und den Verifizierungsprozess umgehen konnte.

Wie sich die Sicherheit von Blockchain-Br├╝cken verbessern l├Ąsst

Die vier beschriebenen Schwachstellen von Blockchain-Br├╝cken zeigen die Herausforderungen im Hinblick auf den Schutz der Kryptow├Ąhrungen der Nutzer in einem vernetzten Blockchain-├ľkosystem. F├╝r die Behebung solcher Sicherheitsl├╝cken gibt es keine Universall├Âsung, sondern es jeder Fall muss individuell betrachtet werden.┬á

So ist es beispielsweise schwierig, allgemeine Richtlinien f├╝r einen fehlerfreien Verifizierungsprozess zu erstellen, da jede Br├╝cke eigene Pr├╝fanforderungen hat. Die wirksamste Methode zur Verhinderung einer Umgehung der Verifizierung ist, die Br├╝cke umfassend auf alle m├Âglichen Arten von Angriffen zu testen und sicherzustellen, dass die Pr├╝flogik stimmt.┬á

Zusammenfassend l├Ąsst sich sagen, dass es unerl├Ąsslich ist, rigorose Tests auf potenzielle Angriffe durchzuf├╝hren und dabei den Fokus besonders auf die h├Ąufigsten Sicherheitsl├╝cken von Blockchain-Br├╝cken zu legen.┬á┬á

Abschie├čende Gedanken┬á

Aufgrund der gro├čen Menge an Kryptow├Ąhrungen, die in einer Cross-Chain-Br├╝cke gespeichert sein k├Ânnen, sind diese seit langem ein Ziel f├╝r Angreifer. Durch umfassende Tests vor der Implementierung und Audits durch Dritte kann die Sicherheit von Blockchain-Br├╝cken erh├Âht und damit das Risiko verheerender Hacks, von denen die Br├╝cken in den letzten Jahren immer wieder betroffen waren, verringert werden. In einer Multi-Blockchain-Welt sind Blockchain-Br├╝cken unverzichtbar, aber die Sicherheit muss beim Aufbau einer zuverl├Ąssigen Web3-Infrastruktur an erster Stelle stehen.

Weiterf├╝hrende Lekt├╝re

Was ist eine Blockchain-Br├╝cke?

Was ist Cross-Chain-Interoperabilit├Ąt?

Drei beliebte Blockchain-Br├╝cken und deren Funktionsweise

Was sind Wrapped Tokens?

Haftungsausschluss und Risikohinweis: Dieser Inhalt wird dir zu allgemeinen Informations- und Bildungszwecken pr├Ąsentiert, ohne jegliche Zusicherung oder Garantie. Er ist weder als finanzielle, rechtliche oder sonstige professionelle Beratung noch als Empfehlung f├╝r den Kauf bestimmter Produkte oder Dienstleistungen zu verstehen. Du solltest deinen eigenen Rat von geeigneten professionellen Beratern einholen. Wenn der Artikel von einem Drittanbieter beigetragen wird, beachte bitte, dass die ge├Ąu├čerten Ansichten diejenigen des Drittanbieters sind und nicht unbedingt die der Binance Academy widerspiegeln. Bitte lies hier unseren vollst├Ąndigen Haftungsausschluss f├╝r weitere Details. Die Preise f├╝r Kryptow├Ąhrungen sind volatil. Der Wert deiner Anlage kann steigen oder fallen, und es kann sein, dass du den investierten Betrag nicht zur├╝ckerh├Ąltst. Die Verantwortung f├╝r deine Anlageentscheidungen liegt allein bei dir. Die Binance Academy haftet nicht f├╝r etwaige Verluste, die du erleidest. Dieses Material sollte nicht als finanzielle, rechtliche oder sonstige professionelle Beratung ausgelegt werden. Weitere Informationen findest du in unseren Nutzungsbedingungen und unserem Risikohinweis.