Will we see the doomsday of Ethereum? What if a catastrophic vulnerability is discovered and exploited in the Ethereum network? Considering the security model of Ethereum, I don’t think that could happen. The execution of smart contracts and the consensus of the network are implemented in multiple independent software clients, a single flaw or discrepancy that affects a minority of the clients will be discarded by the network. Even if we see a nuclear-level bug that destroys all the Ethereum nodes, the community can always fork a new secured chain as the canonical Ethereum, like we have done in the DAO fork.

However, not all EVM compatible chains are guarded at the same security level and with the same decentralization as Ethereum. In fact, most “Ethereum killer” chains only have one single implementation of their protocol. The lack of diversity is the Achilles’ heel of public chains: if anything goes wrong in their official implementation, the giant will be knocked down easily.

A few months ago, I found a critical vulnerability in paritytech/frontier, an EVM implementation written in rust and mainly used in Polkadot parachains. When I was writing my previous blog post, I decided to take one more quick review of the code used in the Moonbeam network, in case I missed anything trivial but critical. My hacker instinct led me to a tricky integer truncation bug!

Frontier executes normal Ethereum smart contracts, but uses a Polkadot substrate as the ledger. This has a quirk: while balance amounts are 256 bit integers in normal Ethereum, the currency in the Polkadot substrate is only 128 bit. To convert to Polkadot, frontier truncates the 256 bit transfer balance amount to 128 bits. This is the code that handles value transferring in the frontier EVM:

Since the balance can never be greater than 128 bit, and the transfer will be validated by the balance substrate eventually, what could go wrong?

The key is that the transfer.value here, or msg.value in EVM, is a totally controlled 256 bit value provided by the user. If we pass (1 << 128) in the msg.value, T::Currency::transfer will do nothing because it’s transferring a truncated zero, and we’ll finish the EVM execution smoothly. We won’t get any extra balance by transferring the zero, but what if the giant untruncated msg.value is accepted by some contract that does give us credit? We could achieve the impossible and attack WETH to make it depeg!

The WETH contract allows users to deposit native ETH that users specify through msg.value. It stores this value internally after transferring the appropriate amount of tokens. Normally if you don’t have enough balance for the transfer, the transaction will be rejected or reverted. However, since we have bypassed the transfer validation by truncating to 0, the contract is willing to add our gigantic credit to our address in its internal balance mappings. Suddenly we have an astronomical balance in the contract and can drain all the deposited native tokens from the wrapped token contract!

To clarify, it’s not the WETH token itself on Ethereum that is vulnerable (but the title made you click, didn't it!), but the analogous wrapped native tokens of the polkadot parachains powered by the frontier EVM, such as WASTR in Astar, WGLMR in Moonbeam, and WMOVR in Moonriver, which are implemented using the standard WETH contract but on their respective parachains!

WETH contracts are not the only vulnerable targets. The Uniswap-like DEX trading pair contract accepts direct swapping from native ETH to ERC20 tokens. It trusts the msg.value too. Compound-like lending protocols usually provide a dedicated native token vault, handling both the deposit and withdrawal of native tokens. DEXes and lending protocols are the fundamental infrastructure of the DeFi world, any insolvency would be contagious. As I mentioned, any critical vulnerability that could depeg WETH is actually the nightmare of the whole ecosystem.

The previous bug had a similar effect, but required a tricky exploit. This bug is trivial but more destructive.

The impact of the bug is complex. The direct exploit could drain all the wrapped token contracts. In addition to taking over the balance of the wrapped token, you can purchase other tokens from DEX by spending the rubber check from the wrapped token. Worse, a more sophisticated exploit could leverage the lending protocol to borrow all the other valuable tokens against the fake deposit.

At the time I reported the bug, the major victims were:

• WMOVR https://moonriver.moonscan.io/address/0x98878b06940ae243284ca214f92bb71a2b032b8a 560,369.286709772080185324 MOVR $6,511,491.11 (@ $11.62/MOVR)

• WMOVR https://moonriver.moonscan.io/address/0xf50225a84382c74cbdea10b0c176f71fc3de0c4d 39,495.093378689025337841 MOVR $458,932.99 (@ $11.62/MOVR)

• MGLMR https://moonbeam.moonscan.io/address/0xacc15dc74880c9944775448304b263d191c6077f 22,509,169.750566904824477505 GLMR $15,462,674.16 (@ $0.69/GLMR)

• Wrapped Astar https://blockscout.com/astar/address/0xAeaaf0e2c81Af264101B9129C00F4440cCF0F720 233,903,992.470478147048553875 ASTR ($12,110,613 USD)

• WASTR https://blockscout.com/astar/address/0x19574c3c8FaFc875051b665Ec131b7E60773d2C9 98,294,128.445114886025015582 ASTR ($5,080,234 USD)

• Wrapped Shiden https://blockscout.com/shiden/address/0x0f933Dc137D21cA519ae4C7E93f87a4C8EF365Ef 9,348,196.210407926441765242 SDN ($3,310,196)

The direct loss from wrapped token contracts could be more than $44M.

In lending pools the assets under risk is even larger:

• Moonwell Apollo Total Supply $89,023,722 Total Borrow $41,595,374.52

• Moonwell Artemis Total Supply $179,023,716.01 Total Borrow $94,486,490.85

• Starlay Finance Total Deposited $37,163,238.35 Total Borrowed $18,769,822.51

The remaining borrowable assets would be somewhere around $150M.

The vulnerability disclosure was troublesome as well. This bug affected at least two parachains: Moonbeam network and Astar network. I had to report to them simultaneously otherwise one team with earlier knowledge of the bug could conceivably launch an attack on the other one (I didn’t know if they were competitors). Furthermore, I noticed Acala network also shipped the same code, but they didn’t have as rich an EVM-based ecosystem as the other two, and the bug had no explicit impact on their system as a result, so I decided to postpone the bug disclosure to them.

All the three projects have their bug bounty program listed on Immunefi: Moonbeam network, Astar network and Acala. Each project has a maximum bug bounty of $1M 😮. I was worried that the triage process on Immunefi might be delayed, so I tried to contact the first two teams as soon as I finished my POC and reports. Thanks to the help from the Moonwell team, they set up a telegram channel between me and Moonbeam, who later invited the Astar and Polkadot guys to the group. All the bugs were quickly patched. A security advisory (CVE-2022-31111) was published later. This has been recorded on Moonbeam’s blog.

Another interesting fact about the bug: a few hours after my report, the Moonbeam team identified a suspicious transaction that triggered the vulnerability. You can see the transfer of 340,282,366 (T) MOVR! I believe the bug is dead now, but the corpse is living on the blockchain permanently.

The vulnerable substrate frontier is built by paritytech, the team behind Polkadot. The Moonbeam team maintains its own fork at https://github.com/PureStake/frontier. The Astar team forks from Moonbeam’s repo to https://github.com/AstarNetwork/frontier. All of them agreed to offer a bug bounty, but they decided to split a $1M bounty after months of negotiation🤣. To my surprise, Acala offered a huge bounty (compared to their negligible potential loss), which was also counted in the split. The final payout is $1M:

• Moonbeam $430k

• Astar $250k

• Polkadot $250k, in DOT

• Acala $70k, in DOT

Whether the result is $2M or $1M, since the bounty pays out in tokens living on the Ethereum blockchain, I guess I'm pretty lucky that WETH wasn't vulnerable to this bug after all!

This journey took me out of the safety of the moonlight and into the uncertain darkness of collateralization. I dug into new concepts to bring familiarity to unfamiliar code. I quickly found a trivial bug, but I suspected that there was more. After some comprehensive research, I discovered a novel, exciting flaw. Both bugs have been confirmed as critical, leading to the decision to deactivate the vulnerable module.

To understand the hack, you, like I had to do, will have to start with the basics. So sit back, read on, and let's learn about collateral!

the interBTC Bridge and Over-collateralization

The interBTC runtime allows the creation of interBTC, a fungible token that represents Bitcoin in the Polkadot ecosystem. Each interBTC is backed by Bitcoin 1:1 and allows redeeming of the equivalent amount of Bitcoins by relying on a collateralized third-party.

Over-collateralization is a popular technique in DeFi protocols, enabling the minting of a synthesized asset from another base asset. Most Collateralized Debt Position (CDP) protocols are designed for minting stable coins from valuable but volatile assets. The most successful case of over-collateralization is the MakerDAO protocol, which allows users to create debt in DAI by depositing ETH.

In the interBTC protocol, however, one is allowed to synthesize a mapping of a high value token (BTC) from its native tokens, like INTR and KINT. This feature is more like Synthetix, which allows minting any mapped assets by locking its native token SNX. The security of risky collateral usually means higher collateralization rate and lower capital efficiency. For SNX, the Collateralization Ratio (C-Ratio) is 400%. For interBTC, on their Kintsugi canary network, C-Ratio of KINT is 500%, C-Ratio of KSM (the native token of Kusama) is 150%.

As pointed out by the interlay team, they use mainly the KSM/DOT assets (the ceiling of INTR/KINT is very low due to missing liquidity). They primarily target exogenously priced collateral assets rather than endogenous ones - more like Maker, but they allow a small portion of our native asset.

The security properties are usually maintained by price oracles and arbitrageurs, but this may not work during market crashes. Luckily, the over-collateralization of interBTC is just the ​​last line of defenses, the system has guaranteed Bitcoin reserves as long as all the vaults are honest.

But how can we trust decentralized vaults that are controlled by anonymous entities? Now I will try to explain the innovation of interBTC’s fraud proof and slashing mechanisms.

Onchain SPV and Fraud Proof

InterBTC is designed specifically for BTC, so it has to deal with the complexity of bitcoin transactions. It is clearly impossible to maintain all the transactions on chain, so the protocol works like a light wallet. Accordingly, the BTC-relay module of the protocol implements the Simplified Payment Verification (SPV). Instead of tracking all the unspent notes (utxo), only the minimal information of every bitcoin block header is stored on the chain. The relayers are in charge of the synchronization of block headers, providing the root of trust. The validation algorithm only needs to verify a given transaction

1. has a valid merkle proof for its txid

2. the merkle root is found in the stored block headers

3. the corresponding block is mature enough

Thus the system is able to check the validity of any interactions between users and vaults (specifically, transfers of a specific amount of BTC). Where would the users deposit to? To addresses prepared by the vaults in the registry module. The vaults have to respond to reasonable requests from the user, and if no valid proof is supplied in a limited time, the locked collateral for that request will be slashed. All the required information is provided to the system, so it can confirm the honest behaviors with confidence.

What about malicious behaviors without corresponding user requests? The off-chain relayers monitor and check that vaults do not move BTC, unless expressly requested during Redeem, Replace or Refund. If a malicious vault moves BTC without authorization by the bridge, or reuses the authorization by committing the same OP_RETURN transaction, all of its collateral will be slashed. These two behaviors are reported by report_vault_theft and report_vault_double_payment extrinsics respectively.

Therein lie the bugs...

Bug 1: Double Payment Force Liquidation

report_vault_double_payment is exposed as an extrinsic call method. It takes two raw txs and verifies that they share the same input and reference the same user requests.

The two txs are compared to ensure they are different. However, the check of Vec<u8> is incomplete.

BytesParser ignores trailing bytes of the raw transaction, so different raw_txs.0 and raw_txs.1 can be parsed into same Transaction, bypassing all the following checks in report_vault_double_payment.

All the vaults with at least one processed user request (Redeem, Replace or Refund), are vulnerable to this force liquidation. The attacker would steal 5% of the vault's collateral, leaving the whole system broken: all the collateral would be transferred to the liquidation account and all vaults would be banned.

The bug is pretty simple. In the POC, a fake tx is crafted by simply appending an extra byte to the original tx. My patch and testcase were later adopted in their commit. Full Report

Bug 2: P2SH Address Forgery

The bitcoin address itself is a pretty interesting topic. There are many variants of address: P2PK, P2PKH, P2MS, P2SH, P2WSH, P2WPKH… It’s super confusing! Why?

As you may (should!) already know, there is no such concept as an account in Bitcoin: all the balances are maintained by utxos. Every utxo has a ScriptPubkey, which can only be unlocked by the corresponding ScriptSig. The different types of common ScriptPubkey are encoded in addresses of various forms. Notice that they are actually tiny scripts that support limited operations in the special stack-based virtual machine inside Bitcoin.

The interBTC system currently supports 4 types of addresses: P2PKH, P2SH, P2WPKHv0 and P2WSHv0. The vaults can freely register any type of address. One of these types is particularly interesting, P2SH – Pay To Script Hash. This feature has a subtle quirk: any ScriptPubkey can be encoded in a vault address with just its hash, and the actual ScriptPubKey will only be provided by the corresponding ScriptSig (and verified against the stored hash). Subsequently, the rest of the ScriptSig (which is not checked against any hashes), just like the key to a lock, can be forged arbitrarily to match the mutable ScriptPubkey!

The malleability of ScriptSig is not a nightmare until it is used in a SPV system. Due to the reduced amount of information stored in SPV, there is no way to lookup the matching ScriptPubkey of a ScriptSig (unlike a full node, which can look it up in the chain). So the system has to extract the ScriptPubkey/address from the ScriptSig. The extraction of the address must be accurate, otherwise

• Attack 1: If the correct address is not recovered from the ScriptSig, the use of the uxto will not be considered as the action of the vault, thus the misbehavior will never be confirmed by report_vault_theft.

• Attack 2: If the extracted address is misinterpreted as an address of another vault, the benign vault will be slashed by report_vault_theft.

Unfortunately, the address extraction algorithm is neither sound nor complete. For example, it only accepts a subset of valid addresses and detects the P2SH address by checking if the first opcode is OP_0. If the ScriptSig violates the hardcoded templates of P2SH and P2PKH, the correct address will not be recognized, leading to Attack 1. If the ScriptSig is carefully crafted by the attacker, any P2PKH or P2SH addresses can be counterfeited. That is Attack 2. It's worth noting that Attack 1 can be a side-effect of Attack 2.

In the POC, I use a P2SH address corresponding to a special redeem script and construct a transaction by spending from that P2SH address. The redeem script consumes 3 elements from stack: [fake sig, fake pubkey, real sig]. It has two OP_NIP opcodes that drop the first two elements of the input stack. The remaining real sig is verified with the hardcoded real pubkey. Because the first two elements, sig and pubkey, are pushed into stack just like other common P2PKH scriptsig, the extracted address from this scriptsig will be just like a normal P2PKH address from the fake pubkey (the fake sig is unused), thus leading to Attack 2. The transaction has been confirmed in the testnet. Full Report.

Patching the design failure is tricky: introducing stricter validations means more chances of missing actual thefts. The interlay team handled the issue quickly and decided to deactivate the vulnerable theft reporting functions. However, my exploration didn’t stop here.

Bonus: Segwit Address Confusion

The P2SH address is not the only type of address with a customized script. P2WSH, the segwit version of P2SH, works in a similar fashion, but the script is revealed inside of the witnesses instead of the ScriptSig. P2WPKH is another specially handled address type, validating the user public key embedded in witnesses. For both cases, there is a deterministic algorithm to infer the correct address from the witnesses. I failed to break the segwit style addresses at first, but eventually I found a weakness!

The extraction algorithm only cares about the last element of the witnesses, because it is either the public key for P2WPKH, or the ScriptPubkey for P2WSH.

So, how can an SPV system determine the exact type of the original address in the unified algorithm? Heuristics again! If the witness of P2WSH address looks like a valid public key:

1. length in 33 bytes

2. first byte is ‘\x03’ or ‘\x04’

then it is considered a valid P2WPKH address.

Some knowledge of the opcodes is required for building this tricky script. The confirmed transaction is on the testnet.

Downgraded Security?

In the postmortem of the interlay team, they have decided to remove the theft reporting functions. As we have discussed in the first section, the removal of fraud proof downgrades the security: it degenerates interBTC into a basic over-collateralization system, just like Synthetix. Will it be a problem? In theory, its economic security is unaffected.

There is no guarantee that a vault still holds BTC, but the value at risk for the vault is still the same. So if a vault does not send BTC at the time of redemption it is still the same decision process: keep BTC or lose collateral at the time when the user redeems.

However, the security achieved through sophisticated economic designs does not always work. While searching for more instances of failed fraud proof, I came across an unexpected protocol, ONEBTC, the “Trustless Bitcoin on Harmony”. They listed interlay/BTC-Bridge and interlay/BTC-Bridge-Spec in their references! Their code looks like an old version of interlay BTC bridge, with some random customizations (comment out some functions deliberately).

In OneBTC.sol, they have implemented reportVaultTheft and reportVaultDoublePayment! But these functions are restricted by requiring relay.isApprovedStakedRelayer(msg.sender), and they don’t really parse the transactions – they just slash anybody unconditionally!

I have not verified if they had ever used the fraud proof functions, but even if that happened, it would not be in a trustless style as they claimed (and users expected). It turned out that the “optimistic” and semi-trustless bridge worked pretty well, the decentralized nature of vaults were immune to the compromised private key! The ONEBTC bridge was the only survivor of the epic nine figure hack.😓

Funds SAFU? Maybe not... The fluctuation of its collateral, Harmony (ONE), caused a huge risk of under-collateration. The emergency (still ongoing!) freeze of the bridge reinforced the crisis. The users might not be able to cash out, but the vault operators can leave this dangerous game freely, because the raw Bitcoin is unstoppable!

Closing Thoughts

Given the potential for deceit that we find again and again in not just crypto, but almost every inter-human transaction, did we truly expect it to hold secure? Humans have been forging coins, cash, and checks for centuries. Is it really unexpected that, given the chance, we would forge scripts?

What keeps the darkness at bay? I hope that, in a small part, I've helped keep it at bay with this report. Perhaps there was a potential future with a headline of an interBTC hack that now won't happen. Perhaps not. But what there is, is you. I am but one hacker, just months into my crypto journey. You can come walk it with me: what took me months can take you weeks, and you, too, can keep crypto safe.

Delegatecall and Native Contracts

After reporting the bug in Aurora engine, I started to think about the other potential misuses of delegate calls of native contracts. The original purpose of the delegatecall was to provide a mechanism through which one smart contract could share and reuse the code of another one’s to avoid the overhead of duplicated code storage. Native contracts are usually prebuilt contracts that implement special functions as extensions of the original EVM.

Now, the tricky part: if you delegatecall to a native contract, you may be able to execute some unexpected functions, even privileged ones! However, the developers of those native contracts might not realize that the actual user of the functions could be someone else. In the Aurora bug's case, the native contract just assumes the caller will always be a magical address, so the hardcoded log emitter leads to the malicious withdrawal vulnerability.

What other assumptions could be wrong? When you do a delegatecall, the calling context is inherited from the previous one, including the msg.sender and msg.value. From the view of a native contract, the contract that invokes delegatecall is transparent: its caller will be considered the real user instead. So if a malicious contract is invoked, it can impersonate its caller to operate on the native contracts!

Shadow in the Moonbeam

Moonbeam and Moonriver are both EVM-compatible platforms. There are some precompiled contracts in moonbeam runtime which are shared between Moonbeam and Moonriver.

The Balance ERC-20 precompile provides an ERC-20 interface for handling the native tokens (MOVR & GLMR) of balance. The implementation Erc20BalancesPrecompile is in moonbeam/precompiles/balances-erc20/src/lib.rs.

The designer did not take the usage of `delegatecall` in EVM into consideration. A malicious contract can pass its msg.sender to the precompile contract to impersonate its caller. In this scenario, there is no way for the precompile contract to figure out the actual caller. The attacker can either increase the allowance from the victim or transfer the available balance immediately.

There are similar issues in the Asset ERC-20 precompile, which provides an ERC-20 native implementation of interoperable tokens (xcKSM, xcDOT, ...). The implementation Erc20AssetsPrecompileSet is in moonbeam/precompiles/assets-erc20/src/lib.rs.

However, the designer did consider the usage of delegatecall in EVM for this case. The ERC20Instance contract in the tests has implemented approve_delegate(), transfer_delegate() and transferFrom_delegate(), with test cases ensuring their validity. Unfortunately (or, for us, fortunately!), it turns out that the design logic can not work properly, so they have removed the relevant code in their patch.

Here is a simple exploit that can be reused in both cases: the asset address of native token is 0x0000000000000000000000000000000000000802 and the asset address of a local token could be 0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080.

Perfect Contracts, or Perfect Victims?

What can we do with the design flaw? The basic idea is to ask someone to trigger your malicious contract, e.g., calling the trap() in the POC contract.

How can we persuade users to invoke some mysterious contracts? By Airdrop! The hackers behind the UNIH token have demonstrated the crypto-native solution of phishing! Any user who wants to sell an airdropped token in uniswap has to call the malicious token contract to approve the DEX to spend their balance. Due to the vulnerable design of RUNE tokens, where only the tx.origin instead of msg.sender is checked for approval, all the RUNE tokens could be stolen by a trojan contract.

The phishing idea is creative, but it strongly limits the potential damage of the vulnerability. We want to find a better victim that is

1. willing to call your contract

2. not as smart as users

3. rich!

Who are the best friends of poor hackers? The flash loan providers! They hold a lot of money and call your contract callbacks as you wish! In the flash loan callback, they are forced to approve your future transfer of their asset tokens, even if they are flawless contracts!

Some DEX pairs support callbacks to arbitrary contracts, such as SolarBeam on MoonRiver and StellaSwap on Moonbeam. The stable swap pair between xcKSM and stKSM is also vulnerable due to the support of flash loans. If one token can be drained from the trading pair, then the other token can be moved out in one single swap, all the liquidity will be cleared.

Now the perfect written contracts become perfect victims. By the time I reported, the richest vulnerable contracts were:

1. 0xea3d1e9e69addfa1ee5bbb89778decd862f1f7c5 on Moonriver, SolarBeam LP Token, $7.5M

2. 0xa927e1e1e044ca1d9fe1854585003477331fe2af on Moonbeam, Stella LP Token, $2.7M

3. 0x77d4b212770a7ca26ee70b1e0f27fc36da191c53 on Moonriver, xcKSM & stKSM pair, $2.4M

These tokens are worth about $12.6M, even a 10% potential loss is already more than $1M, the maximal bounty prize that Moonbeam offers. But real hackers won’t be stopped by trivial achievements, will there be any crazier victims?

the Glimmer

The native tokens MOVR (on Moonriver) and GLMR (on Moonbeam) are equivalent to ETH on Ethereum. To be used in DeFi protocols, they have to be wrapped in ERC-20 compatible token contracts, just like WETH.

The Balance ERC-20 precompile provides the native wrapper of the native tokens. None of any deployed protocols ever use it because the official wrapped tokens WMOVR and WGLMR are more widely adopted. By leveraging the vulnerability of the Balance ERC-20 precompile, we are able to steal the native token balance from any userif it invokes the malicious contract. Unlike the Asset ERC-20 precompile tokens, e.g., xcKSM and xcDOT, which are directly used by DEXes, MOVR and GLMR balances are rarely used by smart contracts.

Most contracts with non-zero balances are multisig wallets, which are not so different from the externally owned accounts. The only exception, our glimmer of hope, is the MGlimmer contract of the Moonwell project.

The Moonwell project is the dominant DeFi protocol on Moonriver. It has nearly $200M in supply and $100M available for borrowing (at the time I reported). MGlimmer, or Moonwell: mMOVR Token is the specific contract that handles the lending and borrowing against MOVR, and it has the native MOVR in its balance.

The cool thing is that when it transfers the balance to the user, it will call the destination as a contract! Here is a simple exploit that gains the approval of spending all the balance of MGlimmer.

The balance stored in the vulnerable contract is not too much (a few thousand of MOVR now). Still, any amount you deposit into that contract will be considered your collateral in this lending protocol. The exploit can be further weaponized by repeating the deposit -> borrow -> transfer all back -> leave bad debt procedure. All borrowable assets can be drained!

It could absolutely be in the top 10 heists of DeFi history if any hacker took all the $100M borrowable assets plus $12M vulnerable tokens in DEX pairs! Another amazing fact about these vulnerabilities is that actual attacks could be super stealthy by only keeping the unauthorized privilege instead of stealing immediately. Since the contracts themselves are flawless, it’s almost impossible for the developers of those DeFi projects to figure out what is going wrong!

Responsible Disclosure

Everybody is struggling in the bear market. I don’t want to hurt anyone, I want to help, especially when they are such hard working teams. So I tried my best to help the project teams understand the root causes and speed up the patching process.

The situation here is extremely complex at first. The flaw is in the deep core of the blockchain system, but the victims are the DeFi protocols built on top of it. Some protocols may have emergency exits to pause and upgrade their contracts, while others are just immutable.

The ultimate patch has to be made by the Moonbeam team, but the biggest victim, Moonwell, could have mitigations for this vulnerability before the actions of the Moonbeam. I noticed that both Moonbeam and Moonwell had launched their bounty program on Immunefi, so I discussed with the Immunefi team the potential special case (without disclosing the specific name of the projects). After realizing that other projects, like the uniswap style DEXes, can not really do anything useful, I decided not to report to them to minimize the risk of leaking the critical information. Since only the Asset ERC-20 issue might be a problem for the Moonwell team, I have to split the report for Moonbeam into two parts, only the necessary information and the exclusive GlimmerExploit POC are submitted to them.

I took special care of the Moonbeam team, even if they might not be aware of that. I spent extra hours learning their code base and writing two complete test cases (600+LOC) just in case they needed more explanation of the root cause. I asked the common timezone of the PureStake team in their discord to make sure I submit the report once the first engineer comes to work. Luckily, it worked out: they started handling this issue on Friday and finished the patch before the weekend without any inquiries!

Is this the last unexpected flaw hiding near the core design of blockchain-based smart contracts? Certainly not! For every delegatecall, there's another, even wilder issue hiding in the darkness. There are always other, more exotic issues waiting for me!. Stay with me on my journey as I find these bugs, push them into the light, and make the blockchain safer for everyone!

I am an experienced whitehat hacker from the web2 world. I have been watching the hacking drama in the crypto world for a while, and there is so much randomness! I am not too surprised at the astronomical profits of defi hackers, because the criminals in the real world also make an insane amount of money. However, I was really shocked by the story of saurik, a famous hacker in the jailbreak community. The size of his bug bounty is unheard of in the traditional security world, and so I can’t wait to start my own treasure hunt in web3.

I started by checking the bounty list on Immunefi. The Aurora bounty program, listed on the very top of the website due to its huge bounty offer, caught my eye. It was a novel project built by a group of talented engineers, which suggested that it might be complex enough to be immune to common defi hackers and mysterious enough for me to learn something magical. Thanks to my experiences in hacking modern complex systems, I was able to start my research on the new blockchains quickly. I had reviewed the Aurora bridge, which was a solid project. Then I moved on to the Aurora engine and discovered the unicorn bug in a few hours. Unlike ordinary defi vulnerabilities, I didn't think this bug could be identified by random people as fast or lucky as me, so I took my time verifying and reproducing the bug in case it was a false alarm. It took me a few days to learn, build, learn, test and finally finish the report.

I tried pinging the Aurora team in discord, sending messages to the official bounty email and submitting the issue through Immunefi. They confirmed and patched the vulnerability quickly, and have since recounted the general story. Their rewards for smart contract critical vulnerabilities are calculated as 10% of potential economic damage of their exploitation, up to a value of $6,000,000 USD. In this case, the potential damage could have been higher than ten times this maximum reward. Therefore I was eligible to receive the maximum possible amount, the total value of $6,000,000 USD, in the form of locked AURORA tokens. It’s a pretty smart and lucky move to be listed on Immunefi :)

The technical details have been explained by Immunefi. Here is my short summary:

1. The Aurora engine implements token bridging in prebuilt contracts at hardcoded addresses. They are the magical bridges connecting Ethereum, NEAR and Aurora.

2. The vulnerable contract always emits a fixed address in bridging events, assuming the msg.value will be collected by itself. However, if the contract is invoked by delegatecall(), the msg.value will never be sent to the contract but the log will be emitted as usual.

3. By repeating the malicious withdrawal then redeposit process, the attacker can double their balance exponentially. The infinity inflation of ETH could have destroyed the whole ecosystem of Aurora: all 71k ETH in the aurora account could have been drained, and other valuable tokens could have been purchased by free ETH. (There were billions of TVL in the Aurora bridge.)

If you are hardcore enough, you may find the original report and scripts interesting, enjoy!