Aurora Engine $6m Bug Bounty

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' and 'General Prevention' sections to other sections, and add any missing information or sources you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Aurora Engine

The Aurora EVM is a layer 2 scaling solution for the Near Protocol. A bridge existed between the Aurora protocol and the Near or Ethereum blockchains, which could allow someone to attempt to swap their Aurora-based Ethereum to Near-based Ethereum or Ethereum itself, without actually completing the payment of the source Ethereum. Such a vulnerability would have allowed draining of the entire wallet balance.

The white hacker pwning.eth found and responsibly disclosed the vulnerability, which was promptly patched. As a reward, he received $6m USD worth of Aurora tokens, the maximum bounty payable.

About Aurora Engine

The Aurora EVM is a layer 2 scaling solution for the Near Protocol.

Documentation:

Near Rainbow Bridge Documentation:

Website:

Bug Bounties:

"Shooting for the stars. Aurora provides Ethereum compatibility, NEAR Protocol scalability, and industry-first user experience through affordable transactions."

"Another striking feature of the NEAR protocol is the layer 2 scalability solution, Aurora." "Aurora is an Ethereum Virtual Machine (EVM) built on the NEAR Protocol, that provides a solution for developers to deploy their apps on an Ethereum-compatible, high-throughput, scalable and future-safe platform, with low transaction costs for their users. Besides the EVM, Aurora developed the Rainbow Bridge which allows users to transfer assets between Ethereum, NEAR, and Aurora. Aurora is backed by top VCs such as Pantera Capital, Electric Capital, Dragonfly Capital, Three Arrows Capital, and Alameda Research."

Aurora "completes the trinity of scalability with NEAR protocol by helping developers increase the scalability and interoperability of their apps, alongside offering lower transaction costs. The NEAR protocol can capitalize on the Rainbow Bridge Aurora combination to deliver plausible improvements in scalability. Most important of all, the NEAR protocol assumes that Aurora could host thousands of transactions per second. On top of it, Aurora could ensure a block confirmation time of almost 2 seconds."

"Thanks to Aurora’s EVM, Ethereum native applications can seamlessly be ported to NEAR’s L2-like network that is built as a smart contract on NEAR. Developers may enjoy familiar Ethereum tooling when working with their Solidity smart contracts on Aurora. The base fee of Aurora is ETH, which provides a smooth experience for dapps’ users."

"The two primary aspects of the design of Aurora include the Aurora Bridge and the Aurora Engine. The Aurora Engine is an EVM or Ethereum Virtual Machine on the NEAR protocol. It offers compatibility with Ethereum alongside all the tools accessible within the Ethereum ecosystem."

"As a result, developers could start working on the NEAR blockchain without knowledge of new development tools or rewriting their dApps. On the other hand, the Aurora Bridge features similarities to Rainbow Bridge for the seamless transfer of ERC-20 tokens to and from Ethereum and the NEAR protocol blockchain. Users could also pay their transaction fees on Aurora by using ETH."

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

A bridge existed between the Aurora protocol and the Near or Ethereum blockchains, which could allow someone to attempt to swap their Aurora-based Ethereum to Near-based Ethereum or Ethereum itself, without actually completing the payment of the source Ethereum. Such a vulnerability would have allowed draining of the entire wallet balance.

"The bug report described an inflation vulnerability that, if exploited, would allow to mint an infinite supply of ETH in the Aurora Engine. That artificial ETH could then have been used to drain of all ETH in the bridge contract on Ethereum (more than 70k ETH at the time of the report, about $204M). Furthermore, the artificial ETH would also allow to drain all tokens from the liquidity pools containing ETH on Aurora and NEAR, also putting these tokens at risk."

"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.)"

"When someone does a DelegateCall to Aurora's ExitToNEAR or ExitToEthereum precompiles they have the ability to not actually send the balance of the EOA resulting in the engine scheduling a withdrawal for them to their NEAR or Ethereum account."

"An example would be if an adversary had 1 ETH, they would be able to DelegateCall exit to NEAR precompile and get 1 ETH back on NEAR's NEP-141 token while retaining the 1 ETH on Aurora. Depositing this 1 ETH back and repeating this process with the 2x balance the adversary had prior, they would be able to exponentially drain the entirety of the locked NEP-141 ETH tokens."

"In the exit to NEAR and exit to Ethereum precompiles, the contract address was hardcoded with disregard to how DelegateCall works. When someone calls the contract it comes from the address of the contract always, and not from the input. Also, since the balance is from the EOA and not the contract, there is no transfer of ETH. This results in the Aurora Engine scheduling a transfer from its NEP-141 ETH balance to the adversary while it has not received an ETH transfer."

"A live test on the testnet was performed by Aurora Labs to confirm the bug, using the exact Solidity contract provided by the author of the exploit." "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." "Swiftly after the bug has been confirmed a patch was developed and deployed on both mainnet and testnet. To allow for additional code reviews the source code corresponding to the bug fix was only later published in the Aurora Engine release 2.5.3."

"Instead of removing the hardcoded contract address, given context, it turned out to be better to instead return an exit error if the address given does not match the inputs' address. This yields the same desired result. It effectively disables the ability to call the contract with DelegateCall, much like how it's already done with StaticCall. An accompanying test was produced to ensure that the vulnerability will be tracked in case a logic change causes it to resurface."

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

"On April 26, 2022, Aurora Labs received a bug report with critical severity affecting the Aurora Engine through its Immunefi's bug bounty program."

The white hacker pwning.eth found and responsibly disclosed the vulnerability, which was promptly patched.

Key Event Timeline - Aurora Engine $6m Bug Bounty

Date	Event	Description
April 26th, 2022	Bug Bounty Report Received	Aurora Labs received the bug report through their Immunefi Bug Bounty program.
June 6th, 2022	Blog Post Published	A blog post is published about the vulnerability, how it was patched, and the bug bounty. TBD more details filled in. New timeline entries?
June 7th, 2022 8:13:21 AM MDT	Release 2.5.3 Is Committed	Release 2.5.3 is committed to Github. TBD - This is after the blog post?
June 7th, 2022 11:15:00 AM MDT	CoinTelegraph Article Published	CoinTelegraph published an article on the bug bounty paid out. TBD add information.
June 14th, 2022	Pwning Shares Their Story	Pwning, the white hat hacker who uncovered the vulnerability, publishes a blog post with their background of how they first came across the vulnerability. TBD get details.
June 23rd, 2022 5:07:41 AM MDT	Hall Of Fame Status	The bug bounty is commemorated in the white hat hall of fame.
August 22nd, 2022 6:31:00 AM MDT	Bug Bounty Referenced	The bug bounty is referenced again in regards to the second Near Bridge attack as the "second largest bug bounty in the world".

Total Amount Lost

The total amount at risk has been estimated at $204,000,000 USD. A $6,000,000 bug bounty was paid for the discovery. No funds were lost.

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

"Immunefi received a report from pwning.eth about a critical flaw in the Aurora Engine that would have enabled the infinite minting of ETH in the Aurora Ethereum Virtual Machine to drain and siphon the corresponding nested ETH (nETH) pool on NEAR. At the time of discovery, the pool contained more than 70,000 ETH, worth at least $200 million."

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

A bounty of $6,000,000 USD was paid for the discovery.

As a reward, he received $6m USD worth of Aurora tokens, the maximum bounty payable.

"Pwning.eth has earned a Whitehat Hall of Fame NFT for his recent critical bug find in Aurora, forever securing his spot in hacking history. This award makes him the second whitehat to be immortalized after Satya0x, who was paid $10,000,000 for his find in Wormhole."

"Each Whitehat Hall of Fame NFT card is a 1/1 made specifically for each landmark bug report and legendary whitehat, all designed to suit the hacker’s ultimate persona. It is minted from immunefi.eth to ensure authenticity. This time, [Immunefi] worked with an artist to show pwning.eth locked in struggle with bugs and blackhats on the Aurora bridge, with aurora borealis displayed overhead."

"On Tuesday, [June 7th, 2022, ]Ethereum bridging and scaling solution Aurora announced it had paid out a $6 million bounty to ethical security hacker pwning.eth, who discovered a critical vulnerability in the Aurora Engine. The exploit allegedly placed over $200 million worth of capital at risk. The sum was paid in collaboration with Immunefi."

"As a reward for the responsible disclosure, the white hat hacker pwning.eth has been awarded $6M in AURORA tokens, the maximum possible bounty in our bug bounty program and to our best knowledge, the second-highest bug bounty ever paid in history."

Mitchell Amador, founder and CEO at Immunefi, said: "Hats off to Aurora and pwning.eth for the flawless overall processing of the report. The bug was quickly patched, with no user funds lost." "Aurora had launched a bug bounty program with Immunefi just one week before discovering the security vulnerability."

Meanwhile, Frank Braun, head of security at Aurora Labs, commented: "We look at the bug bounty program as the last step in a layered defense approach and will use this bug as a learning opportunity to improve earlier steps, like internal reviews and external audits."

"Such a vulnerability should have been discovered at an earlier stage of the defense pipeline and Aurora Labs has already started improving its methods to achieve that in the nearest future."

Total Amount Recovered

No funds were lost in this case.

Ongoing Developments

There are no ongoing developments remaining in this case.

General Prevention Policies

Ultimately, deploying a live bridge with full access to release all assets is not secure, and all actions can only be taken to reduce the level of risk. Obtaining security audits on the smart contract would have been likely to detect the vulnerability, and for best results obtaining audits from three independent firms would increase the likelihood of vulnerabilities being detected. While the bug bounty helped, it was a race between black and white hackers on a live deployed contract, and the outcome could have been very different.

A mechanism to limit the rate of withdrawals would have significantly reduced the potential impact from the vulnerability, while still allowing the majority of transactions to proceed instantly. If the withdrawal limit is hit, a multi-signature setup can securely vote to increase it temporarily or permanently. A separate treasury can be funded to cover any loss situations that may arise.

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.