Poly Network Validation Error

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' section to other sections, and add any missing information or sources you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

Poly Network

The Poly Network allows different smart chains to interact with one another securely. However, it contained a vulnerability which allowed funds to be removed. A hacker exploited the vulnerability, messed up their transactions such that their identity became known, and then proceeded to return the funds in exchange for a $500k bounty and legal immunity.

It remains to be seen whether the legal immunity will hold up in court. In the meantime, the funds have been distributed back to affected users.

This is a global/international case not involving a specific country.

About Poly Network

"In order to build a better next-generation internet infrastructure, we have launched a new cross-chain technology, the Poly Network. Poly Network is based on the side-chain/relay mode and adopts a two-layer architecture. It employs the Poly chain as a cross-chain coordinator, multiple homogeneous chains as crosschain transaction executors, and Relayer as a cross-chain information porter. By resolving issues such as trust, security and transaction issues of chain data, we have realized a safe, easy-to-use and efficient cross-chain system."

"Poly Network acts as a cross-chain interoperability bridge to facilitate the transfer of tokens between two relatively independent blockchains. As such, one of their main Poly Network smart contracts is the bridge itself. In order for bridges between chains to act effectively (e.g. for users to be able to use the network to transfer tokens across chains), they need to maintain large sums of liquidity. Whenever a user wants to “bridge” between chains Poly Network needs to efficiently burn/mint the equivalent assets on the respective chains."

"Poly Network is built to implement interoperability between multiple chains in order to build the next generation internet infrastructure. Authorized homogeneous and heterogeneous public blockchains can connect to Poly Network through an open, transparent admission mechanism and communicate with other blockchains. Poly Network has already integrated Bitcoin, Ethereum, Neo, Ontology, Elrond, Ziliqa, Binance Smart Chain, Switcheo and Huobi ECO Chain. More institutions and organizations are welcome to join Poly Network and build the next generation internet with us."

"The contract that issues these cross-chain token transfers uses “keepers” to verify and execute the transactions. Once the keeper signs on the source chain the CrossChainManager contract on the destination chain will check the Keeper’s signature for validity and execute the equivalent on the destination chain to complete the “bridge”."

"There is currently no indication that the Poly Network code had ever received an audit. Searching through the protocol’s GitHub repos did not indicate any audits had been performed or reported."

"On August 10, Poly Network suffered a $612 million hack—the largest crypto-related hack to date. Where the typical DeFi hack is against specific DeFi instruments, resulting in much smaller losses, in this case the attack was against Poly Network’s infrastructure, focusing on the DeFi platform itself and targeting control of the decentralized exchange’s (DEX) smart contracts."

"Since the smart contract executes the transactions and not the user themselves, the hacker was able to exploit the CrossChainManager smart contract and swap the “keepers” for a malicious keeper under their control. As a result, the main cross-chain contract on the Poly Network became completely controlled by the hacker, allowing him to unlock tokens that were supposed to remain locked within the bridge contract and move the tokens to addresses under his control. The hacker then replicated the attack across chains."

"As a result, the main cross-chain contract became completely controlled by the hacker, allowing him to unlock tokens that were supposed to be locked within the contract, send the tokens to addresses under their control, and then repeat the attack across chains."

"Poly has a contract called the "EthCrossChainManager". It's a privileged contract that has the right to trigger messages from another chain. It's a standard thing for cross-chain projects."

"It has a function named verifyHeaderAndExecuteTx that anyone can call to execute a cross-chain transaction."

"It (1) verifies that the block header is correct by checking signatures (seems the other chain was a poa sidechain or) and then (2) checks that the transaction was included within that block with a Merkle proof. Here's the code."

"One of the last things the function does is call executeCrossChainTx, which makes the call to the target contract. This is where the critical flaw sits. Poly checks that the target is a contract, but they forgot to prevent users from calling a very important target... the EthCrossChainData contract"

"By sending this cross-chain message, the user could trick the EthCrossChainManager into calling the EthCrossChainData contract, passing the onlyOwner check. Now the user just had to craft the right data to be able to trigger the function that changes the public keys…"

"The only remaining challenge was to figure out how to make the EthCrossChainManager call the right function. Now comes a little bit of complexity around how Solidity picks which function you're trying to call."

"The first four bytes of transaction input data is called the "signature hash" or "sighash" for short. It's a short piece of information that tells a Solidity contract what you're trying to do."

The sighash of a function is calculated by taking the first four bytes of the hash of "<function name>(<function input types>)". For example, the sighash of the ERC20 transfer function is the first four bytes of the hash of "transfer(address,uint256)".

"Poly's contract was willing to call any contract. However, it would only call the contract function that corresponded to the [right] sighash." "All the attacker had to do to call the right function was figure out some value for "_method" that, when combined with those other values and hashed, had the same leading four bytes as the sighash of our target function."

"With just a little bit of grinding, you can easily find some input that produces the right sighash. You don't need to find a full hash collision, you're only checking the first four bytes." "[H]ere's the actual sighash of the target function: http://ethers.utils.id ('putCurEpochConPubKeyBytes(bytes)').slice(0, 10) '0x41973cd9'"

"And the sighash that the attacker crafted... http://ethers.utils.id ('f1121318093(bytes,bytes,uint64)').slice(0, 10) '0x41973cd9'"

"Fantastic. No private key compromise required! Just craft the right data and boom... the contract will just hack itself!"

"This attack is mainly because the keeper of the EthCrossChainData contract can be modified by the EthCrossChainManager contract, and the verifyHeaderAndExecuteTx function of the EthCrossChainManager contract can execute the data passed in by the user through the _executeCrossChainTx function. Therefore, the attacker uses this function to pass in carefully constructed data to modify the keeper of the EthCrossChainData contract. It is not the case that this event occurred due to the leakage of the keeper’s private key."

"1. The core of this attack is that the verifyHeaderAndExecuteTx function of the EthCrossChainManager contract can execute specific cross-chain transactions through the _executeCrossChainTx function."

"2. Since the owner of the EthCrossChainData contract is the EthCrossChainManager contract, the EthCrossChainManager contract can modify the keeper of the contract by calling the putCurEpochConPubKeyBytes function of the EthCrossChainData contract."

"3. The verifyHeaderAndExecuteTx function of the EthCrossChainManager contract can perform user-specified cross-chain transactions by calling the _executeCrossChainTx function internally. So the attacker only needs to pass in the carefully constructed data through the verifyHeaderAndExecuteTx function for the _executeCrossChainTx function to execute the call to the EthCrossChainData contract PutCurEpochConPubKeyBytes function to change the keeper role to the address specified attackers."

"4. After replacing the address of the keeper role, the attacker can construct a transaction at will and withdraw any amount of funds from the contract."

"Shortly after the exploit, an unexpected protagonist appeared, going by the name of hanashiro.eth."

"hanashiro.eth first gained attention when they sent the hacker a tip about how to handle USDT, for which they received 13.37 Ether from the hacker as a reward." "Many others sent messages to the hacker afterwards, but none were quite as successful as hanashiro.eth."

"Hanashiro sent 1.337 of the 13.37 ETH he received to Vitalik." "Meanwhile our old friend hanashiro is now on a donation spree. Even donated to @RektHQ who will be writing extensively on him in their next report."

"With a truly crypto native level of philanthropic showmanship, hanashiro.eth went on to donate their stolen money to a few of the foundational organisations which support our industry, such as Infura, Etherscan, and rekt.news."

"Tether froze all of the 33M USDT that were stolen on the Ethereum chain." "$33M USDT frozen."

"By this point th[ings] had really hit the fan; and all eyes were on Poly Network, who resorted to posting an open letter to the attacker begging them to return the funds."

"[T]hen @WardBradt tweeted."

"Did the PolyNetwork Exploiter accidentally use the wrong sender address for this tx? The sender address is tied to FTX, Binance, Okex accounts."

"In all the swapping the hacker has done in an effort to obfuscate their trail, it appears the hacker had at one point reused a wallet that already had previous transactions with some prominent exchanges that could have identifying “know your customer” (KYC) information on him."

"Surely a hacker who feels confident enough to attempt an attack of this scale wouldn’t make such a basic OPSEC error? Or maybe they used fake KYC documents…"

"Either way, we began to see signs of fear from the attacker."

"The hacker began to suggest that they might return "some tokens" or even abandon them, saying that they were "not so interested in the money"."

"Then the hacker considered the idea of creating a DAO to distribute the stolen funds."

"Finally, the pressure became too much, and the hacker announced that they were “READY TO SURRENDER”"

"In an unexpected and unprecedented move, the attacker is now returning the funds to Poly Network."

"They announced that they were "READY TO RETURN THE FUNDS!" in an Ethereum transaction that was sent from the same wallet used for the attack."

"Before sending the first return transaction, the hacker created a token called "The hacker is ready to surrender" and sent this token to Poly Network who announced that they had set up a multisig controlled by ‘’known Poly addresses’’."

"In an August 17 Medium article, the Poly Network team announced that they had offered the hacker, whom they refer to as “Mr. White Hat,” the position of Chief Security Officer along with a $500,000 bounty for identifying the exploit. In the post, the team declared they have “no intention of holding Mr. White Hat legally responsible.”"

"CipherTrace has confirmed nearly all funds have been returned to Poly Network into the addresses they had developed specifically for the hacker to return the funds."

"the method to fix the vulnerability is using allow lists. The allow lists are initialized when creating the EthCrossChainManager. By doing so, this patch can ensure" that "[o]nly the contract in the allow lists can invoke the crossChain function, which is used to start the cross-chain transaction" and "[o]nly the method and the contract in the allow lists can be invoked by the cross-chain transaction."

This is a global/international case not involving a specific country.

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

Key Event Timeline - Poly Network Validation Error

Date	Event	Description
August 10th, 2021 3:48:40 AM	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.

Total Amount Lost

The total amount lost has been estimated at $611,000,000 USD.

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

A bounty of $500,000 USD was paid for the discovery.

Total Amount Recovered

The total amount recovered has been estimated at $610,500,000 USD.

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

What parts of this case are still remaining to be concluded?

Prevention Policies

It's not wise placing such a large amount of liquidity in a smart contract hot wallet, especially without an audit. The only truly secure storage of assets is an offline multi-sig wallet. In the future, it's very likely that insurance protocols will reduce some of the risk.

This was a lucky case in that losses were minimized by the hacker returning the funds.