Bridge Bugs Overview

Author: Konstantin Nekrasov
Security researcher at MixBytes
Intro
Blockchain bridges are an important tool in the world of cryptocurrency and blockchain technology. They allow different blockchain networks to communicate and exchange information, making it easier to transfer assets between different chains. However, as with any technology, there is a risk of hacking and security breaches. It is important to understand the potential vulnerabilities and how to protect against them in order to ensure the safety and security of your assets. In this article, we will provide an overview of blockchain bridge hacks and discuss ways to prevent and mitigate these attacks.
Ronin
Description
Ronin used a 5/9 validator scheme for transaction signing. The attacker was able to hack Sky Mavis, which controlled 4 validators. It appears that there was an arrangement between Sky Mavis and the Axie DAO which essentially allowed Sky Mavis access to another (fifth) validator. As a result, by hacking Mavis, the attacker gained access to all the necessary 5/9 validators for transaction signing.
Type of bug
Server-side hack
Recommendation
There are several measures that can be taken to help prevent attacks similar to the one that occurred on the Ronin Network:

  1. Decentralization: One key measure to help prevent such attacks is to ensure that the system is decentralized, meaning that it is not controlled by a small number of entities. By distributing control among a larger number of participants, it becomes more difficult for a single attacker to gain sufficient control to execute a successful attack.
  2. Least privilege: It is important to ensure that users and systems are granted only the minimum permissions necessary to perform their intended functions. This helps to reduce the potential attack surface and makes it harder for attackers to gain access to sensitive systems or data.
  3. Monitoring: Implementing effective monitoring can help detect suspicious activity and alert administrators to potential attacks in progress. This can ensure a timely response and may help prevent or mitigate the impact of an attack.
  4. It is recommended to conduct an audit not only of the code of smart contracts but also of the entire system as a whole, including how it is deployed and the server-side. This will help ensure the security and reliability of the system.

It is important to note that no system can be completely immune to attacks, and it is always a good idea to have contingency plans in place to deal with the potential consequences of a successful attack.
Date
29.03.2022
Stolen
$625 000 000,00
Links
Wormhole
Description
The hack on Solana's Wormhole occurred when an attacker was able to bypass the signature checks that were meant to verify transfers between blockchains. They did this by using a fake "SignatureSet" which was created by calling the "verify_signatures" function on the main bridge, but substituting the system program that for signature validation with the fake account. This allowed the attacker to create a valid "Validator Action Approval" (VAA) and trigger an unauthorized mint to their own account on Solana, resulting in the theft of 120,000 ETH. The attacker then bridged 93,750 of these ETH back to Ethereum, where they remain in the hacker's wallet. This exploit was made possible due to a flaw in the contract that didn't properly validate all input accounts, allowing the attacker to bypass the signature checks and trigger the unauthorized mint.
Type of bug
Missing validation when using cryptograpic precompiles
Technical details
@samczsun has a detailed twitter thread on technical details of the hack.
The verify_signatures function is meant to take a set of signatures provided by the guardians and pack it into a SignatureSet. But it doesn't actually do any of the verification itself. Instead, it delegates that to the Secp256k1 program.
And herein lies the problem. The solana_program::sysvar::instructions mod is meant to be used with the Instructions sysvar, a sort of precompile on Solana. However, the version of solana_program that Wormhole used didn't verify the address being used.
This meant that you could create your own account which stored the same data that the Instructions sysvar would have stored, and substituted that account for the Instruction sysvar in the call to verify_signatures. This would essentially bypass signature validation entirely.
Recommendation
The wormhole didn't verify the address of the Secp256k1 program used for signature verification. Thus, the general recommendation of using a whitelist of system component addresses could help.
Date
02.02.2022
Stolen
$326 000 000,00
Links
Nomad
Description
The exploit was caused by a recent update to one of Nomad's smart contracts, which initialized the trusted root to be 0x00. This had the unintended effect of auto-proving every message, allowing users to spoof transactions and withdraw money that did not actually belong to them. The incident has drawn attention to the security of cross-chain bridges and the importance of thorough testing and risk assessment before implementing updates.
Type of bug
Bad deployment
Technical details
@samczsun has a detailed twitter thread on technical details of the hack.
This left only one possibility - there was a fatal flaw within the Replica contract. But how? A quick look suggests that the message submitted must belong to an acceptable root. Otherwise, the check on line 185 would fail.
Fortunately, there's an easy way to sanity check this assumption. I knew that the root of a message which had not been proven would be 0x00, because messages[_messageHash] would be uninitialized. All I had to do was check whether the contract would accept that as a root.
Oops…
It turns out that during a routine upgrade, the Nomad team initialized the trusted root to be 0x00. To be clear, using zero values as initialization values is a common practice. Unfortunately, in this case it had a tiny side effect of auto-proving every message.
Recommendation
Having a good test coverage and running tests before any deployment or redeployment is an important practice in order to minimize the risk of introducing bugs into a system. In the case of the Nomad token bridge, a thorough testing process may have identified the issue with initializing the trusted root to be 0x00, which had the unintended effect of auto-proving every message and allowing users to spoof transactions.

To ensure a good test coverage, it is important to have a comprehensive set of tests that cover as many various scenarios and edge cases as possible. This can include unit tests, integration tests, and end-to-end tests. It is vital to have a robust testing process in place that includes both manual and automated testing.

In addition to running tests, it is also significant to regularly review and update the testing process to ensure its effectiveness and to cover all relevant areas. This can include reviewing the types of tests being run, the coverage of the tests, and the processes for running and reviewing the test results.

Overall, having a good test coverage and running tests before any deployment or redeployment is an essential part of maintaining the security and stability of a system. It helps to identify and address potential issues before they can cause any harm.
Date
01.08.2022
Stolen
$190 000 000,00
Links
Horizon by Harmony
Description
The Harmony Bridge was secured by a 2-of-5 multisig, of which the following addresses were compromised:

  • 0xf845A7ee8477AD1FB4446651E548901a2635A915
  • 0x812d8622C6F3c45959439e7ede3C580dA06f8f25

The attack vector which allowed the hacker to take control of these addresses remains unknown, though some have suggested that they were hot wallets with private keys kept in plaintext.

If an attacker managed to gain access to the servers running these hot wallets, they would have access to the two addresses necessary to pass any transactions they like, such as draining $100M from the bridge.
Type of bug
Server-side hack
Recommendation
It is generally recommended to use more signatures in a multisignature (multisig) configuration for added security. This is because a multisig setup requires the consent of multiple parties for transactions to be initiated or completed, making it more difficult for a single party to take control of the wallet or funds. As the number of required signatures increases, it becomes more difficult for a hacker to compromise the required number of keys and gain access to a wallet or funds.

It is important to note that in the case of the Harmony Bridge hack, the low number of signatures required for transactions was not the only issue. It is also possible that the private keys for the two addresses involved in the hack were not properly secured, which may have contributed to the success of the attack. Additionally, the fact that the sufficient number of signatures was stored on servers may have made them more vulnerable to compromise, as servers are more susceptible to cyber attacks than offline storage methods such as hardware wallets.

Therefore, it is vital to not only use a sufficient number of signatures in a multisig configuration, but also to ensure that the private keys are properly secured and stored in a secure location. It is generally recommended to store private keys offline, such as on a hardware wallet in order to reduce the risk of them being compromised by cyber attacks. By implementing these measures, users can increase the security of their cryptocurrency assets and reduce the risk of them stolen in a hack.
Date
23.06.2022
Stolen
$100 000 000,00
Links
BSC Token Hub
Description
It appears that the BNB Smart Chain (BSC) was hacked by exploiting a vulnerability in the BNB bridge, which connects the BNB Beacon Chain (BEP2) to the BSC (BEP20). The hacker was able to forge proof of deposit on the legacy Binance Beacon Chain and mint two batches of 1 million BNB each. The bridge used vulnerable IAVL verification, which the hacker was able to forge specifically for block 110217401 from August 2020. The hacker then deposited the stolen BNB as collateral on the Venus Protocol lending platform and moved the funds to other chains, including Ethereum, Fantom, Avalanche, and Polygon. Binance was able to halt the chain and freeze the hacker's access to the remaining funds on their BSC address, but not before the hacker had escaped with a portion of the stolen BNB.
Type of bug
Bad cryptography
Technical details
@samczsun has a detailed twitter thread on technical details of the hack.
Recommendation
It is recommended that you never attempt to implement cryptography on your own, as it is a complex field that requires a thorough understanding of mathematical concepts and best security practices. If you do choose to do so, it is strongly recommended that your code be reviewed by experts in the field of cryptography to ensure that it is secure.

Another recommendation is to implement monitoring for suspicious activity and have a robust contingency plan in place in case of a breach.
Date
06.10.2022
Stolen
$89 530 887,00
Links
EvoDeFi Bridge
Description
It appears that there are concerns regarding the financial stability of the EVODeFi protocol, a cross-chain platform and bridge that offers a range of cryptocurrency products on Binance Smart Chain and Polygon. Reports suggest that the team behind EVODeFi invested users' funds in the anchor Protocol, a product of the Terra blockchain, in order to fund their cross-platform bridge and maintain high annual percentage rates (APRs) on ValleySwap, a project owned by the same team. In an attempt to further boost APRs on ValleySwap, the team allegedly minted unbacked Tether (USDT) tokens, which caused funds on the Oasis Emerald network, where ValleySwap was based, to be unbacked as well. However, with the collapse of the Terra ecosystem, EVODeFi lost its investment in anchor Protocol and its unbacked USDT became worthless, leading to a lack of liquidity and inability to keep the bridge running. As a result, millions of dollars worth of users' funds may be trapped on Oasis, with no way to move them out without significant value loss.
Type of bug
There was no hack. Only bad financial decisions.
Recommendation
Perhaps a financial audit in such cases can help.
Date
07.06.2022
Stolen
$66 000 000,00
Links
pNetwork
Description
According to pNetwork's post-mortem report, the hack was executed by exploiting a bug in the Rust code of the pBTC-on-BSC bridge, which allowed the attacker to steal 277 BTC, worth roughly $12.7 million. The attack was successful on the pBTC-on-BSC bridge.

The attacker funded their account with BNB tokens from Binance and then deployed a set of smart contracts that abused the peg-out instructions that the pNetwork nodes use. These smart contracts created a series of event logs, including a legitimate peg-out request and faulty peg-out requests emitted by the attacker's smart contracts. Due to a bug in the code that extracts these log events, both the legitimate and faulty logs were extracted and processed, allowing the attacker to steal the BTC collateral for the pBTC-on-BSC bridge. The stolen BTC was then moved to a list of addresses that are still held by the attacker.
Type of bug
Server side logic bug
Recommendation
It is recommended for DeFi bridges to regularly audit their server-side logic code in order to identify and fix vulnerabilities before they can be exploited.
Date
19.09.2021
Stolen
$12 700 000,00
Links
Rubic
Description
Rubic exchange was hacked after USDC token was mistakenly added by the admin to the Rubic protocol's Router whitelist. This allowed any user to call USDC contract randomly using the RubicProxy contract. The attacker exploited this behaviour by calling the USDC contract using the routerCallNative function and transferring USDC tokens from users allowed to the RubicProxy contract to the attacker's account via the transferFrom interface.
Type of bug
Human error
Technical details
See the code at https://github.com/Cryptorubic/only-source-cross-chain-proxy/blob/f291786406b7f91c6ad097c62fb324f778c89eb2/contracts/RubicProxy.sol#L130.

The RubicProxy contract had a function called routerCallNative which allowed users to pass a router address and call parameters:
function routerCallNative(
    string calldata _providerInfo,
    BaseCrossChainParams calldata _params,
    bytes calldata _data
) external
First, the function checked that the target address was on the white list:
if (!whitelistRegistry.isWhitelistedCrossChain(_params.router)) {
    revert RouterNotAvailable(_params.router);
}
Then it made an external call to the router specified in the arguments:
AddressUpgradeable.functionCallWithValue(_params.router, _data, _amountIn);
An administrator accidentally added the USDC contract to the white list, and the attacker simply made calls to USDC on behalf of RubicProxy, which allowed the attacker to transfer USDC funds from the RubicProxy account and all the user accounts which approved RubicProxy to transfer money on their behalf.
Recommendation
Using multisig is one way to minimize the risk of human error in cryptocurrency-related operations. In a multisig setup, a transaction or action requires the approval of multiple parties before it can be completed. This can help to prevent mistakes or unauthorized actions, as all parties must agree on the transaction or action before it can be carried out.
Date
25.12.2022
Stolen
$1 400 000,00
Links
Summarized recommendations
Testing:

  • Have a comprehensive and robust testing process in place, including unit tests, integration tests, and end-to-end tests. Regularly review and update the testing process to ensure it covers all relevant areas.

Implementation:

  • Implement a whitelist of approved system addresses (for routers, validators, etc.) to prevent unauthorized transactions. Maintain and update the whitelist to ensure effectiveness.
  • Decentralize the system and implement least privilege to reduce the attack surface and make it harder for attackers to gain access.
  • Never attempt to implement cryptography on your own and have experts review the code.
  • Implement functionality to quickly stop (pause) the bridge's operation in case of a hack to prevent the attacker from withdrawing funds.

Access:

  • Use a multisig for governance (including the whitelist management) to reduce human error and attack surface.
  • Use more signatures, at least 3/5.
  • Do not store private keys for governance on remote servers. Use hardware wallets instead.

Audit:

  • Conduct an audit of the entire system, including the code of smart contracts and how it is deployed, to ensure security and reliability.
  • Do not forget to regularly audit server-side code.

Backup plan:

  • Implement monitoring to detect suspicious activity and alert administrators to potential attacks.
  • Have a solid disaster recovery plan in place to quickly and efficiently recover assets in the event of a successful attack.
Conclusion
We've compiled a list of recommendations based on recent hacks to help you audit and protect future blockchain bridges. These recommendations may seem obvious, but it is still important to follow them, especially when developing and managing a blockchain bridge.
Disclaimer
The information contained in this Website is for educational and informational purposes only and shall not be understood or construed as financial or investment advice.
Other posts