Near Protocol Rainbow Bridge Second Attack Mitigated

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.

Near Protocol

The Near Protocol Rainbow Bridge allows the transfer of tokens between the Ethereum, Near, and Aurora blockchain networks. Like most bridges, there is a possibility of attackers submitting fraudulent transactions trying to trick the bridge into releasing funds without making an actual payment. The Near Protocol Rainbow Bridge requires the attacker to send 5 ETH along with any payment request as a "safe deposit", has watchdogs monitoring the network, and allows validators to flag and reject any suspicious transactions.

On the early morning of Saturday August 20th, such a fraudulent transaction was submitted. It was successfully detected and mitigated in this case, and no funds were lost.

About Near Protocol

The NEAR Rainbow Bridge is a solution for scalability in blockchain networks, particularly for Ethereum. The ETH <> NEAR Rainbow Bridge enables seamless migration of assets from Ethereum to NEAR's low-cost and developer-friendly platform. Due to increased demand on the Ethereum network, users can now bridge their assets to NEAR and enjoy faster transactions without compromising speed.

The Rainbow Bridge is a trustless and permissionless protocol, enabling anyone to deploy, use, or maintain a bridge without requiring approval. It addresses the congestion and high gas fees associated with increased transactions. It allows cryptographic proof on NEAR to be usable in Ethereum contracts and vice versa, facilitating activities like voting with ETH balances in NEAR DAOs. The bridge is accessible through the ETH Faucet and MetaMask wallet, and transactions on NEAR confirm in 1-2 seconds at a low cost. While transferring assets from Ethereum to NEAR takes about six minutes and incurs an average cost of $10, sending assets back to Ethereum currently takes up to sixteen hours and costs around $60. However, these costs and speeds are expected to improve in the future. The Rainbow Bridge is available to everyone, offering advantages in speed and cost for transferring ERC-20 tokens on NEAR.

NEAR protocol, which uses blockchain sharding technology, serves as the foundation for the Rainbow Bridge. The protocol offers advantages such as Nightshade sharding, Rainbow Bridge, and Aurora, which enable efficient data processing, seamless token swapping between Ethereum and NEAR, and layer 2 scalability. The Rainbow Bridge is decentralized and permissionless, allowing for the transfer of ERC-20 tokens, stablecoins, wrapped tokens, and NFTs. It offers faster confirmation times and lower transaction costs, benefiting both developers and users.

Users can connect to the bridge using WalletConnect, MetaMask, or the Brave crypto wallet. If they don't have a NEAR account, they can create one by logging in with MetaMask and proving ownership of an Ethereum address with a balance of at least 0.05 ETH. The bridge allows popular tokens such as stablecoins (e.g., USDT, DAI), wrapped assets (e.g., WBTC, WETH), DEX tokens (e.g., UNI, 1INCH), lending tokens (e.g., AAVE, COMP), and service company tokens (e.g., HT, CRO) to be interoperable with NEAR. The transfer of ERC-20 tokens uses a two-step process of approval and transfer, with the tokens being locked in a token locker contract on Ethereum until they are unlocked on NEAR.

TBD more on architecture and GitHub. Team founding. Etc...

Statistics on the rainbow bridge are publicly available on the Dune website.

Third Party Transaction Validators

Transaction validators "agree on which transactions are genuine by tracking blockchain activity on all networks connected to Rainbow. Incorrect transactions are challenged by independent “watchdogs” who observe the Near blockchain to check for data misfits, with incorrect transactions getting flagged and eventually blocked."

"[I]ncorrectly submitted information to the NEAR Light Client may result in the loss of all funds on the bridge. That's why this step is secured with the most solid thing: a consensus of NEAR validators." "And if someone tries to submit incorrect info, then it would be challenged by independent watchdogs, who also observe NEAR blockchain."

This is a global/international case not involving a specific country.

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• 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

"Usually, it's Rainbow bridge relayers, who submit the info on NEAR blocks to Ethereum. However, sometimes others are doing this. Unfortunately, usually with bad intentions." "Such a mechanism protects the network from seeing potentially hundreds of millions of dollars in losses, especially as bridge attacks become more commonplace."

While the mechanism is designed to prevent malicious transactions, a potential concern was that the detection of malicious transactions may depend on human participation, which could be challenging at certain times of day.

What Happened

An attacker attempted to exploit the Near Protocol rainbow bridge and forfeited their required 5 ETH deposit.

Key Event Timeline - Near Protocol Rainbow Bridge Second Attack Mitigated

Date	Event	Description
August 19th, 2020	The Rainbow Bridge Is Announced	An announcement describes the building of the Rainbow Bridge.
April 6th, 2021 6:05:20 AM MDT	The Rainbow Bridge Is Launched	The Rainbow Bridge launched is announced. TBD what's different between these two announcements?
April 6th, 2021 8:10:45 AM MDT	Rainbow Bridge Guide Published	The "Rainbow Bridge Guide (full version)" is published to YouTube.
August 20th, 2022 10:49:19 AM MDT	Safety Deposit Transaction	The attacker puts forth their safe deposit of 5 ETH in preparation for their attack.
August 20th, 2022 10:49:50 AM MDT	Malicious Attack Attempt Transaction	The attacker submits their malicious transaction attempting to fool the bridge, and foregoing their original 5 ETH deposit. TBD more detailed analysis
August 22nd, 2022 6:30:00 AM MDT	Alex Shevchenko Analysis Published	Aurora Labs CEO Alex Shevchenko publishes an analysis of the Rainbow Bridge attack mitigation to Twitter and Typefully.
August 23rd, 2022 6:08:00 AM MDT	CoinDesk Article Published	CoinDesk publishes an article on the attempted attack. The article covers how the protocol's attackers lost 5 ETH (worth $8,000 USD) while attacking the protocol. It includes the quote from CEO Alex Shevchenko and some additional details and background on how the protocol's validators automatically caught and challenged the transaction. "This was possible because of how the Rainbow bridge works. As a wholly decentralized platform, Rainbow relies on several validators, called bridge relayers, who submit block info on Near blocks to Ethereum." This article is ultimately reposted on Yahoo Finance.
August 23rd, 2022 9:34:14 AM MDT	Decrypt Article Published	Decrypt publishes an article on the attempted attack.
August 23rd, 2022 10:20:07 AM MDT	The News Crypto Article Published	The News Crypto Publishes and article on the attempted attack.
August 23rd, 2022 3:47:00 PM MDT	ZyCrypto Article Published	ZyCrypto publishes an article on the attempted attack.

Technical Details

The Near Protocol Rainbow Bridge relies on third party transaction validators.

"However, this is where the validators step in: They agree on which transactions are genuine by tracking blockchain activity on all networks connected to Rainbow. Incorrect transactions are challenged by independent “watchdogs” who observe the Near blockchain to check for data misfits, with incorrect transactions getting flagged and eventually blocked." "[I]ncorrectly submitted information to the NEAR Light Client may result in the loss of all funds on the bridge. That's why this step is secured with the most solid thing: a consensus of NEAR validators." "And if someone tries to submit incorrect info, then it would be challenged by independent watchdogs, who also observe NEAR blockchain."

Specific Timing of The Transaction

A malicious "transaction was successfully submitted in the Ethereum blockchain in the block 15378741 on Aug-20-2022 04:49:19 PM +UTC." "Rainbow developer Alex Shevchenko said in a note Monday that an attacker submitted a fabricated Near block to the Rainbow bridge contract over the weekend by putting up a “safe deposit” of 5 ether." "Over the weekend an attacker submitted a fabricated NEAR block to the Rainbow Bridge contract." "During a transaction, a safe deposit of 5 ETH was required." "That transaction was successfully submitted to the Ethereum network, with the attacker expecting Rainbow developers to be unavailable to mitigate any threats."

"The attacker likely intended to fake transactions and trick Rainbow’s smart contracts into releasing locked funds without depositing any initial funds. Such a sophisticated mechanism has previously been used to exploit several blockchain bridges, such as Nomad’s recent $200 million exploit."

"Note the time of attack: an attacker was hoping that it would be complicated to react [to] the attack early Saturday morning." “[The] attacker was hoping that it would be complicated to react to the attack early Saturday morning,” Shevchenko explained.

"However, no reaction from humans was required. Automated watchdogs were challenging the malicious transaction, which resulted in an attacker loosing his safe deposit." "Rainbow’s validators automatically caught the fabricated block that the attacker tried to submit, challenged and blocked the transaction, and took away the safe deposit of 5 ether put up by the attacker." "[A]utomated security processes by the bridge’s validators kicked in and mitigated the threat in under 31 seconds." "Near Protocol’s Rainbow bridge mitigated a threat in under 31 seconds due to automated security processes which cost the attacker 5Ξ (~$8,000)."

"And though [the] attacker was hoping that our security team won't be available, in fact it was. After notifications on strange activities, within 1h the team was checking that everything is OK and was going back to sleep without disturbing myself or the users."

There was no failure of the protocol due to this exploit attempt. It performed according to the established safe deposit mechanism.

Total Amount Lost

The attacker lost their 5 ETH safety deposit, as per the design of the security mechanism.

No user or platform funds were lost.

Immediate Reactions

The situation was Tweeted about by Near Protocol CEO Alex Shevchenko.

Alex Shevchenko Analysis

Aurora CEO Alex Shevchenko published his analysis of the attack on Twitter and Typefully.

on the Rainbow Bridge attack during the weekend

TL; DR: similar to May attack; no user funds lost; attack was mitigated automatically within 31 seconds; attacker lost 5 ETH.

1/15 The rainbow bridge is based on trustless assumptions with no selected middleman to transfer messages or assets between chains. Because of this, anyone can interact with its' smart contracts, including the NEAR light client

2/15 Usually, it's Rainbow bridge relayers, who submit the info on NEAR blocks to Ethereum. However, sometimes others are doing this. Unfortunately, usually with bad intentions.

3/15 The incorrectly submitted information to the NEAR Light Client may result in the loss of all funds on the bridge. That's why this step is secured with the most solid thing: a consensus of NEAR validators.

4/15 And if someone tries to submit incorrect info, then it would be challenged by independent watchdogs, who also observe NEAR blockchain.

5/15 Over the weekend an attacker submitted a fabricated NEAR block to the Rainbow Bridge contract.

During a transaction, a safe deposit of 5 ETH was required.

6/15 The transaction was successfully submitted in the Ethereum blockchain in the block 15378741 on Aug-20-2022 04:49:19 PM +UTC.

Note the time of attack: an attacker was hoping that it would be complicated to react on the attack early Saturday morning.

7/15 However, no reaction from humans was required. Automated watchdogs were challenging the malicious transaction, which resulted in an attacker loosing his safe deposit:

8/15 And the reaction was taking only 31 seconds (4 Ethereum blocks)

9/15 This attack was absolutely similar to an attack on May 1st.

10/15 And though attacker was hoping that our security team won't be available, in fact it was. After notifications on strange activities, within 1h the team was checking that everything is OK and was going back to sleep without disturbing myself or the users.

11/15 There are still several important things to mention:

First, we have been thinking of increasing the safe deposit (to reduce the number of attacks), but discarded this idea. The reason -- it would make the bridge more permissioned and we fight for decentralization.

12/15 Second, the security is in the hearts of Aurora Labs team and that's the reason why we have alerts, automatic systems, audits and bug bounties.

In fact we payed out the second largest bug bounty in the world to secure our users!

13/15 Third, to all the builders in web3, there's no way you can omit attack attempts. Please, make sure that you have enough systems in place to mitigate these attacks.

My heart is bleeding when I see great builders unfortunately failing because of these.

14/15 And forth, dear attacker, it's great to see the activity from your end, but if you actually want to make something good, instead of stealing users money and having lots of hard time trying to launder it; you have an alternative -- the bug bounty

Ultimate Outcome

The situation was resolved quickly with the attacker losing their 5 ETH safety deposit.

Debate About Increasing Safe Deposit

"[W]e have been thinking of increasing the safe deposit (to reduce the number of attacks), but discarded this idea. The reason -- it would make the bridge more permissioned and we fight for decentralization." "[D]ear attacker, it's great to see the activity from your end, but if you actually want to make something good, instead of stealing users money and having lots of hard time trying to launder it; you have an alternative -- the bug bounty."

Total Amount Recovered

No funds were lost, so no recovery was required.

Ongoing Developments

The case appears to have been concluded already.

Individual Prevention Policies

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

The only entity losing funds in this case was the attacker, who by all accounts appears to have been attempting to defraud the protocol.

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.

This system seems to have worked effectively due to the multi-signature nature of having multiple independent validators to approve the transactions. Such a system likely works well to automatically approve small value transactions, where there is minimal incentive to attack, with continual adaptation and a small treasury to pay out any losses available. Larger transactions would likely benefit from human oversight as it can be challenging to be sure that the automated systems will effectively detect the full diversity of potential fraudulent transactions. There is a tendency for all nodes to employ similar software that will make the exact same decision, thereby negating key benefits of the multi-signature setup.

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.

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