PolyNetwork wurde gehackt und über 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 Private Keys, der zum Signieren der Cross-Chain-Nachricht verwendet wird, oder ein Fehler im Signierungsprozess von PolyNetwork sein könnte, der missbraucht wurde, um eine manipulierte Nachricht zu signieren.
Haftungsausschluss: Dieser Blog enthält nur die Ergebnisse unserer ersten Analyse, die auf On-Chain-Daten auf Ethereum basieren. Ohne weitere Informationen von Poly Network können wir unsere Ergebnisse nicht überprüfen.
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 Private Keys). 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 -> managerProxyContractforLockProxy
- 0xc8a65fadf0e0ddaf421f28feab69bf6e2e589963: Angreifer
- 0x838bf9e95cb12dd76a54c9f9d2e3082eaf928270: EthCrossChainManager
- 0xcf2afe102057ba5c16f899271045a0a37fcb10f2: EthCrossChainData
- 0x250e76987d838a75310c34bf422ea9f1ac4cc906: LockProxy
- 0x5a51e2ebf8d136926b9ca7b59b60464e7c44d2eb: managerProxyContract for 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() übergeben hat. Diese Funktion dekodiert die Daten und überprüft die Signaturen, mit denen die Daten signiert wurden. 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 gültige Parameter zurückzuführen ist, die an die Funktion verifyHeaderAndExecuteTx übergeben wurden. Und die Parameter können 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 des Aufrufverfolgung wieder her.
Funktion: verifyHeaderAndExecuteTx:
verifySig
unlock
Die Variable des managerProxyContract im LockProxy. Sie stimmt mit dem Wert der Aufruferadresse der unlock-Funktion überein.
Schlussfolgerung
Aus den wiederhergestellten Werten stellen wir fest:
- Der Angreifer hat eine gültige signierte Nachricht an die Funktion verifyHeaderAndExecuteTx übergeben.
- Der Modifier
onlyManagerContractim LockProxy Smart Contract wurde NICHT umgangen.
Basierend auf diesen beiden Beobachtungen vermuten wir, dass:
- Der Angreifer möglicherweise die legitimen Schlüssel zum Signieren der Nachrichten besitzt, was darauf hindeutet, dass die Signierschlüssel möglicherweise offengelegt wurden.
Oder
- Es gibt einen Fehler im Signierungsprozess von PolyNetwork, der missbraucht wurde, um eine manipulierte Nachricht zu signieren.
Wir verfügen jedoch nicht über weitere Off-Chain-Daten, um unsere Erkenntnisse zu überprüfen. Wir hoffen, dass unsere Analyse für weitere Ermittlungen hilfreich sein kann.
Credits: Yufeng Hu, Siwei Wu, Lei Wu, Yajin Zhou @BlockSec
Twitter: https://twitter.com/BlockSecTeam
