Bridge Bugs Overview

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.

Server-side hack

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.

29.03.2022

$625 000 000,00

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.

Missing validation when using cryptograpic precompiles

@samczsun has a detailed twitter thread on technical details of the hack.

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.

02.02.2022

$326 000 000,00

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.

Bad deployment

@samczsun has a detailed twitter thread on technical details of the hack.

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.

01.08.2022

$190 000 000,00

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.

Server-side hack

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.

23.06.2022

$100 000 000,00

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.

Bad cryptography

@samczsun has a detailed twitter thread on technical details of the hack.

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.

06.10.2022

$89 530 887,00

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.

There was no hack. Only bad financial decisions.

Perhaps a financial audit in such cases can help.

07.06.2022

$66 000 000,00

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.

Server side logic bug

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.

19.09.2021

$12 700 000,00

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.

Human error

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.

25.12.2022

$1 400 000,00