In a previous blog post, we explored the open problems in cross-chain related to the 3.2 billion USD stolen in such protocols, including a list of theoretical vulnerabilities and future research directions in the area.

The following list presents the most high-profile and mediatic cross-chain hacks in history. More than 3.2 billion USD were stolen from these protocols, and hacks have been recurrent since June 2021. In this post, we systematize and analyze some of the most profitable hacks in cross-chain history, according to some criteria presented below.

We present a comparative table of some hacks in the table above. These account for more than 94% of the total value stolen. All the metrics used in the table are explained below.

General Attack Information

Security Approach (SA): The security approach used by the bridge. This ranges from centralized to decentralized approaches. Check out the list of security approaches proposed here.

Date: The date of the first transaction exploiting a vulnerability in the protocol.

Amount: The amount in USD stolen from the cross-chain bridge. We do not include any collateral losses in other protocols.

Attacker Type (AT): We classify attackers as black or white hats based on whether they returned the funds (or both if there is at least one attacker of each type). Attackers who returned the funds, excluding agreed bounty fees, are also considered white hats in our analysis.

Number of Transactions (Txs): A range of the number of transactions issued by the attackers to exploit the bridge, including both external and internal transactions, which are transactions issued directly by the user or as a consequence of another contract execution, respectively. It does not include transactions issued before or after the attack to exchange or launder funds using DEXes (e.g., Uniswap) or mixing services.

Usage of Mixers (Mix): The usage of transaction mixers (e.g., Tornado Cash) by the attacker to launder funds either before or after attacks to break the linkability of transactions.

Incident Response

Discovery Time (DT): The time it took maintainers to discover the attack and trigger the corresponding incident response mechanism. Given that this information is internal to each team, we contacted each of the 14 projects and asked them to provide us with data.

Communication Time (CT): Time taken by maintainers to communicate the exploit to the community. This communication was performed solely as Tweets. This value is the difference between the timestamp of the Tweet and the timestamp of the first exploit transaction.

Location

Vulnerability Location (VL): We identify the location of each vulnerability: in the Source Chain Smart Contract — the component with the bridging logic in the source chain, is responsible for escrowing funds; in the Target Chain Smart Contract — the element with the bridging logic in the source chain, responsible for verifying inclusion proofs; or in the Interoperability Mechanism — the off-chain component that enables interoperability, usually composed of validators/relayers.

Exploit Location (EL): A vulnerability in one location can originate exploits in others. We classify the location of the exploit as follows: in the Source Chain Smart Contract if the attacker stole escrowed funds; in the Target Chain Smart Contract if the attacker minted unbacked funds; or in the Business Logic Smart Contract if the attacker stole funds by exploiting the business logic contract — usually because users approved a bridge-controlled contract to manage their funds (e.g., through the approve() function in the ERC20 token standard).

Mapping to Theoretical Vulnerabilities

We present the theoretical vulnerabilities found in cross-chain hacks. These are further used in the table below.

• Incorrect event verification (V6): Events emitted on blockchains drive interoperability. The incorrect verification of events might cause the bridge to validate transactions on the target chain based on forged source chain events (or vice versa).
• Insecure access control (V24): With the rapid evolution of decentralized applications’ development, the complexity of such apps has increased exponentially. However, the absence of access control policies when accessing certain functionalities (e.g., usually implemented as smart contracts) has originated multiple attacks in these components.
• Unsafe third-party modules (V27): As usual in software development, code relies on third-party modules or libraries. These libraries can insert vulnerabilities into the codebase, which may weaken the source code.
• Dead code (V28): A noteworthy vulnerability behind the Qubit and Multichain hack is the presence of dead code within the deployed smart contracts, allowing attackers to execute malicious operations.
• Inadequate key management (V43): The compromise of cryptographic keys is one of the main sources of hacks in cross-chain bridges. Even worse than compromising a single key, is compromising multiple keys, which has happened more than once.
• Physical infrastructure backdoors (V44): Infrastructure backdoors create numerous potential attack vectors, such as reaching blockchain nodes through the RPC or HTTP ports which can be used to transmit malicious transactions or perform DDoS attacks.

• $1.6B (55%) of stolen funds originated in the operational layer (e.g., inadequate key management practices).
• 65.8% of the total value stolen originated in bridges based on intermediary permissioned networks.
• Only $35M were returned by white hats (1.5%). There is a lack of incentives to disclose vulnerabilities.
• Transaction mixers were used 5 times before a hack (35.7%) and 11 times afterward (78.6%) to launder funds.
• Funds are stolen from smart contracts. However, multiple vulnerabilities were found off-chain (see column ‘VL’).
• The lock-mint pattern in cross-chain bridges is riskier than others (e.g., burn-mint used with native tokens). 62% of the total value stolen was drained from the escrow.
• Several attacks were performed using multiple transactions (both external and internal). Setting withdrawal limits on-chain would reduce this value.
• Two teams took 5 and 13 minutes to detect the incidents. The Ronin bridge team took 6 days. We emphasize the need for working on monitoring and attack detection mechanisms.

🔍 The evidence suggests that cross-chain hacks are unlikely to cease anytime soon. Despite the significant risks involved, there is a noticeable lack of public research on the topic beyond individual team efforts. Our current understanding indicates that these efforts are insufficient, given the substantial value at stake.

💰 Investment in protocol security is imperative. There is a pressing need for new research to address the specific requirements of these protocols. Innovative solutions are essential for effective monitoring and swift incident response.

📢 Stay tuned for updates on our research and plans to contribute to this critical area. Together, we can enhance the security of cross-chain protocols and mitigate the risks associated with blockchain interoperability.

Access the paper below👇👇👇