WazirX Background Information

WazirX is an cryptocurrency exchange primarily based in India with an ambiguous origin story that ties to the now-infamous Binance exchange (see: ChangpengZhao prison sentence). If you're interested to learn more about the connection between Binance and WazirX, feel free to use Google, Twitter, CoinTelegraph or any other resource that you consider to be a reliable dispenser of truth because this analysis is purely technical.

Any additional banal / circumstantial information that gets included in this write-up will be done purely for informational purposes to enhance the reader's overall understanding of the exploit that occurred last month (July 18th) that drained ~$230 million worth of cryptocurrency from WazirX's smart contract orchestration.

How Did WazirX Store Their User's Funds?

Without wasting any time, we're going to get right down to business here and explore exactly how WazirX was holding/managing user funds from both a fundamental and technical perspective.

How Can This be Both Technical & Fundamental?

We can glean certain information about the custodial practices of WazirX by simply analyzing the related smart contracts in their orchestration as well as associated on-chain data. However, our understanding will also be supplemented by additional information given to us through WazirX's public communications following the hack (i.e., Liminal being a 3rd-party custodian with a unique key whose signatures contributed to the multi-signature threshold necessary to confirm transactions or how the keys that were responsible for signing in WazirX's possession were managed in a mutually independent manner among the team members).

Before we begin dissecting the actual smart contract orchestration and security protocol implemented by WazirX to ensure the safe custody of their user's funds, this analysis declares (and hopefully debunks) the following proposed "possibilities" to be unequivocally false:

1. The Hack Was an Inside Job - This analysis unequivocally rejects the notion that this hack was an inside job due to its complexity, lack of apparent motive on the part of the exchange owners (apart from the obvious $230 million), as well as efforts made on their part post-hack to rectify the situation (whether these attempts have gained favor with the exchange's customers or not). At face value, we've never seen an 'exit scam' perpetuated in the manner WazirX was deprived of $230 million of its customer funds. Also, the assumed post-hack consultation with India's relevant governance and police authorities, cash-bounty reward offer and divulgence of intimate details of the exchange's security protocol for handling the custody of user funds lends additional credence to the notion that this was not an inside job. Additionally, the hack that was executed was so complex in nature, its (respectfully) questionable whether anyone on WazirX's team possesses the capability of orchestrating such a heist. As we dig into the minutiae of this compromise, that statement I made in the prior sentence will be understood on an increasingly greater level.

2. The Team / Liminal Mishandled Their Keys - Another theory that's floated around is that the team mishandled their keys in some way. Although it seems that there are few proponents of this theory on social media and elsewhere at this point in time. Also, WazirX recently published a press release on their site affirming that they each 'signer' responsible for authorizing transactions on the Ethereum blockchain on WazirX's team had their devices independently audited by a cybersecurity firm (Mandiant), whom certified that no team member's device was compromised at or before the time of the actual theft of customer funds from the exchange's Ethereum smart contract orchestration.

3. The Team SIgned a 'Bad' Transaction - This is one of the most popular (if not prevailing) theories out right now. Essentially, this theory asserts that a bad actor crafted a malicious transaction which included additional / erroneous data and submitted it to the WazirX exchange to be signed. As the theory goes, the team - unbeknownst to them - ended up signing the malicious transaction, inadvertently granting ownership-level privileges or authorization to the bad actor that crafted the transaction. This allowed the bad actor to gain illicit authorization over WazirX's smart contract orchestration, fulfilling a critical pre-requisite for the hack and subsequent appropriation of user funds. The issue with this theory is that it is entirely unsupported by on-chain data. After careful examination of several dozen or hundred transactions leading up to the hack, associated emitted events & function calls and the mandated dynamic/static fields encapsulated within those function signatures in the ultimate signed transaction, there is no credence to the idea that the team was bamboozled with a maliciously crafted transaction that simply snuck by under their noses. This rejection also extends to the notion that the team visited a site with malicious javascript embedded within that triggered a signature authorization workflow that they were tricked into signing (whether by virtue of effective 'phishing' or otherwise).

If we take a closer look at the contract deployments by the WazirX team, we'll see that the contracts in which they were in contact with were either deployed or owned by the Safe team itself.

This is evidenced on their site here.

The screenshot above comes directly from the Safe website (linked above). On their site, at the top of that page they state that, "this page lists all of the safe contracts v1.3.0." Notably, there are 3 contracts that we highlighted here.

Those contracts are:

• 0xf48f2B2d2a534e402487b3ee7C18c33Aec0Fe5e4

• 0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552

• 0x3E5c63644E683549055b9Be8653de26E0B4CD36E

For those that have been following the hack to some extent, you'll likely recognize at least two of those three contracts. The first one (0xf48), is the designated fallback handler for the WazirX main proxy (0x27). The second one is the implementation proxy (0xd9Db) associated with their main proxy (0x27).

Studying the Creation of the WazirX Proxy Contract Address

Let's begin by reviewing the transaction that led to the creation of the initial WazirX proxy in the first place. That transaction can be found here.

For more technically inclined readers or those well-versed with deciphering Ethereum/EVM-based transactions, I included the full transaction trace here in a gist. [credit to Tenderly for providing the RPC to pull the TX trace from]

If we check out the logs panel on Etherscan, we'll see a lot of relevant information displayed there for us that we're going to come back and reference shortly.

Just in case you didn't catch it in the screenshots above, here's what you need to know.

The designated owners of this contract from its inception were/are:

• 0xfA54B4085811aef6ACf47D51B05FdA188DEAe28b

• 0x9AF78003CecC2383d9D576A49c0C6b17fc34Ae34

• 0xD83b89E261D02B0f2f9E384B44907f8d380E9AF0

• 0x10F16CdE93f1bC9C38a9e31C8DB0eEb89a744824

• 0xaE648f68823bc164CA3ad1f5f5dC0057d9d515aD The fallback handler for this contract is: 0xf48f2B2d2a534e402487b3ee7C18c33Aec0Fe5e4 The singleton (implementation proxy) is: 0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552 The main proxy (unique) that was created from this transaction was: 0x27fD43BABfbe83a81d14665b1a6fB8030A60C9b4

That proxy address is the smart contract known as 'WazirX 2' on Etherscan and is the infamous address associated with the ~$230 million theft of funds from the exchange. The transaction that we just looked at took place on December 7th, 2022.

If we fast forward just a few short months later, we can see that there was another owner added to the contract and the threshold for the multi-signatures was adjusted upward from '3' to '4'.

That transaction can be found here.

Worthy of note here is the fact that the transaction was initiated by an account that was already designated as one of the original owners of the WazirX main proxy implementation (0x27fD).

Heading to the transaction logs, we can see the following:

The 0xd9671 EOA (external owned account; not a smart contract), addition as an owner occurred simultaneously with the increase in the smart contract's multi-signature threshold from 3 to 4.

At the time of writing (nearly a month and a half after the attack), the team has yet to state that this was an erroneous or malicious addition. The idea that the transaction was legitimate is even further reinforced by the fact that said transaction was brought to the attention of the exchange on social media by a user named 'TruthLabs' here.

Curiously, the exchange provided a response to the thread that this user posted that acknowledged the multi-signature structure of the wallet (specifically the requirement that there be 4 signers for each transaction; a fact only made true by the same transaction that added the 0xd9671 smart contract address).

The exchange's response can be found here (also their response and the entire thread has been archived permanently here).

That response is re-posted below for convenience:

Of note is the exchange's declaration that "While any 4 keys are needed, ever since we moved to Liminal, it has always been 3 separate WazirX key holders and 1 Liminal signing all of the transactions on the ETH wallet that was attacked. Even the malicious transaction that led to the attack was signed by 3 separate WazirX signers and 1 Liminal signer and this data is provable from the signatures made on those transactions."

Why This is Worth Mentioning

For some reason, certain block explorers have decided to label the 0xd967 address as the exploiter itself. But this is grossly inaccurate.

The screenshot above is from the Phalcon block explorer. They decided to label this address as 'WazirX exploiter' for some erroneous reason.

To understand how the compromise took place, we need to operate off of a few assumptions first:

• None of the keys in the multi-signature setup that the team had were compromised at any point in time.

• We must examine the smart contract(s) associated with WazirX's proxy upgradable deployment to gain a true understanding of what happened here.

• This attack was not an inside job. Although, we can never rule this out entirely - the complexity of this hack strongly suggests that some outside group or threat actor was responsible for compromising WazirX. Many have suggested that the North Korean threat actor group 'Lazarus' was responsible. This is plausible, if not likely when considering the nature of the attack (i.e., how it was orchestrated).