Die Retrospektive des Poly Network Hacks aus der Sicht eines Sicherheitsforschers

In diesem Blog möchten wir den gesamten Prozess des Poly Network Hacks überprüfen und die gewonnenen Erkenntnisse diskutieren.

Wir wussten, dass das Poly Network am 10. August 2021 gehackt wurde (wir verwenden in diesem Blog die Zeitzone +8). Es gab jedoch keinen Hinweis darauf, wie der Hack stattgefunden hat und was die eigentliche Ursache des Hacks war. Als Sicherheitsteam haben wir unsere Untersuchung begonnen.

Schritt 1: Finde die Angriffstransaktion

Wir haben die Angriffstransaktion 0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a in unserem Transaktionsvirtualisierungssystem (https://tx.blocksecteam.com) nachgespielt.

Die Spur ist ziemlich einfach, was sich von anderen Angriffen unterscheidet, die den Preis manipulieren. Sie haben normalerweise sehr komplizierte Funktionsaufrufe (siehe den Popsicle-Hack.).

Schritt 2: Analysiere den Vertragscode

Nachdem wir die Angriffstransaktion erhalten hatten, mussten wir den Quellcode des Vertrags überprüfen. Überraschenderweise hat das Poly Network KEINEN verifizierten Quellcode auf Etherscan. Wir konnten jedoch den veröffentlichten Quellcode auf GitHub finden.

Nach der Überprüfung des Quellcodes haben wir keine offensichtlichen Code-Schwachstellen gefunden. Wir verglichen auch die Angriffstransaktion mit einer legitimen Transaktionstransaktion und stellten fest, dass sie ähnlich sind.

Schritt 3: Stelle die kritischen Zustände wieder her

Dann stellten wir die kritischen Zustände während des Angriffs wieder her. Da der Angriff durch den Aufruf von VerifyHeaderAndExecuteTxEvent ausgelöst wurde, stellten wir mehrere kritische Variablenwerte wieder her, die wir in unserer ersten Analyse geteilt haben [1].

Dabei stellten wir fest, dass es nur einen Keeper gibt (siehe obige Abbildung). Da der Wert aus der Angriffstransaktion stammt und die Angriffstransaktion alle Signaturprüfungen bestanden hat, dachten wir, der potenzielle Grund könnte die Offenlegung des privaten Schlüssels oder ein Fehler im Signierungsprozess des Servers sein [1].

Hier haben wir jedoch einen Fehler gemacht. Die Analyse eines Angriffs ist wie das Schälen einer Zwiebel. Man schält sie Schicht für Schicht, bis man die eigentliche "Wurzel-Wurzel-Wurzel"-Ursache gefunden hat. Zu diesem Zeitpunkt haben wir die Zwiebel nicht weiter geschält, um zu sehen, ob der Keeper geändert wurde!

Schritt 4: Neuer Hinweis

Ein paar Stunden später gaben Kelvin und Slow Mist neue Hinweise auf Twitter und zeigten an, dass der Keeper geändert wurde. Der Änderungsprozess missbrauchte eine Hash-Kollision, um eine mächtige Funktion aufzurufen – einen „smarten“ Hack.

Nun erkannten wir, dass unsere erste Analyse unvollständig war. Basierend auf den neuesten Informationen haben wir die Transaktion nachgespielt, die den Keeper geändert hat. Immer noch ist die Spur sehr einfach.

Aber denken Sie daran, dass während dieser Transaktion vier Keeper (anstelle von einem) vorhanden sind. Alle diese Schlüssel sind dieselben wie bei anderen legitimen Transaktionen – was bedeutet, dass die Schlüssel legitim sind. Hier stellt sich die Frage: Warum konnte die Transaktion, die den Keeper ändert, überhaupt auf der Kette platziert und ausgeführt werden?

Schritt 5: Ursprungstransaktion lokalisieren

Wir haben dann versucht, die Ursprungstransaktion zu lokalisieren, da das Poly Network eine Cross-Chain-Brücke ist. Es sollte irgendwo eine Ursprungstransaktion existieren. Dies haben wir getan, indem wir die kritische Variable dekodiert haben (wie im folgenden Bild gezeigt). Sie zeigt die Transaktions-Hash der Quellkette und der Poly-Kette.

Es gibt einen Trick, der nirgendwo anders erwähnt wurde. Der Tx-Hash-Wert in der Variablen hat eine andere Darstellung als der offizielle Wert in der Poly-Kette. Zum Beispiel ist der Tx-Hash der Poly-Kette in der Abbildung 0x80cc978479eb082e1e656993c63dee7a5d08a00dc2b2aab88bc0e465cfa0721a. Aber im Poly-Kettenbrowser ist der Hash-Wert 1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80 (sehen Sie den Unterschied?). Wir teilten unsere Erkenntnisse am 11. August um 16:55 Uhr in der EthereumSecurity TG-Gruppe.

Schritt 6: Ursache lokalisieren

Aber immer noch können wir die Frage nicht beantworten: „Warum konnte die Transaktion zur Änderung des Keepers auf der Kette gepackt werden?“ Um diese Frage zu beantworten, begannen wir auf der Ontology-Kette und fanden den Transaktionsfluss:

Ontology-Transaktion -> Ontology-Relayer -> Poly-Kette -> Ethereum-Relayer -> Ethereum

Dann lasen wir den Quellcode der Ontology-Kette und der Relayer. Nach ein paar Stunden stellten wir fest, dass der Ontology-Relayer nicht über genügend Validierung für die Cross-Chain-Transaktion verfügte. Dies konnte dazu führen, dass die bösartige Transaktion auf der Poly-Kette gepackt wurde. Danach war das System kompromittiert.

Nach interner Diskussion und Herausforderung veröffentlichten wir unsere Erkenntnisse am 12. August um 02:41 Uhr auf Twitter und Medium [3].

Lektionen

Security by Design. Sicherheit sollte im gesamten Prozess eines DeFi-Projekts eine Rolle spielen. Nutzer vertrauen ihr Geld dem Projekt an. Im Gegenzug sollte das Projekt das Vertrauen verdienen. Leider sahen wir die Ignoranz des Poly Networks bezüglich Sicherheit. Beispielsweise ist der Mangel an Validierung eine alte Sicherheitslücke, die ich in meinem Grundstudium gelehrt habe.
Es gibt keinen verifizierten Quellcode für ein DeFi-Projekt mit mehr als 600 Millionen TVL. Die Basis der dezentralen Infrastruktur ist Vertrauen und die Grundlage des Vertrauens ist Transparenz. Leider sind die Nutzer bereit, ihr Geld in ein Blackbox-Projekt zu stecken, was mich überrascht und beunruhigt. Wie die Sicherheitswahrnehmung der Nutzer verbessert werden kann, erfordert wahrscheinlich eine neue Lösung.