TLDR
- The paper reviews recent exploits on bridges, providing a concise reference for the exploits.
- Exploits are described in generality, reference the specific issue, and are complemented by mitigation strategies when possible.
Core Research Question
How did previous blockchain bridges get exploited?
Citation
Sung-Shine Lee, Alexandr Murashkin, Martin Derka, Jan Gorzny: SoK: Not Quite Water Under the Bridge: Review of Cross-Chain Bridge Hacks. CoRR abs/2210.16209 (2022)
Background
Bridges are systems to “move” data or digital assets from one blockchain to another. These systems have complex and varied implementations, involving both on-chain and off-chain components. Since digital assets cannot actually be moved from one chain to another, these systems must lock assets on one chain and mint or release representative assets on another chain. The result is a large surface area for attacks and various technical approaches to solving this problem.
In recent months, various such systems have been exploited to the tune of over $1 billion USD.
This arises from the complexity of both straightforward cross-chain asset transfers and the ability to support advanced features like cross-chain function calls. As a result, it is difficult to determine what to avoid for future bridge implementations; no single reference exists. Instead, developers and auditors need to be aware of previous exploits and find the specifics of them online in various disparate blog posts to avoid the same pitfalls. This is made even more confusing as there is no standard terminology for these systems as their components.
Important terminology used and introduced by the paper:
- Bridges: Bridges are complex, cross-chain systems that “move” digital assets or data from one blockchain or distributed ledger to another.
- Source Chain: A blockchain where a bridge transaction originates.
- Destination Chain: A blockchain where a bridge transaction terminates.
- Custodian: A (smart-contract based) system on the source chain that receives and holds an asset on the source blockchain (a.k.a. “debt”).
- Debt Issuer: A (smart-contract based) system on the destination chain that issues representations of an asset on the source blockchain (a.k.a. “debt”).
- Communicator: An off-chain component which passess messages between the Custodian and Debt Issuer.
Summary
- Several key components, like the key terminology above, are identified and defined. They enable a common language to discuss various aspects of bridges, including which parts failed in specific instances. The relationships between these components are also defined.
- Previous exploits are summarized in the context of the language above. Each exploit is categorized according to the primary component exploited within the bridge. Each exploit is first described at a high level and then described at the implementation level. Exploit descriptions are sourced from disparate post-mortem blog posts but are cleaned up to use consistent language and focus on the relevant parts, and are complemented by techniques to mitigate the exploit whenever possible.
- In all cases where real-world examples are used, exploits and issues are reported not to defame or insult the relevant projects, but to add legitimacy to the issues and to enable researchers to find exploits based on project names. In some cases, bridge operators were able to correct issues prior to their exploitation, and secure the bridges before any harm was done. These efforts are also described when relevant.
- Three custodian-based exploits are described: the PolyNetwork Bridge exploit, Polygon/Matic Ethereum/Plasma Bridge, and the Meter Bridge.
- One debt-issuer based exploit is described: the Wormhole Bridge.
- One real-world communicator based exploit is described: the pNetwork pBTC-on-BSC Bridge. Another hypothetical attack, for proof-of-work chains, is described.
- Two exploits based primarily on the interfaces of (ERC-20) tokens supported by bridges are also described: an early version of the Multichain Bridge and the Polygon Bridge Zap.
- A collection of related work is presented, though none provide a concise reference handbook for prior attacks like the work summarized here. Nonetheless, they may provide other interesting models and analyses of bridges and their components.
Method
- Each real world example has its own subsection within the section dealing with the primary component of the bridge exploited. Within each subsection, an introduction to how the exploit could be problematic is provided, before describing the generalized approach to the exploit. This generalized approach includes a description of the assumptions required to execute the exploit and the steps necessary to exploit the bridge component under these assumptions.
- The description follows post mortem blog posts found online. These sources are the exploited bridge project blogs or security researchers who studied the exploits. The relevant details from the post mortem are included in the paper, along with links to the sources. Relevant details have been distilled to focus on the key problems for each exploit. Diagrams are included in order to help readers follow the exploit. This provides a concise reference to understand the exploits included in the paper.
- One exploit for bridges on Proof-of-Work chains is hypothetical. For this exploit, we provide an analysis for the exploit’s feasibility.
- In all cases, exploits are complemented by mitigating strategies. Often, these are specific things to check for in the smart contract implementations of the bridges, but also include more general strategies for bridge feature design when possible.
Results
- The PolyNetwork Bridge’s custodian exploit is described. This exploit occurred because the bridge supported cross-chain function calls and did not properly check the caller when such calls were made. Critically, a clever attacker was able to fool the bridge’s custodian into passing a call onto the destination chain that changed the privileged actors of the bridge’s debt issuer. This occurred due to a partial hash collision of the Ethereum function selector and the ability to “replay” signed messages on the destination change.
- Next, the authors summarize how the Polygon/Matic Ethereum/Plasma Bridge’s custodian could have been exploited. In this case, the exploit was possible because the “proof-of-burn”, a token given to an actor, was not correctly verified by the bridge’s custodian contract. As a result, these tokens could be modified partially and resubmitted, resulting in actors being able to withdraw more from the custodian than they were originally entitled to. The issue was detected and patched before the exploit was executed.
- The Meter Bridge exploit is also studied. This is exploit was a result of the bridge custodian handling so-called “wrapped” assets differently than “unwrapped” assets. This implementation-level error resulted in the custodian emitting events (which were in turn picked up by the bridge’s relayer and sent to the debt issuer) in all cases, but only transferring a user’s funds to the custodian in the wrapped asset case.
- One debt-issuer based exploit is described: the Wormhole Bridge exploit. In this situation, the debt issuer was constructed in such a way as to allow custom verification logic for the messages it received from the bridge’s relayer. This exploit occurred because such logic was able to be replaced with logic that accepted any message as valid. As a result, attackers were able to withdraw more funds from the debt issuer than they were entitled to, and could then bridge the asset back to the source chain.
- One real-world communicator based exploit is described: the pNetwork pBTC-on-BSC Bridge. This exploit occurred because the communicator was watching for all events with a particular name, but without regard for the contract that emitted the event. An attacker was able to call the custodian’s deposit function via a smart contract call which mimicked the events emitted. The communicator observed both the real and imitated events, and signaled the debt issuer to issue debt for all events, not just the real ones.
- Another hypothetical attack, for proof-of-work chains, is described. This exploit relies on a short-term 51% attack on an underlying source chain. The exploit describes a method by which a bridge that does not carefully pay attention to chain re-orgs may be problematic in the event that a malicious actor can muster the resources to acquire 51% of the chain’s hash power for a couple of hours.
- Next, the paper turns to exploits that target interfaces of (ERC-20) tokens supported by bridges. The first example is an exploit of an early version of the Multichain Bridge. Honest users would often provide an “infinite approval” of ERC-20 tokens to bridge custodians, in order to save gas an allow the custodian to transfer tokens at the user’s request. However, an attacker exploited the fact that this bridge could make arbitrary function calls, and made a call to “transferFrom” on ERC-20 tokens from honest users who provided an infinite approval. Since the bridge itself was calling the function, and it had been approved, the attacker was able to take these funds from honest users.
- Finally, the Polygon Bridge Zap exploit is also described. This exploit is also a result of the supported token interfaces. In this case, some ERC-20 tokens supported optional functionality of EIP-2612, which enables token holders to hand out “permits” for others to spend their tokens. However, if other ERC-20 tokens have a fallback function that never reverts – that is, the default function called by Ethereum, and it never fails to execute, there may be problems for the bridge’s users. In this case, attackers exploited an ERC-20 token with a non-reverting fallback function and a bridge that supported the use of permits. The attacker would claim to have a permit for a ERC-20 token that did not support the permit functionality, so the non-reverting fallback function would succeed, and the bridge understood that it incorrectly had the right to spend funds on behalf of the attacker.
Discussion and Key Takeaways
- The exploits described above are naturally categorized into the component whose failure resulted in an exploit. These components appear across all the bridges studied, and the language above can be used to discuss bridge architecture with ease.
- The previous findings are crucial to understand when developing and reviewing new bridges. Each component of a bridge introduces a large surface area for exploitation and these findings can ensure that the issues of the past are not repeated.
Implications and Follow-Ups
- Additional exploits could be studied and collected. Unfortunately, these systems continue to be exploited, and the paper is incomplete with respect to the most recent issues.
- Additional preventative measures could be studied. Some attacks are implementation dependent, but others may be avoided by a framework or set of standards. As mentioned in the paper, custodian or debt issuer standards may reduce errors with cross-chain calls or decrease erroneous event emissions. Such standards could be similar to the ERC-20 or ERC-721 standards.
- The development of a wishlist of specific properties for security would guide new developers, auditors, and end-users. This would avoid the case where attacks listed in this paper fade into obscurity and become unknown to new community members.
Applicability
This work describes these real-world exploits in a consistent language categorized according to the main component exploited. Exploit descriptions are sourced from various post-mortem blog posts and are cleaned up to use focus on the relevant parts, and are complemented by techniques to mitigate the exploit whenever possible. The result is a handbook that can be used by auditors to look for specific attack vectors and developers to avoid the pitfalls of the past. This work may also be particularly valuable in guiding future tooling to detect issues within bridge codebases automatically. As Ethereum (and other blockchains) move toward a rollup-centric future, the number of bridges will increase. It is important that these bridges do not repeat the failures of the past.