PolyNetwork wurde gehackt und mehr als 300 Millionen US-Dollar wurden gestohlen. Der Angreifer führte den Angriff auf mehreren Chains durch. In diesem Blog verwenden wir die Angriffstransaktion auf Ethereum (0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a), um den möglichen Grund für den Hack zu analysieren. Unsere erste Analyse zeigt, dass ein möglicher Grund entweder die Offenlegung des privaten Schlüssels sein könnte, der zum Signieren der Cross-Chain-Nachricht verwendet wird, oder dass ein Fehler im Signaturprozess von PolyNetwork vorliegt, der missbraucht wurde, um eine präparierte Nachricht zu signieren.
Haftungsausschluss: Dieser Blog enthält nur die Ergebnisse unserer ersten Analyse, die auf On-Chain-Daten auf Ethereum basieren. Wir können unsere Ergebnisse ohne weitere Informationen von Poly Network nicht verifizieren.
Update 2021/08/12: Weitere Informationen zeigen, dass die Ursache des Angriffs darin liegt, dass der Keeper vom Angreifer modifiziert wurde (nicht aufgrund der Offenlegung des privaten Schlüssels). Wir haben eine weitere Analyse, um die Frage zu beantworten, warum die Transaktion zur Änderung des Keepers überhaupt ausgeführt werden konnte.
Transaktion und Aufrufverfolgung
Wir verwenden unser Transaktionsanalyse-System, um die Spur wiederherzustellen.

Angreifer -> EthCrossChainManager -> EthCrossChainData -> LockProxy -> managerProxyContractfürLockProxy
- 0xc8a65fadf0e0ddaf421f28feab69bf6e2e589963: Angreifer
- 0x838bf9e95cb12dd76a54c9f9d2e3082eaf928270: EthCrossChainManager
- 0xcf2afe102057ba5c16f899271045a0a37fcb10f2: EthCrossChainData
- 0x250e76987d838a75310c34bf422ea9f1ac4cc906: LockProxy
- 0x5a51e2ebf8d136926b9ca7b59b60464e7c44d2eb: managerProxyContract für LockProxy
Funktionssignaturen:
- d450e04c (verifyHeaderAndExecuteTx)
- 69d48074 (getCurEpochConPubKeyBytes)
- 5ac40790 (getCurEpochStartHeight)
- 0586763c (checkIfFromChainTxExist)
- e90bfdcf (markFromChainTxExist(uint64,bytes32))
Der Hauptprozess des Angriffs
Der Hauptprozess des Angriffs besteht darin, dass der Angreifer die signierten Daten an die Funktion verifyHeaderAndExecuteTx() übergab. Diese Funktion dekodiert die Daten und verifiziert die Signaturen, die zum Signieren der Daten verwendet werden. Wenn dieser Prozess erfolgreich ist, wird die in der Nachricht angegebene Methode (und die Vertragsadresse) ausgeführt. Während dieses Angriffs wurde die unlock-Funktion des Smart Contracts 0x250e76987d838a75310c34bf422ea9f1ac4cc906 aufgerufen, um Fei an den Angreifer zu transferieren.
Zusammenfassend lässt sich sagen, dass der Angriff auf die gültigen Parameter zurückzuführen ist, die an die Funktion verifyHeaderAndExecuteTx übergeben wurden. Und die Parameter konnten den Signaturverifizierungsprozess bestehen. Danach wird die in der Nachricht angegebene Transaktion ausgeführt (ähnlich der willkürlichen Befehlsausführung in der Softwaresicherheit).
Um diesen Prozess besser zu verstehen, stellen wir die kritischen Werte der Aufrufverfolgung wieder her.
Funktion: verifyHeaderAndExecuteTx:


verifySig

unlock

Die Variable des managerProxyContract im LockProxy. Sie stimmt mit der aufrufenden Adresse der unlock-Funktion überein.

Schlussfolgerung
Aus den wiederhergestellten Werten stellen wir fest, dass:
- Der Angreifer eine gültige signierte Nachricht an die Funktion verifyHeaderAndExecuteTx übergibt
- Die
onlyManagerContract-Modifikation im LockProxy-Smart-Contract wird NICHT umgangen.
Basierend auf diesen beiden Beobachtungen vermuten wir, dass:
- Der Angreifer möglicherweise über die legitimen Schlüssel zum Signieren der Nachrichten verfügt, was darauf hindeutet, dass die Signierschlüssel möglicherweise offengelegt wurden.
Oder
- Es liegt ein Fehler im Signaturprozess von PolyNetwork vor, der missbraucht wurde, um eine präparierte Nachricht zu signieren.
Wir verfügen jedoch nicht über weitere Off-Chain-Daten, um unsere Ergebnisse zu verifizieren. Wir hoffen, dass unsere Analyse für weitere Untersuchungen hilfreich sein kann.
Mitwirkende: Yufeng Hu, Siwei Wu, Lei Wu, Yajin Zhou @BlockSec
Twitter: https://twitter.com/BlockSecTeam



