Decentralized case: Nomad hack 1–2–3 explanation
The recent Nomad’s massive hack has made a lot of buzz and sparked a wave of discussions on social media. Different opinions and viewpoints have created a bit of confusion in the cryptocurrency community. Who are the Nomad and what really happened? Why is the Nomad case important? And at last, what might this case teach us?
In this article we’ve tried to explain the Nomad case as simply and step by step as possible, answering key questions along the way. So, let’s begin.
What is Nomad?
Nomad is an interoperability protocol for cross-chain messaging, on which a native multichain bridge for communication between blockchains is built. At the time of the hack it was interoperating with 5 networks: Etherium, Evmos, Milkomedia, Avalanche and Moonbeam.
What happened?
On 01 Aug, 2022 attackers drained almost all liquidity from Nomad protocol — about ~$190M. At the time of writing this article, protocol TVL according to Defillama is about ~$97K (some increase since the attack).
Source — Defillama
Why the hack became possible
In Nomad Replica.sol smart contract there was a process function vulnerability: trusted root was not initialized, its value was 0x00.
Under normal circumstances, trusted root should be initialized for the appropriate check processes. So, it became possible to bypass the message verification. To be more exact, the verification was just “broken”: due to lack of initialization of the trusted root, any message appeared as a “trusted source”, i.e. verified.
Step by step implementation of the hack events
So, a “pathfinder” hacker discovered a vulnerability and exploited it — drained 60K DAI stable coins from the bridge contract.
An input data which was used to perform an attack. Source
Further, other dishonest people got involved in the process of withdrawing tokens from Nomad. By using the original hacker’s transaction calldata and replacing it’s data with a custom one, the attackers were able to empty the bridge’s assets quite quickly. However, despite numerous suggestions about a simple Ctrl+C — Ctrl+V process implementation, it was not enough just to copy and paste other’s input data, the attackers had to figure out how the data is encoded and processed.
What about an audit?
The compromised Replica.sol contract was audited by Quantstamp, a fairly well-known auditing company. The audit report can be seen here. This audit was conducted 2 months before the incident — 6 June, 2022. So how come the vulnerability wasn’t spotted?
There are 2 main theories often expressed in the cryptocurrency community at the moment:
- Quantstamp didn’t notice the vulnerability
- Quantstamp noticed the vulnerability and told Nomad about it, but the project team didn’t listen to the auditors’ advice.
Let’s examine these versions in detail.
So, the audit report contains item QSP-19: Proving With An Empty Leaf.
Source — Nomad audit by Quantstamp
Here we can see version 2: some people think that this paragraph is actually referring to a vulnerability which was dismissed by Nomad. If you are observant, you can see that this vulnerability is assigned a low risk level. Could it be that Quantstamp misjudged the risk level?
A closer look reveals that this item refers to a different function — prove. Version 2 falls away. HOWEVER: conceptually, the vulnerability of the process function belongs to the same type as the prove vulnerability. At the same time, the report does not say a word about it. We can see version 1 here: Quantstamp somehow missed the process vulnerability (while noting the prove vulnerability).
So we have a vulnerability that is not mentioned in the audit report, although it mentions a similar vulnerability that is assigned with a low risk level. And we know that the vulnerability led to the devastation of Nomad’s assets. What is going on? Was it an audit omission or not?
Actually, Quantstamp did a qualitative job. The reason the hack became possible is the Replica.sol contract deploy mistakes, and the deploy process is usually not something that audit companies are involved in.
The bug is indeed identical to the one mentioned in their Quantstamp audit. Moreover, this vulnerability does have a low risk level — as long as the trusted root initialisation process goes correctly. The problem lies in the fact that in Nomad’s case, this process apparently did not go as it was intended. It was Nomad’s negligence that caused the low level risk to become highly critical.
Why is the Nomad case important?
Why is this attack significant, besides the large amount of money stolen? There are two main reasons:
This incident can confidently be called a decentralized attack. Multiple attackers carried out the malicious activity at least partially independently from each other.
This attack was relatively easy to implement. One did not need to be a very advanced hacker. It was quite enough to appear in the right place at the right time, have a crypto wallet, to know solidity logic and perform a few quick and rather primitive hacking actions.
What we can learn from the Nomad case
There are fairly obvious conclusions we can draw from this sad situation.
- There is no such thing as a “completely safe bridge”. Nomad is a good project reputationally, and it didn’t save it from losing huge amounts of money.
- Small issues can turn into big problems with dire consequences if the original logic of code processes is disturbed by carelessness. An auditing company can be very competent when parsing the code but one shouldn’t be relaxed and forget that the project itself is responsible for the deployment as well as for the final result.
- A large-scale hack of a well-known project with large losses can be based on a fairly primitive action that a non-expert hacker could have easily done. One should always be on the alert and keep in mind how changes in code will affect the overall picture of the project’s architecture logic
Recommended: Detailed technical description of Nomad vulnerability and hacker scenarios by SmartState tech team is available here.
Stay tuned and find out more about us and what we provide on our:
