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 keine Hinweise darauf, wie der Hack stattgefunden hat und was die Grundursache des Hacks war. Als Sicherheitsexperten-Team haben wir unsere Untersuchung begonnen.
Schritt 1: Angriffs-Transaktion finden
Wir haben die Angriffs-Transaktion 0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a in unserem Transaktionsvirtualisierungssystem (https://tx.blocksecteam.com) erneut abgespielt.
Die Spur ist ziemlich einfach und unterscheidet sich von anderen Angriffen, die den Preis manipulieren. Diese weisen normalerweise sehr komplizierte Funktionsaufrufe auf (siehe den Popsicle-Hack.).
Schritt 2: Smart Contract Code analysieren
Nachdem wir die Angriffstrace erhalten hatten, mussten wir den Quellcode des Vertrags überprüfen. Überraschenderweise hatte das Poly Network keinen verifizierten Quellcode auf Etherscan. Wir konnten den veröffentlichten Quellcode jedoch auf GitHub finden.
Nach der Überprüfung des Quellcodes konnten wir keine offensichtliche Code-Schwachstelle finden. Wir verglichen auch die Angriffstrace mit einer legitimen Transaktions-Trace und stellten fest, dass sie ähnlich waren.
Schritt 3: Kritische Zustände wiederherstellen
Dann stellten wir die kritischen Zustände während des Angriffs wieder her. Da der Angriff durch den Aufruf von VerifyHeaderAndExecuteTxEvent gestartet wurde, stellten wir mehrere kritische Variablenwerte wieder her, die wir in unserer ersten Analyse geteilt haben [1].
Während dieses Prozesses stellten wir fest, dass es nur einen Keeper gab (siehe obige Abbildung). Da der Wert aus der Angriffstrace stammt und die Angriffstransaktion alle Signaturprüfungen bestanden hatte, dachten wir, der mögliche Grund könnte die Offenlegung des privaten Schlüssels oder ein Fehler im Signaturprozess des Servers sein [1].
Hier haben wir jedoch einen Fehler gemacht. Einen Angriff zu analysieren ist wie eine Zwiebel zu schälen. Man schält sie Schicht für Schicht, bis man die wirkliche „Wurzel-Wurzel-Wurzel“-Ursache findet. Damals haben wir die Zwiebel nicht weiter geschält, um zu sehen, ob der Keeper geändert worden war!
Schritt 4: Neuer Hinweis
Ein paar Stunden später gaben Kelvin und Slow Mist neue Hinweise auf Twitter, die zeigten, dass der Keeper gewechselt worden war. Der Änderungsprozess missbrauchte eine Hash-Kollision, um eine leistungsstarke Funktion aufzurufen – einen „smarten“ Hack.
Nun erkannten wir, dass unsere erste Analyse nicht vollständig war. Basierend auf den neuesten Informationen spielten wir die Transaktion, die den Keeper geändert hat, erneut ab. Immer noch ist die Spur sehr einfach.
Aber denken Sie daran, dass es während dieser Transaktion vier Keeper gab (statt einem). Alle diese Schlüssel sind die gleichen wie bei anderen legitimen Transaktionen – das bedeutet, dass die Schlüssel legitim sind. Hier kommt die Frage: Warum konnte die Transaktion, die den Keeper ändert, überhaupt auf die Kette gesetzt und ausgeführt werden?
Schritt 5: Quell-Transaktion lokalisieren
Wir versuchten dann, die Quell-Transaktion zu lokalisieren, da das Poly Network eine Cross-Chain-Bridge ist. Es sollte irgendwo eine Quell-Transaktion existieren. Dies taten wir, indem wir die kritische Variable dekodierten (wie im folgenden Bild gezeigt). Sie zeigt den Transaktions-Hash der Quell-Kette und der Poly-Kette.
Es gibt einen Trick, der bisher nirgendwo 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-Chain-Browser 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 mit.
Schritt 6: Grundursache lokalisieren
Aber immer noch können wir die Frage nicht beantworten: „Warum wurde die Transaktion zur Änderung des Keepers auf der Kette verpackt?“ Um diese Frage zu beantworten, begannen wir auf der Ontology-Kette und fanden den Transaktionsfluss:
Ontology-Transaktion -> Ontology-Relayer -> Poly-Kette -> Ethereum-Relayer -> Ethereum
Wir lasen dann den Quellcode der Ontology-Kette und der Relayer. Nach ein paar Stunden stellten wir fest, dass der Ontology-Relayer nicht genügend Validierung für die Cross-Chain-Transaktion hatte. Dies ließ die bösartige Transaktion auf der Poly-Kette verpacken. Danach war das System kompromittiert.
Nach interner Diskussion und Herausforderungen veröffentlichten wir unsere Ergebnisse am 12. August um 02:41 Uhr auf Twitter und Medium[3].
Lektionen
-
Security by Design. Sicherheit sollte Teil des gesamten Prozesses eines DeFi-Projekts sein. Benutzer vertrauen ihr Geld dem Projekt an. Im Gegenzug sollte das Projekt dieses Vertrauen verdienen. Leider sahen wir die Ignoranz der Sicherheit durch das Poly Network. Zum Beispiel ist der Mangel an Validierung eine altmodische Sicherheitslücke, die ich im Bachelor-Kurs unterrichtet habe.
-
Es gibt keinen verifizierten Quellcode für DeFi-Projekte mit mehr als 600 Millionen TVL. Die Grundlage der dezentralen Infrastruktur ist Vertrauen und die Grundlage des Vertrauens ist Transparenz. Leider sind Benutzer bereit, ihr Geld in ein Blackbox-Projekt zu investieren, was mich überrascht und beunruhigt. Wie die Sicherheitswahrnehmung der Benutzer verbessert werden kann, erfordert wahrscheinlich eine neue Lösung.
Referenz
[1]https://blocksecteam.medium.com/the-initial-analysis-of-the-polynetwork-hack-270ac6072e2a
[2]https://twitter.com/kelvinfichter/status/1425290462076747777
[3]https://blocksecteam.medium.com/the-further-analysis-of-the-poly-network-attack-6c459199c057
Credits: Yufeng Hu, Siwei Wu, Lei Wu, Yajin Zhou @ BlockSecTeam
