One Key to Rule the Wormchain: Wormhole Vulnerability Disclosure

Disclaimer: This article discusses a vulnerability disclosure related to Wormhole. Marco Nunes is publishing this information as part of his company’s security research work and is not affiliated with, endorsed by, or sponsored by Wormhole. This research was conducted independently and facilitated through the Immunefi bug bounty platform. A bug bounty reward was received for the responsible disclosure of this vulnerability.

➤ Reported on: January 15, 2024
➤ Reported severity: Critical
➤ Accepted severity: High
➤ Mediation rounds: 2
➤ Reward: $50,000 (USDC)

First, I want to tell you why this submission is special to me. I have a whole blockchain and offensive security background that ended up going dark due to the contractual and OPSEC requirements of the professional rabbit holes I went down, all perfectly aligned with white hat ethics, but just more private than the average, which made it easy to forget the public hustle and sharing that I love for some time. And this submission is dear to me because, besides a couple of contests that I really committed to and had good results, it marked one of my first shots in this public security arena.

As for the vulnerability? It’s a very simple one. That said, it shows that paying extra attention to the simple things can literally pay off, as I was able to catch a vulnerability that had been lurking for a couple of years.

Enter Wormhole

Wormhole relies on a set of Guardians that observe cross-chain messages and sign their payloads so they can traverse chains. The packets containing cross-chain data and the Guardians’ signatures attesting to that data are called Verified Action Approvals (VAAs).

For VAAs to be valid, they must be signed by a quorum of 2/3 of the current Guardian set. Being a total of 19 Guardians, this means that at least 13 Guardians (rounded up) must sign VAAs before their payloads are considered valid to be executed on the destination chain.

The Guardians are grouped into Guardian sets that may change over time as a result of governance operations. When I found this vulnerability, the Guardian set index was 2, counting from zero. Each Guardian set also has an expiration time, where zero generally means non-expired. The zero expiration time is used for the current Guardian set and a different value is eventually set to define an expiration when setting a new Guardian set.

As an interoperability protocol, there are lots of moving parts and nuance we are ignoring for now. But this is all you need to know to keep exploring this vulnerability with me.

The Wormchain Vulnerability

The Wormchain is a blockchain built using the Cosmos SDK and CosmWasm, serving as a gateway connecting the IBC-powered Cosmos ecosystem to the Ethereum, Solana, and many other chains.

And, straight to the point, here’s the Wormchain code to decide if a Guardian set is expired or not as part of their VAA verification logic:go

[... SNIP ...]
if 0 < guardianSet.ExpirationTime && guardianSet.ExpirationTime < uint64(ctx.BlockTime().Unix()) {
    return 0, nil, types.ErrGuardianSetExpired
}
[... SNIP ...]

// Source: https://github.com/wormhole-foundation/wormhole/blob/v2.23.32/wormchain/x/wormhole/keeper/vaa.go#L36C1-L38C3

Cool, so if the Guardian set that signed the VAA has an expiration time greater than zero, their expiration time must be less than the current block time uint64 representation (i.e., uint64(ctx.BlockTime().Unix())). Makes sense, right? This ensures the current Guardian set doesn’t need a set expiration time, while any past Guardian sets can be expired by having their ExpirationTime set. But...

$ ./wormchaind q wormhole show-guardian-set 0
GuardianSet:
  expirationTime: "0"
  index: 0
  keys:
  - WMw65cCXshPOPIGXnhuflXB0aqU=
$ ./wormchaind q wormhole show-guardian-set 1
GuardianSet:
  expirationTime: "0"
  index: 1
  keys:
  - WMw65cCXshPOPIGXnhuflXB0aqU=

That’s what the Wormchain node shows when querying the first two Guardian sets.

Do you see what I saw, anon?

Yeah, that’s it. That simple.

The first two Guardian sets, both with the same key WMw65cCXshPOPIGXnhuflXB0aqU= (let’s call it genesis key), were never expired. In combination with the Wormchain’s VAA verification logic, this means that instead of 13 keys you just need ONE specific key to pass any VAAs on Wormchain. This breaks the Guardian security model for Wormchain, which largely depends on a 13 of 19 quorum of reputable entities. This aligns with the “Critical – Governance manipulation” impact; an impact category that existed in their BBP at the time.

What was more interesting to discover is that the Wormhole team had already caught variants of this vulnerability on at least one other chain:rust

[... SNIP ...]
// IMPORTANT - this is a fix for mainnet wormhole
// The initial guardian set was never expired so we block it here.
if guardian_set.index == 0 && guardian_set.creation_time == 1628099186 {
    return Err(PostVAAGuardianSetExpired.into());
}
if guardian_set.expiration_time != 0
    && (guardian_set.expiration_time as i64) < clock.unix_timestamp
{
    return Err(PostVAAGuardianSetExpired.into());
}
[... SNIP ...]

// Source: https://github.com/wormhole-foundation/wormhole/blob/5fa8379b175f5d0353b825fae8efdb7ff3116466/solana/bridge/program/src/api/post_vaa.rs#L162C1-L171C6

A simple issue that had already been caught elsewhere. And yet, this one was there waiting for me.

Wait. But I don’t have the key, do I? Well, nothing that some good old social engineering won’t solve... Nah, I’m joking. Social engineering is out of scope and I don’t like prison food. I just wrote a simple PoC and reported it as “Critical – Governance manipulation”.

The team was quick to respond and confirmed with a fix in around 48 hours. They offered me a 50,000 USDC reward and downgraded the severity to High “as the attack can only be performed by a specific guardian”.The Wormhole team later informed that the key had been destroyed before the time of the report, and although I trust their technical and operational skills to conduct such operation to the highest standards possible, I don’t think that materially changes the fundamental uncertainty around whether the key was ever compromised before destruction. Nevertheless, this understandably changes the risk assessment from their side.

The Fix

The immediate fix was similarly simple:

-	if 0 < guardianSet.ExpirationTime && guardianSet.ExpirationTime < uint64(ctx.BlockTime().Unix()) {
+	latestGuardianSetIndex := k.GetLatestGuardianSetIndex(ctx)
+
+	if guardianSet.Index != latestGuardianSetIndex && guardianSet.ExpirationTime < uint64(ctx.BlockTime().Unix()) {
        return 0, nil, types.ErrGuardianSetExpired
    }

// Source: https://github.com/wormhole-foundation/wormhole/pull/3714/files

Mediation

I requested mediation because I believed it was fair to maintain the Critical severity for my submission. The first mediation round confirmed the Critical severity and recommended a reward of 100,000 USDC. A second round of mediation just changed the reward to 50,000 USDC to align with the BBP rules and didn’t challenge the severity. I argued to maintain the Critical severity despite accepting the reward as correct.

Looking back, there was a disagreement about severity classification. The Wormhole team stood by their High severity rating while I maintained that the feasibility limitation should affect the reward but not reduce the severity from Critical. Yes, maybe a bit vain to care about a severity label when the reward was fair, but it is what it is. In the end, I was tired and just wanted to receive the reward I agreed was correct, so I just stopped arguing. All things considered, I’m thankful to Immunefi and the Wormhole team. Maybe it’s just not the first thought in anybody’s head that a researcher may care so much about a “mere” Critical label in his stats without making any difference to the final reward.

Why the reward was correct but the severity wrong?

Of course, I want to prove I’m correct about the severity, even if seen as slightly vain ;).

The correct severity is Critical because the accepted impact is Governance Manipulation, which was listed as a Critical severity impact. But with a feasibility limitation of involving access to a privileged address. Here’s the Immunefi rule about feasibility limitations:

The impact of a bug is calculated before, and separately from, feasibility limitations. Feasibility limitations only change how much a project pays for a bug report.

So, a bug with a massive impact that is infeasible would still have that impact and severity, though it would be rewarded differently based on that infeasibility.

So, it’s evident that the severity should be the same I reported.

And what about the reward? Well, I agree it’s correct because their BBP clearly stated that there’s no minimum payout and:

Because of the governor, rewards for critical vulnerabilities are further capped at 10% of extractable value during a 24-hour period

You see, the Governor is a software that Guardians run to limit how much value can be extracted from a chain to another in a given timeframe. For Wormchain, which was the only chain affected by this vulnerability, it was, and still is, $500,000 during a 24-hour period. So 10% of that is $50,000.

One overlooked detail got me a $50k reward. Not a bad game.

Catch you on my next adventure.