Die Erstbewertung des PolyNetwork-Hacks

Die Erstbewertung des PolyNetwork-Hacks

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:

  1. Der Angreifer eine gültige signierte Nachricht an die Funktion verifyHeaderAndExecuteTx übergibt
  2. Die onlyManagerContract-Modifikation im LockProxy-Smart-Contract wird NICHT umgangen.

Basierend auf diesen beiden Beobachtungen vermuten wir, dass:

  1. 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

  1. 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

Sign up for the latest updates
#1 Cetus Incident: One Unchecked Shift Drains $223M in the Largest DeFi Hack of 2025

#1 Cetus Incident: One Unchecked Shift Drains $223M in the Largest DeFi Hack of 2025

Cetus Protocol, the largest concentrated-liquidity DEX on Sui, was exploited on May 22, 2025, resulting in an estimated ~$223M loss across multiple liquidity pools. The attacker leveraged a flaw in checked_shlw(), a custom overflow-prevention helper used in fixed-point u256 math, where an incorrect constant and comparison failed to block unsafe left shifts and caused silent truncation of high bits during liquidity delta calculations. By crafting specific liquidity and tick/price-range parameters, the exploit made required deposits appear near-zero while minting an oversized liquidity position, which was later withdrawn to drain real pool reserves.

#2 Bybit Incident: A Web2 Breach Enables the Largest Crypto Hack in History

#2 Bybit Incident: A Web2 Breach Enables the Largest Crypto Hack in History

The largest crypto hack ever, the February 21, 2025 Bybit breach stole about $1.5B after attackers used social engineering to compromise a Safe{Wallet} workflow, injected malicious JavaScript into an AWS S3 bucket, tampered with the transaction signing process, and upgraded Bybit’s Safe{Wallet} contract to a malicious implementation that drained funds across multiple chains.

Weekly Web3 Security Incident Roundup | Jan 25 – Feb 1, 2026

Weekly Web3 Security Incident Roundup | Jan 25 – Feb 1, 2026

During the week of January 25 to February 1, 2026, six blockchain security incidents were reported with total losses of ~$18.05M. These involved improper input validation, token design flaws, key compromises, and business logic errors across DeFi protocols on multiple chains. The primary causes included unchecked user inputs enabling arbitrary calls, flawed burn mechanisms allowing price manipulation, compromised developer tools, and missing solvency checks in lending functions.