Decoding Poly Network $34 Billion Hack

Decoding Poly Network $34 Billion Hack

Decoding Poly Network $34 Billion Hack

Decoding Poly Network $34 Billion Hack

Decoding Poly Network $34 Billion Hack

Read Time: 8 minutes

Summary:

On July 2nd, 2023, Poly Network suffered a hack of what was initially reported to be 34 billion dollars. The main accuse of this is a compromise of private keys or a multi-signature service attack. The hacker exploited forged proofs to initiate withdrawal operations on the cross-chain bridge contracts across multiple chains. 

About Project:

Poly cross-chain ecosystem provides a platform for various chains to interact and transfer data along with carrying out cross-chain transactions. 

To learn more about the Project, check out the official documentation.


Vulnerability Analysis & Impact:

On-Chain Details:

Attacker Address: List of issued Poly Network Hackers 

Attack Transaction: List of attack transactions 

The Root Cause:

The root cause of the hack was not a logical bug but most likely a case of stolen/misused private keys.

To understand this, let’s first get the hang of Poly Network’s cross-chain interaction 

Below is a  poly’s sample cross-chain interaction between chains .

source

Notice that the DApp contract invoked by the users invokes the Cross-Chain Manager Contract 

This contract allows tokens to be transferred from the source chain to the destination chain.

A  Merkle Proof is required for the transaction’s legitimacy and to ensure that a transaction has been created and occurred on the relay chain. 

This gets encoded with other arguments that together withdraw these tokens in the destination chain, 

You can read more about the process from the official documentation.

The function verifyHeaderAndExecuteTx is responsible for the verification of the header and then the execution of the transaction. 

This is the central access point, though, where users can “unlock” tokens on the destination chain that was “locked” in the source chain. 

It takes 3 parameters 

  1. Transaction Merkle proof
  2. Header containing state root to verify the Merkle proof 
  3. A converted signature derived from Poly chain’s “keepers” (EOA’s)

The transfer of the token from the original chain is what Poly called as “lock”, and the retrieval of the token is termed as “unlock”.

Poly has a set of Externally Owned Accounts. These EOAs need to sign the “unlock” event at the destination chain also includes other relevant data of the source chain, for the transaction to happen. 

At this point, either 

  • The private keys that made the converted signature were compromised. or,
  • There is a logical bug somewhere in the implementation that returns Merkle root 

To verify the signature, this function is used 

function verifySig(bytes memory _rawHeader, bytes memory _sigList, address[] memory _keepers, uint _m) internal pure returns (bool){

//_rawHeader = 0x0000000000000000000000001e8bb7336ce3a75ea668e10854c6b6c9530dab7…
//_sigList = // List of 3 signatures from
// 0x3dFcCB7b8A6972CDE3B695d3C0c032514B0f3825,
// 0x4c46e1f946362547546677Bfa719598385ce56f2,
// 0x51b7529137D34002c4ebd81A2244F0ee7e95B2C0

//_keepers= [“0x3dFcCB7b8A6972CDE3B695d3C0c032514B0f3825″,”0x4c46e1f946362547546677Bfa719598385ce56f2″,”0xF81F676832F6dFEC4A5d0671BD27156425fCEF98″,”0x51b7529137D34002c4ebd81A2244F0ee7e95B2C0”]

//_m = 3


        bytes32 hash = getHeaderHash(_rawHeader);
        uint sigCount = _sigList.length.div(POLYCHAIN_SIGNATURE_LEN);
        address[] memory signers = new address[](sigCount);
//   signers = [
        //     0x4c46e1f946362547546677Bfa719598385ce56f2,
        //     0x3dFcCB7b8A6972CDE3B695d3C0c032514B0f3825,
        //     0x51b7529137D34002c4ebd81A2244F0ee7e95B2C0
        // ]

        bytes32 r;
        bytes32 s;
        uint8 v;
        for(uint j = 0; j  < sigCount; j++){
            r = Utils.bytesToBytes32(Utils.slice(_sigList, j*POLYCHAIN_SIGNATURE_LEN, 32));
            s =  Utils.bytesToBytes32(Utils.slice(_sigList, j*POLYCHAIN_SIGNATURE_LEN + 32, 32));
            v =  uint8(_sigList[j*POLYCHAIN_SIGNATURE_LEN + 64]) + 27;
            signers[j] =  ecrecover(sha256(abi.encodePacked(hash)), v, r, s);
            if (signers[j] == address(0)) return false;
        }
        return Utils.containMAddresses(_keepers, signers, _m);
    }

For the transaction to happen, the signature needs to be verified. 

Upon investigation, it has been clear that the attacker correctly invoked this function. 

It is worth noting that the list of keepers has remained constant for a long time and has not been modified.

The hypothesis of key compromise was further solidified when further inspection was done on the Merkle Prover function in hopes of finding a logical bug in the implementation of smart contract.

/* @notice                  Verify Poly chain transaction whether exist or not
    *  @param _auditPath        Poly chain merkle proof
    *  @param _root             Poly chain root
    *  @return                  The verified value included in _auditPath
    */
    function merkleProve(bytes memory _auditPath, bytes32 _root) internal pure returns (bytes memory) {
        uint256 off = 0;
        bytes memory value;
        (value, off)  = ZeroCopySource.NextVarBytes(_auditPath, off);

        bytes32 hash = Utils.hashLeaf(value);
        uint size = _auditPath.length.sub(off).div(33);
        bytes32 nodeHash;
        byte pos;
        for (uint i = 0; i < size; i++) {
            (pos, off) = ZeroCopySource.NextByte(_auditPath, off);
            (nodeHash, off) = ZeroCopySource.NextHash(_auditPath, off);
            if (pos == 0x00) {
                hash = Utils.hashChildren(nodeHash, hash);
            } else if (pos == 0x01) {
                hash = Utils.hashChildren(hash, nodeHash);
            } else {
                revert(“merkleProve, NextByte for position info failed”);
            }
        }
        require(hash == _root, “merkleProve, expect root is not equal actual root”);
        return value;
    }

The above function takes 2 inputs 

_auditPath – This will contain a leaf node followed by a path through the Merkle tree that acts as a proof of it’s existence 

_root – This will take the state root of the Merkle tree 

According to this implementation –

The hash of the leaf node needing to correspond to the state root hash for the proof to succeed implies that the integrity of the data stored within the leaf node is crucial for the verification process. If this requirement was not in place, the attacker could have potentially manipulated the implementation by exploiting the flexibility allowed by the verifier.

Without the condition that the hash of the leaf node must match the state root hash, the attacker could have provided a zero-length witness and an empty path as proof. In this scenario, the attacker could have crafted an artificial state root containing an unlock command to send tokens to themselves. By bypassing the need for a valid leaf node hash, the attacker would have been able to create fraudulent proof that falsely claimed ownership or authorisation for certain actions.

However, because the hash of the leaf node must correspond to the state root hash for the proof to succeed, it ensures the integrity and authenticity of the data stored within the leaf node. This requirement prevents attackers from manipulating the implementation by constructing artificial state roots and gaining unauthorised access or control over the system.

This means that the possibility of private key exploitation has more weight out of the two possibilities. 

Despite this, there is no definitive proof that the private keys were stolen. 

Possibilities of a rug pull or a compromised off-chain software running 3 out of 4 keepers still holds true for the scenario described above 

In short, 

Poly network had a simple 3 of 4 multisig arrangement. 

The attacker used keys to sign proof that they owed BNB. 

The header containing the state root was correctly signed by 3 out of 4 addresses. This leads us to the direction of a private key exploit.

Attack Process:

  • The attacker called the lock function on the LockProxy cross-chain bridge contract to lock a small amount of Lever Token
  • The toChainId 6 corresponds to the BNB chain, which can be viewed at https://explorer.poly.network. If a transaction is visible on the Poly Network explorer, it indicates that it has been validated through the relay chain.
  • Switching to the BNB chain, the attacker used the verifyHeaderAndExecuteTx function to initiate withdrawal operations, but the quantity involved does not match the original lock amount. However, no record of this transaction was found upon querying the relay chain network.
  • The hacker tricked the “EthCrossChainManager” contract into thinking that the parameter was valid and authentic & executed it without any further checks. 
  • This allowed the hacker to issue tokens from PolyNetwork’s Ethereum pool to their own address on other chains, such as Metis, Polygon, and Binance Smart Chain.
  • The hacker repeated this process for other chains supported by PolyNetwork, such as Heco and Avalanche, by using similar malicious parameters and exploiting similar vulnerabilities in the corresponding contracts.
  • The hacker repeated this process for other chains supported by PolyNetwork, such as Heco and Avalanche, by using similar malicious parameters and exploiting similar vulnerabilities in the corresponding contracts.

Flow of Funds:

The breakdown of assets minted by the hacker on different chains is as follows: – 

  • 99,999,184 BNB and 10 billion BUSD issued on Metis 
  • 999.8127T SHIB issued on Heco 
  • 87,579,118 COW and 999,998,434 OOE issued on Polygon 
  • 636,643,868 STACK and 88,640,563 GM issued on Polygon 
  • 2,175,053 03 issued on Polygon 
  • 378,028,371 STACK, 82,854,568 XTM, 11,026,341 SPAY, and 89,383,712 GM issued on Avalanche
  • 8,882,911 METIS, 926,160,132 DOV, 978,102,855 SLD

The attacker used multiple addresses to withdraw funds from cross-chain bridge contracts. 

All cross-chain operations were directed towards chain ID 6. 

 These are the addresses that hold the majority of the portion of assets:  

  1. 0xc8Ab4aa93949c377C32c069272425bd42738C42F
  2. 0x23f4CA51aa75d9d3f28888748d514173394Cc671
  3. 0xfD3E731AFf8B930337302f26EEf015CFA022b778
  4. 0x11c924f0B50c51CbF9Ac31a20365A38F24D4A4E8
  5. 0x2F6C25E3c93c0FC7fdDe2Ece8e370AE152a57B82
  6. 0xc8Ab4aa93949c377C32c069272425bd42738C42F

complete resolution image here

On Ethereum, assets worth $4.3 million were swapped for 674 ETH, with 1592 ETH unlocked, totalling 2267 ETH. The hacker still holds 10M BNB and 10B BUSD, which can’t be processed. 

Attacker’s Wallets: Here is a snippet of hacker’s wallet .


After the Exploit

  July 2nd, 2023 06:47:20 PM UTC, the Project acknowledge the incident and announced it through their Twitter.

July 3rd, 2023 The project continues to suspend it’s services for the user as shared via Twitter.


How could they have prevented the Exploit?

Fast Monitoring systems could have prevented this attack or at least reduce the impact.

The attacker would not have a chance if the response from Poly Network was faster. It took 7 hours for them to react to the situation. 

Poly Network bridge had its private keys compromised, leading to the loss of the bridged token. Bridges should have been decentralized.

Web3 security- Need of the hour

Why QuillAudits For Web3 Security? QuillAudits is well-equipped with tools and expertise to provide cybersecurity solutions saving the loss of millions in funds.

Want more Such Security Blogs & Reports?

Connect with QuillAudits on :

Linkedin | Twitter | Website | Newsletter | Discord | Telegram

Partner with QuillAudits :

2,758 Views

Blockchain for dog nose wrinkles' Ponzi makes off ~$127M🐶

Project promised up to 150% returns on investment in 100 days, raising about 166.4 billion South Korean won — or about $127 million — from 22,000 people.

Latest blogs for this week

Understanding Fuzzing and Fuzz Testing: A Vital Tool in Web3 Security

Read Time: 5 minutes When it comes to smart contracts, ensuring the robustness and security of code is paramount. Many techniques are employed to safeguard these contracts against vulnerabilities
Read More

How EigenLayer’s Restaking Enhances Security and Rewards in DeFi

Read Time: 7 minutes Decentralized finance (DeFi) relies on Ethereum staking to secure the blockchain and maintain consensus. Restaking allows liquid staking tokens to be staked with validators in
Read More

ERC 404 Standard: Everything You Need to Know

Read Time: 7 minutes Introduction Ethereum has significantly shaped the crypto world with its introduction of smart contracts and decentralized applications (DApps). This has led to innovative developments in
Read More

DNS Attacks:  Cascading Effects and Mitigation Strategies

Read Time: 8 minutes Introduction DNS security is vital for a safe online space. DNS translates domain names to IP addresses, crucial for internet functionality. DNS ensures unique name-value
Read More

EIP-4844 Explained: The Key to Ethereum’s Scalability with Protodanksharding

Read Time: 7 minutes Introduction  Ethereum, the driving force behind dApps, has struggled with scalability. High fees and slow processing have limited its potential. They have kept it from
Read More

QuillAudits Powers Supermoon at ETH Denver!

Read Time: 4 minutes Calling all the brightest minds and leaders in the crypto world! Are you ready to build, connect, and innovate at the hottest event during ETH
Read More

Decoding the Role of Artificial Intelligence in Metaverse and Web3

Read Time: 7 minutes Introduction  Experts predict a transformative shift in global software, driven by AI and ML, marking the dawn of a new era. PwC predicts AI will
Read More

Transforming Assets: Unlocking Real-World Asset Tokenization

Read Time: 7 minutes In the blockchain, real-world assets (RWAs) are digital tokens that stand for tangible and conventional financial assets, including money, raw materials, stocks, and bonds. As
Read More
Scroll to Top

Become a Quiffiliate!
Join our mission to safeguard web3

Sounds Interesting, Right? All you have to do is:

1

Refer QuillAudits to Web3 projects for audits.

2

Earn rewards as we conclude the audits.

3

Thereby help us Secure web3 ecosystem.

Total Rewards Shared Out: $200K+