Aurora Engine $6m Bug Bounty

Notice: This page is a new case study and some aspects have not been fully researched. Some sections may be incomplete or reflect inaccuracies present in initial sources. Please check the References at the bottom for further information and perform your own additional assessment. Please feel free to contribute by adding any missing information or sources you come across. 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 recently discovered and reported a critical bug in the Aurora Engine, a layer 2 EVM solution built on the NEAR protocol. The bug 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.

About Pwning

Pwning comes from a background as a Web2 hacker. He first got interested in Web3 bug bounties based on the story of Saurik. He was intrigued by the high bug bounty rewards in the crypto world and decided to explore web3 hacking. He shared his initial story on his blog post.

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.

He started his research by examining the Aurora bounty program.

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.

A bug put around 70,000 ETH at risk of being stolen, making it one of the potential top heists in DeFi history.

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

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 white hacker pwning.eth found found and responsibly disclosed a unicorn bug in the Aurora engine. After verifying and reproducing the bug, he reported it to the Aurora team through various channels and received the maximum reward of $6,000,000 in locked AURORA tokens.

Key Event Timeline - Aurora Engine $6m Bug Bounty

Date	Event	Description
February 2nd, 2022	Saurik Blog Post Published	Saurik publishes a blog post highlighting his critical security issue which he found in the Optimism protocol. This post would serve as inspiration for white hacker Pwning.
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".

Technical Details

Aurora Labs recently received a bug report on April 26, 2022, through the Immunefi bug bounty program, highlighting a critical inflation vulnerability in the Aurora Engine.

The technical details of the bug involve a vulnerability in the token bridging contracts implemented by the Aurora engine. The bug could have allowed an attacker to create an infinite supply of ETH within the Aurora Engine and potentially drain over 70,000 ETH from the bridge contract on Ethereum, along with other tokens in the liquidity pools.

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

Total Amount Lost

Pwning.eth describes the amount at risk on his blog post:

At least 70000 ETH were at risk of being stolen, until I found the tricky vulnerability and helped the Aurora team fix it. It would be in the top 5 heists in the defi history, if the 200 million tokens were taken over by a blackhat hacker.

The total amount at risk has been estimated at $204,000,000 USD. The Aurora team fixed the vulnerability with the help of pwning.eth, who received a bug bounty of $6m USD, the second highest in history. After verifying and reproducing the bug, pwning.eth reported it to the Aurora team through various channels and received the maximum reward of $6,000,000 in locked AURORA tokens. No funds were lost.

Immediate Reactions

After confirming the bug, Aurora Labs swiftly developed and deployed a patch on both mainnet and testnet to address the issue.

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.

The responsible disclosure of the bug earned the white hat hacker, pwning.eth, a reward of $6 million in AURORA tokens, which is the maximum possible bounty in the bug bounty program and one of the highest bug bounties ever paid.

As a reward, Pwning.eth 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."

"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 remaining developments to be resolved in this case.

Aurora Labs sees the bug bounty program as a valuable approach to incentivize white hat hackers and considers this incident as an opportunity to improve their defense pipeline, including internal code reviews and external audits. The event demonstrates the effectiveness of Aurora Labs' security mechanisms and highlights the importance of such programs in the crypto ecosystem.

Frank Braun, the head of security at Aurora Labs, has 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."

Individual Prevention Policies

This case does not appear to have resulted in a loss to any individual.

Avoid the use of smart contracts unless necessary. Minimize the level of exposure by removing or withdrawing assets whenever possible. Aim to choose smart contracts which have obtained third party security audits, preferably having been audited by at least three separate reputable firms. Pay attention to the audit reports, which smart contracts are covered, and whether the smart contract has been upgraded or modified since the report. Ensure that any administrative functions with the ability to remove funds from the smart contract are under the authority of a multi-signature wallet which is controlled by at least three separate and reputable entities.

Store the majority of funds offline. By offline, it means that the private key and/or seed phrase is exclusively held by you and not connected to any networked device. Examples of offline storage include paper wallets (seed phrase or key written down and deleted from all electronic media), hardware wallets, steel wallet devices, etc...

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

Platform Prevention Policies

This case does not appear to have resulted in a loss to any platform. (Other than the bounty paid.)

Deploying a live bridge with full access to release all assets places all assets at risk in a smart contract hot wallet. A better model would limit the liquidity at risk, with the remainder (beyond typical trading volumes) stored in a multi-signature wallet. Obtaining multiple security audits on the smart contract from three independent firms would dramatically decrease the likelihood of vulnerabilities going undetected. The bug bounty is the key concept that saved the platform in this case, though it isn't foolproof.

All wallets, minting functions, and critical infrastructure should be implemented with a multi-signature requirement, with a recommended minimum of 3 signatures required. This means that making important changes or approving spending will require the keys held by at least 3 separate individuals within the organization to approve. The multi-signature should be implemented at the lowest layer possible, all key holders should have security training, and all key holders should be empowered and encouraged to exercise diligence.

All aspects of any platform should undergo a regular validation/inspection by experts. This validation should include a security audit of any smart contracts, reporting any risks to the backing (of any customer assets, ensuring treasuries or minting functions are properly secured under the control of a multi-signature wallet, and finding any inadequacies in the level of training or integrity of the team. The recommended interval is twice prior to launch or significant system upgrade, once after 3 months, and every 6 months thereafter. It is recommended that the third party performing the inspection not be repeated within a 14 month period.

Regardless of what is employed, it is always a good idea to have some funds set aside to cover unexpected vulnerabilities.

Work with other industry platforms to set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

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

Regulatory Prevention Policies

It does not appear that any funds were lost in this case.

All platforms should undergo published security and risk assessments by independent third parties. Two assessments are required at founding or major upgrade, one after 3 months, and one every 6 months thereafter. The third parties must not repeat within the past 14 months. A risk assessment needs to include what assets back customer deposits and the risk of default from any third parties being lent to. The security assessment must include ensuring a proper multi-signature wallet, and that all signatories are properly trained. Assessments must be performed on social media, databases, and DNS security.

Set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services within the country, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

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