Hacking Bridges

TL;DR Bridges play an increasingly important role in allowing various blockchains to communicate with one another. Sharing experience from both hands-on white-hat hacking and their newfound leadership in the field of web3 auditing, brothers and Sayfer founders Nir Duan (CEO) and Or Duan (CTO) presented at Israel Crypto Community (ICC) on 22/9/2022 on why bridges are so susceptible to attacks, how they get hacked, and what are the best approaches for a successful smart contract audit on a bridge.

Why Should A Bridge Be Audited?

Bridges are an extremely lucrative target for crypto hackers. More than $1.6b were stolen in 2022 alone. This in combination with the inherent complexity that comes with coding a bridge makes auditing an indispensable part of the deployment process.Sayfer helps other companies become more secure by performing penetration tests, which are a crucial part of a full security audit. Smart contract auditing is a specialized part of security auditing designed for the blockchain-facing code of a modern web3, decentralized application, or dapp. The auditing process aims to ensure that once the immutable contract is deployed on the blockchain, it can only do what it is intended to do. Bridges present an even more specialized case for auditors, since they contain code components in both chains, as well as an off-chain component. If proper security mindset and auditing will not be implemented in this realm of web3 development, it is very likely that millions of dollars in tokens will continue to be drained from poorly designed bridges.

Step-by-Step Guide to Auditing a Bridge

Learn About the Architecture

Naturally, auditing requires invoking the white-hat hacker mindset of looking for vulnerabilities and ways to attack the contract the same way a black-hat hacker would. The most important part before deciding how to approach attacking a bridge is to understand its security model. In the most general sense bridges can be trusted, or trustless. The trust model, or the centralized bridge, relies on one governing component which ultimately can decide how much money moves from one chain to another. In a trustless or decentralized bridge, there is a separate consensus mechanism, which validates each request to transfer the money between the chains. This part is extremely important when we decide how we are going to hack, or for our purposes, to audit this bridge. While a centralized bridge may be considered unworthy by many in the crypto community, due to their reliance on a single entity, the security complications that come with maintaining a whole separate consensus mechanism do not leave trustless bridges without their own caveats.

Key Management

Who controls the keys? Because if that’s not secure, nothing is, as we’ve seen with the Ronin hack. Even if the consensus is distributed between a number of different entities, we have to consider how easy it would be to take over, and just how far someone would be willing to go to do so.

Validator Architecture

When it comes to decentralized bridges, there is no one or few governing entities, so the focus is purely on the quality of the validators, who they are, what is the consensus mechanism, who can join it, how peer-to-peer communication between validators is done, etc.

Understanding the Code Base

After digging into the basic architecture, whether it is trusted or trustless, and who is in control of the keys to the protocol, we can look into the components of the code base. The first step is to read the documentation provided by the developers. A good bridge dev team should document every change due to the inherent complexity of the task. If possible, talk with the team, and try to reduce the feedback loop later down the line by getting questions answered live.

Contract deployment scripts are perhaps one of the most important parts of the audit; read those carefully, because sometimes vulnerabilities arise only from the deployment scripts, rather than directly from the smart contract. If you have the tools, run the scripts locally on your computer, but do not deploy anything on a public mainnet or testnet during an audit.

Next, look at the tests provided by the devs. They may help you better understand the code base, but also later on to try your own exploit and vulnerability testing. You don’t have to reinvent the wheel! If you have tests with setups and tear-downs, you can just copy a test, change it, and make up your own.

Finally, and most importantly when reviewing a bridge, comes reviewing the end-to-end transaction flow – understanding how exactly the money flows from chain A to chain B. This is where the real vulnerabilities in bridges lie, and where hacker’s eyes are as well. This of course requires a deeper look into the code of the contracts themselves as well as starting to use various open-source tools to help enumerate the code and scan for vulnerabilities.

Auditing Tools

Plotting a function call graph can be a great help in understanding the structure of the contracts and the functions inside them. surya by ConsenSys offers this functionality.

Tools that offer differential analysis are also very useful for contract auditing, on the premise that many of the most popular and reliable blockchain projects base their code on top of other open-source projects. If a major code base that’s been audited multiple times by industry leaders is used in another project, though it doesn’t mean it cannot be hacked, we can assume it’s relatively safe, and focus our auditing efforts on the parts of the code that actually changed between the two projects. More and more, Sayfer sees clients where they find serious vulnerabilities only in the diff. This is why they developed an in-house tool called smartdiffer, which compares smart contracts source code and relies on the APIs of Etherscan and Diffchecker.

Automated scanners are our friends as auditors for finding the “low hanging fruit.” The most commonly used tool is slither. Or stresses the importance of the approach to running the vulnerability scanner: don’t simply run the tool and hope for no red warnings. Treat it exactly as such – a tool. To help reduce noise from your output, use flags to exclude specific paths, dependencies or detectors from your scan. You can also use the output to .json format option, which makes it relatively easy to then filter and make a specific to-do list for your audit.

Another area to check is on-chain events and errors. Analyzing these event logs on a block explorer like etherscan is a great way to understand edge cases in smart contract code. Oftentimes, a single error code is not a reason to worry, but if the same error happens over and over again, you have to start investigating the pattern and understand why it’s misbehaving.

The last step of the process is the manual audit. Review all of your notes and all the information gathered so far. When looking at a big system of contracts like a bridge, try to avoid going too deep on analyzing specific paths, because you may be spending days searching for vulnerabilities in what ends up being a dead end. Try to go wide and find every possible exploit in the time frame you have rather than going on deep-dives.

Even after the audit stage, it is important to monitor the contracts for events after deployment to detect and respond to any attacks, and make sure that events in general correspond to the expected behavior.

After you learned these methodologies, watch the part where Nir and Or demonstrated a live challenge at the ICC on how to actually find the vulnerability in a code:

Summary

We hope this post gives you a better understanding of why bridges are getting attacked in the first place, some insight into our methodology and how we audit a specific bridge’s smart contract, and provide you with a real life example of an exploit. Watch the final part of the video for the Q&A: