How to Avoid Cross-chain Risks? Answers from HurricaneSwap
In august 10, Poly Network, an important cross-chain protocol for swapping tokens across multiple blockchains, suffered an attack. As a result, more than $600 million was stolen, the largest DeFi hack to date. This incident truly highlighted the importance of securing cross-chain protocols.
The day after the attack, the hacker posted a series of Q&As via memos in Ethereum transactions. He said the attack was “for fun :)”, and because “cross-chain hacking is hot.”
Cross-chain Hacking is Hot!
According to PeckShield statistics, as of now, there have been 19 DeFi security incidents in just Q3 of 2021 alone. Topping the list were 6 hacks in cross-chain protocols (US$644 million losses); followed by hacks in the Ethereum ecosystem (US$29.37 million losses); and Polygon (US$1.22 million losses). Even excluding the $611 million involved in the Poly Network incident, the losses caused by attacks on cross-chain protocols is still the highest in DeFi.
In a way, the high frequency and large monetary impact of these cross-chain attacks is a consequence of the growing enthusiasm for cross-chain protocols. The emergence of cross-chain DEXs has made it simple and fast for DeFi users to trade assets across different chains. In a traditional CEX, cross-chain transactions take tens of minutes or even several days to process and can involve large fees. Thus, a cross-chain DEX (which only takes 2–3 steps and a few seconds to complete a cross chain transaction) can offer improved user experiences. However, the recent and frequent security incidents surrounding cross-chain protocols might point out that, without strong security guarantees, better speed, efficacy and rates, might not be enough.
Risks of Cross-chain DEX
From the statistics of PeckShield we can see that cross-chain security issues that have erupted intensively in the past two months happen mainly due to “logic errors” of the underlying protocols.
Here is a brief overview of the potential risks of cross-chain DEXes with specific examples of past attacks:
1. Fake Deposit — THORChain
This exploit can happen when the protocol has some vulnerability in the contracts that enables hackers to trick the network into thinking they have deposited funds into the contract, when they have not. This enables the attacker to ask for a refund of a deposit that was never there in the first place.
THORChain suffered this type of attack. The function for verifying the token address checked if the ticker of the received token was ETH. The attacker forged an ERC-20 token with the ticker ETH to deceive the cross-chain bridge and then got real ETH tokens “refunded” to themselves.
2. Multi-signature & Quota Vulnerabilities — ChainSwap
ChainSwap funds were stolen for a second time because the quotas for whitelist addresses of cross-chain bridges were increased by a node. When the whitelist was checked, the multi-signature required originally became a single signature due to a configuration error. The attacker only needed one of the signatures to transfer the assets by calling the Receive function on the other chain.
3. Redemption Risk — Anyswap
To explain this we will take the BNB of OKExChain (OEC) as an example. The Anyswap itself issued BNB on OEC without official authorization from Binance. The BNB on OEC is not equivalent to the BNB on BSC and is actually a BNB bond issued by Anyswap and circulating on OEC.
4. Private Key Leakage — Anyswap
The main reason that Anyswap was attacked was that the signature used a repeated R-value. If two transactions signed by the same account have the same R-value of the RSV signature, the hacker can reversely derive the private key of the account. Since the account could be used on BSC, ETH and FTM, the assets on multiple chains of the account were stolen. This was also related to the excessive authority of a single account.
5. Flashloan Arbitrage — bEarn Fi
The attacker lent BUSD through flashloans, generated ibBUSD through Alpaca Finance’s lending, and then exploited bEarn Fi’s contract strategy vulnerabilities to carry out arbitrage attacks between ibBUSD and BUSD.
6. Keeper (Relayer) Replacement & Signature Forgery — O3 / Poly Network
By disguising a transaction to replace the Keeper (relayer) as a normal cross-chain transaction, the attacker replaced the address of the Keeper in the Poly Network with his own address. The verification function for relayer was not secure enough, and it only checked 4 bytes. The attacker encountered 4 bytes that met the requirements and successfully converted his own address into the Keeper address and signed it. Then, the hacker called the LockProxy contract and looted all the cross-chain assets of Poly Network.
Risk Prevention Starts from Protocols
The above 6 risks are summarized by the security team of the newly born protocol HurricaneSwap. As a fully upgraded LP-Bridge protocol compared to the traditional single token cross-chain, HurricaneSwap deployed on Avalanche has the top architecture consultant in the blockchain industry — Ted Yin, the first author of the HotStuff consensus, and the current chief architect of the Avalanche.
Most of these attacked cross-chain protocols have their own protocol vulnerabilities or logic errors. To fully prevent them, the security deployment of a cross-chain DEX must be extremely meticulous. In response to the above risks, HurricaneSwap — a more advanced LP-Bridge protocol created by one of the top teams in this industry — has already prepared some solid security guarantees:
1. Fake Deposit
HurricaneSwap has strict restrictions on the contract addresses and the kinds of cross-chain tokens supported by the HurricaneStation. Besides, PeckShield’s audit report has made it clear that HurricaneSwap has no risk of fake deposit.
2. Multi-signature & Quota Vulnerabilities
The code of HurricaneSwap does not contain any code which embezzles LP assets of users, and there is no way to loot the LP assets by multi-signature. (Check the audit report by PeckShield for more details.)
Cross-chain liquidity bridges such as ChainSwap check if a deposit of Token A has happened in one end and mint Token A’ on the destination chain. Whitelisted users rely on quotas to deposit and withdraw liquidity in ChainSwap. HurricaneSwap does not have a quota upper limit. The upper limit of liquidity that users can withdraw depends on the LP token they own.
3. Redemption Risk
HurricaneSwap’s aToken is a mapping of source chain assets. Users can check whether the number of liquidity assets locked in the HurricaneStation contract and the number of aToken issued in HurricaneSwap is 1:1. In the future, we will also integrate Chainlink Oracles to make it even more secure.
4. Private Key Leakage
HurricaneSwap has learned from Anyswaps mistakes. There is no repeated R-value signature in the transaction, which prevents the attacker from reverse-engineering the private key. Furthermore, our team used dedicated key management tools during the contract deployment phase to avoid the risk of leakage caused by storing private keys in plain text.
5. Flashloan Arbitrage
The key to conduct flashloan arbitrage is the manipulation of the price feeds the contract receives.
HurricaneSwap uses Chainlink price feeds to enable HurricaneStation to check the aggregated price of assets, so the contract will not rely in a single data source. Additionally, a fuse mechanism will be adopted to further prevent flashloan attacks by suspending the call of related token contracts. Furthermore, the HurricaneAlliance nodes will carry out arbitrage to narrow the price gap between HurricaneSwap and other exchanges, reducing a potential attacker’s profit should a hack ever occur.
6. Relayer Replacement & Signature Forgery
The master account of the Roke Protocol in HurricaneSwap has a similar function to Keeper, but Roke Protocol cannot control the liquidity assets locked in HurricaneStation. Only the Roke Protocol Owner Account has permission to mint or burn a Token, and there is no possibility of forging a Token by replacing the relayer.
HurricaneSwap — Born to be Secure
One of the main reasons to move away from single token cross-chain bridges towards an LP-Bridge is the risks of current cross-chain mechanisms. As a more advanced cross-chain mechanism, HurricaneSwap’s LP-Bridge has inherent security advantages over current single token bridges, the most fundamental difference being that attackers cannot escape through a single token cross-chain under the LP-Bridge mechanism. In addition to these security features, HurricaneSwap also uses Roke Protocol, Hurricane Station and HurricaneAlliance to provide additional security: price gaps, LP permissions, and decentralized security verification, and more. Besides, Ted Yin and other industry-leading members have jointly constructed the underlying guarantee for the project in code, logic, and mechanism.
The emergence of new things is always accompanied by risks, and the Poly Network incident has once again highlighted the importance of security in the defi industry.
Remember: no one is evil unless you present them with the opportunity.
