Combating Bridge Attacks: A Closer Look at the Attackers’ Preparations
Intro
On Aug 1st, 2022 the Nomad bridge, a cross-chain bridge between Ethereum, Moonbeam, Avalanche, Evmos, and Milkomeda, was exploited, and approximately $190M in assets were stolen. For the technical details around how this attack unfolded, see Samczsun’s informative breakdown of the attack in his Twitter thread.
Usually, attack post-mortems focus on the attack itself and how a vulnerability was exploited. This form of analysis is extremely useful and helps builders in developing more robust and secure contracts and platforms. While we agree, we believe that it is equally as important to understand the activity that occurred before the hack itself, in order to develop insights around how bad actors prepare for attacks. Understanding an attacker’s behavior aids us in identifying attacks as early as possible, potentially before they are even executed.
Analysis
Before diving into the details of what happened, some context is needed.
The hack of the Nomad bridge originated from a vulnerability that was found in one of their core contracts called ‘Replica.sol’. This contract is used to facilitate cross-chain messaging. By exploiting the vulnerability, attackers can bypass the message verification process. This enables them to execute a process of sending tokens to a bridge contract on one chain and then choosing an arbitrary amount to withdraw on the other chain, allowing them to empty the funds held in the bridge contract. In order to execute this, the attacker would need to compile a smart contract with the exploit built-in, deploy it on-chain, and sign a transaction to set the attack in motion.
By mapping out the timeline of the incident, we can analyze the on-chain activity of the exploiters in their preparation for the attack and understand the relationship between the different addresses that were involved. In this case, there were three main addresses that initiated this attack - referred to herein as Exploiters A, B, & C. After these three main actors, more than 30 other exploiters noticed the malicious activity, understood what was happening, and followed suit by looting the bridge. We can separate this secondary set of behaviors from the premeditated attack played out by Exploiters A, B, and C. The secondary set of exploiters executed their attack by creating individual exploit transactions without deploying smart contracts in advance; some of them failed to do so, but all together, they managed to drain an additional worth of tens of millions of USD.
Timeline
The sequence of some notable events leading up to the attack is as follows:
Notes and associated links:
Deployment of the first malicious contract by Exploiter B (June 20th, at block 14995596 - 1 day before Nomad deployed their contract).
An hour before and during the exploit many other contacts used by the exploiters were also deployed.
This timeline suggests that attackers have their sights set on bridge projects and closely watch their Github repository for any code changes that may introduce exploitable vulnerabilities. The preparation activity of the three main exploiter addresses is aggregated below:
| Exploiter | Value stolen | Activity | | ------------------------------------------------------------------------------------------------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Exploiter A (main actor) | ~$47m | Interacted directly with the replica proxy and also used Exploiter B’s contracts in order to interact with the Nomad bridge contract. | | Exploiter B | ~$8m | Interacted directly with the proxy and created contracts that were also used by Exploiter A to call ‘process()’ and drain the contract. | | Exploiter C | ~$39.7m | Deployed more than 70 contracts, each one of them deployed another 10 relay contracts, that performed the same process and drained the bridge contract. We assume that the reason for this multiplication is to drain the funds faster and confuse the Nomad bridge security team. Another assumption is the multiplication aimed to avoid the bridge’s logic that could block a single user from reusing the exploit (see Paradigm Engineer #420). |
The Connection Between A,B and C
Based on the on-chain analysis of Exploiters A and B, we can infer that they are either the same actor or two entities working closely together.
Exploiter C didn’t interact with any of the contracts associated with Exploiters A or B and operated in a different manner; Exploiters A and B deployed one of the malicious contracts and started battletesting it about 30 days prior to the attack, while Exploiter C, although funded by Tornado.cash four days prior to the attack, deployed his malicious contract only on the day of the attack, and only after he tried several manual transactions through the first hour of the attack.
This suggests two options in regards to Exploiter C’s relationship to A and B:
All three exploiters are the same actor that utilized two different attack vectors to confuse the system and overwhelm first responders.
Exploiter C is not related to Exploiters A and B. Although Exploiter C seems to have been prepared ahead of time, he executed his plan only once he realized an attack on the bridge was taking place. It is plausible that the attack took place while Exploiter C was watching the bridge as he prepared for his own attack, and immediately joined in after spotting Exploiters A and B’s actions.
In Conclusion
This attack is a great example of how complicated code vulnerabilities can be hard to spot and that upgrades to proxy contracts can occur post-audit and can potentially introduce new vulnerabilities to the system. It also demonstrates well how attackers will often leave breadcrumbs when they prepare and act, and that their doing so gives us opportunities to identify attacks as they unfold and even before they are fully executed.
Moving Forward
Redefine’s strength lies in our ability to understand the behavior of bad actors and then to alert customers who are potential victims as quickly as possible to provide them with sufficient time to react to what is happening and save their funds.
Our flagship product, DeFirewall, assesses the risks of a transaction before the user signs it.
On the roadmap and currently being developed are two products that would have helped prevent many victims from losing funds in this attack:
Our Monitoring system identifies contracts that the user is exposed to (such as bridges, liquidity pools, etc) and notifies them of any relevant state changes (i.e. ownership changes, implementation contract upgrades, etc.) or general anomalous activity (such as dozens of unverified contracts interacting with it, as was the case here) that could result in funds being lost.
Our DeFi Dome actively mitigates risk by taking action to protect user funds. Again, looking at contracts that the user is exposed to, DeFi Dome monitors the mempool for all transactions that will interact with one of these contracts and identifies if they will result in user funds being lost (i.e. if the transaction is malicious). Based on the user’s configurations, if a relevant malicious transaction is identified, DeFi dome will be triggered and will submit a transaction to move the user’s funds to safety by frontrunning the malicious transaction.
Our DeFirewall is live in Beta, so if you’re active in the DeFi space you can already enjoy transacting safely. For a demo or to set up a call contact us!
,