Bridges are becoming more and more crucial for connecting different blockchains together.
Why should a bridge be audited?
Extremely lucrative targets for crypto hackers are the Bridges.. More than $1.6 billion were stolen only in 2022. This, in combination with the inherent complexity involved in coding a bridge, makes auditing an indispensable part of the implementation process. We help other companies to become more secure by conducting penetration tests, which are a crucial part of a complete security audit. Smart contract auditing is a specialized part of security auditing designed for the blockchain-oriented code of a modern web3, decentralized or dapp application. The auditing process is intended to ensure that once the immutable contract is implemented on the blockchain, it can only do what it is intended to do. Bridges present an even more specialized case for auditors, as they contain code components in both chains, as well as an off-chain component. Millions of dollars in shoddy bridge tokens will likely continue to be drained if suitable security measures are not taken and auditing is not implemented in this area of web3 development.
Step-by-step guide to auditing a bridge
Learn about architecture
Naturally, the audit requires invoking the mindset of a white hat hacker of looking for vulnerabilities and ways to attack the contract in the same way that a black hat hacker would. The most important part before deciding how to approach a bridge attack is to understand your security model. In the most general sense, bridges can be trusted or trusted . The trust model, or centralized bridge, is based on a governance component that can ultimately decide how much money moves from one chain to another. Each request to move money between chains is approved by a different consensus method in a Trust or Decentralized Bridge. When deciding how to hack, or for our purposes, audit, this bridge, this section is crucial. While a centralized bridge may be considered unworthy by many in the crypto community, due to its reliance on a single entity, the security complications that come with maintaining a completely separate consensus mechanism do not leave untrusted bridges without their own warnings.
Key management
Who controls the keys? Because if that's not safe, nothing is, as we've seen with the Ronin hack. Even if the consensus is distributed among several different entities, we have to consider how easy it would be to seize control and how far someone would be willing to go to do so.
Validator architecture
There are no or only a few governing bodies for decentralised bridges, therefore the attention is solely on the validity of the validators, who they are, what the consensus method is, who may join, how peer-to-peer communication between validators is carried out, etc.
Understand the code base
After delving into the basic architecture, whether it's trusted or not, and who has control of the protocol keys, we can discuss the components of the codebase.Reading the developers' documentation is the first thing to do. A good bridge development team must document every change due to the inherent complexity of the task. If possible, talk to the team and try to reduce the feedback loop later by answering the questions live.
Contract deployment scripts are perhaps one of the most important parts of the audit; Please read them 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 don't deploy anything to a public mainnet or testnet during an audit.
Next, take a look at the tests provided by the developers. They can help you better understand the code base, but also further test your own exploit and vulnerability tests. You don't have to reinvent the wheel! If you have tests with setups and teardowns, you can simply copy a test, change it, and create your own.
Finally, and most importantly when reviewing a bridge, comes the review of the end-to-end transaction flow: understanding how exactly money flows from chain A to chain B. The real vulnerabilities of bridges are found here. , and where the eyes of hackers are as well. This, of course, requires a deeper look at the contract code itself, as well as starting to use various open source tools to help list code and scan for vulnerabilities.
Audit tools
Understanding the structure of contracts and the functions within them can be greatly aided by the creation of a function call graph.
Given that many of the most well-known and reputable blockchain projects base their code on top of other open source projects, tools that allow differential analysis are also very helpful for smart contract audits. If a core codebase that has been audited multiple times by industry leaders is used in another project, although that doesn't mean it can't be hacked, we can assume it's relatively safe and focus our auditing efforts on the code parts that actually changed between the two projects. More and more, we see clients where they find serious vulnerabilities just in the diff. That's why they developed an in-house tool called smart diff, which checks the source code of smart contracts and is based on the Etherscan and Diffchecker APIs.
Automated scanners are our friends as auditors to find the “low-hanging fruit.” The most used tool is swipe . O emphasizes the importance of the approach to running the vulnerability scanner: don't just run the tool and hope there are 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 format option to .json, which makes it relatively easy to filter and list specific tasks for your audit.
Another area to check is chain events and errors. Analyzing these event logs in a block explorer like etherscan is a great way to understand edge cases in smart contract code. Often a single error code is not a cause for concern, but if the same error occurs over and over again, you need to start investigating the pattern and understand why it is behaving badly.
The last step in the process is the manual audit. Review all your notes and all the information collected so far. When looking at a large contract system as a bridge, try to avoid going too deep into analyzing specific paths, because you can spend days looking for vulnerabilities in what ends up being a dead end. Try to go further and find all possible exploits in the time frame you have rather than dig deeper.
Even after the audit stage, it is important to monitor contract events post-deployment to detect and respond to any attacks, and to ensure that the events generally correspond to expected behavior.
0
