Near Protocol Rainbow Bridge First Attack Mitigated

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.

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 a "safe deposit", has watchdogs monitoring the network, and allows validators to flag and reject any suspicious transactions.

On the early morning between April 30th and May 1st (depending on timezone), a fraudulent transaction was submitted. It was successfully detected and mitigated in this case, and no funds were lost.

About Near Protocol

The Near Protocol Rainbow Bridge is a cross-chain bridge allowing tokens to be transferred between the Ethereum, Near, and Aurora blockchains. The protocol has a goal of preventing developers from having to choose just one chain by creating a developer-friendly and low-cost platform.

Website:

Smart Contract:

Guide Video:

Explanation Document:

GitHub:

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

"Innovation across DeFi and NFTs has increased demand on the Ethereum network and sent fees soaring." "Blockchain-based bridges allow users to send and receive tokens between different networks by locking native tokens on either side."

"At NEAR, we do not want Ethereum developers to choose between NEAR and Ethereum and commit to only one. We want them to have the same asset on both blockchains and even have apps that seamlessly communicate across the boundary. So we built a bridge, called Rainbow Bridge, to connect the Ethereum and NEAR blockchains, and we created the lowest possible trust level one can have for an interoperability solution — you only need to trust what it connects, the NEAR and Ethereum blockchains, and you don’t need to trust the bridge itself. There is no authority outside Ethereum miners and NEAR validators."

"The ETH <> NEAR Rainbow Bridge allows users to seamlessly migrate assets to NEAR’s developer-friendly and low-cost platform." "Seamlessly migrate assets to NEAR’s developer-friendly and low-cost platform, without compromising on speed." "The first phase of the ETH ↔ NEAR Rainbow Bridge opens the gates for assets to flow freely between NEAR and Ethereum blockchains while enabling users to bridge any ERC-20 token they wish."

"Ethereum users can easily onboard to NEAR using the ETH Faucet, hosted by Paras, and MetaMask. Simply by logging into MetaMask and proving that their account has a balance higher than 0.05 ETH, anyone can claim a NEAR account and start using the Rainbow Bridge right away."

"Rainbow allows users to send tokens among the Ethereum, Near and Aurora networks and has over $2.3 billion in assets locked on the protocol, data shows." "The following popular tokens with common ERC-20 functionality are interoperable with NEAR, including but not limited to[ s]tablecoins like USDT (Tether), DAI, and TUSD, wrapped assets like WBTC and WETH[, ]DEX tokens like UNI and 1INCH[, l]ending tokens like AAVE and COMP[, and s]ervice company tokens like HT (Huobi) and CRO (Crypto.com)[. ]Users can send these ERC-20 assets directly from MetaMask or other Web3 wallets to NEAR wallets and apps, and vice versa."

"Since the Rainbow Bridge does not require the users to trust anything but the blockchains themselves, we call it trustless." "The ETH ↔ NEAR Rainbow Bridge is a trustless, permissionless protocol for connecting blockchains. The bridge protocol removes the need to trust anyone except the security of the connected chains. Anyone can deploy a new bridge, use an existing bridge, or join the maintenance of an existing bridge without getting approval from anyone else."

"The Rainbow Bridge allows any information that is cryptographically provable on NEAR to be usable in Ethereum contracts and vice versa — including the ability to read the state and schedule calls with callbacks on the other chain. This means a user can vote with their ETH balance in a NEAR DAO without sending a transaction on Ethereum." "The nature of the Rainbow Bridge means its fully decentralized and adaptable to any future protocol changes."

"I personally know about 5 watchdogs that are running 24/7. And no one in the world knows about all of them (a protection from the insiders). You can improve the security by simply running the watchdog script from [GitHub]."

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

The attacker "got some ETH from Tornado to start the attack around [4 AM UTC]." "With th[is] money he deployed a contract that meant to deposit some funds to become a valid Rainbow Bridge relayer and send the fabricated light client blocks." "He was trying to hit the moment to front run our relayer, but failed to do it."

"After it, he decided to send the similar transaction with the block timestamp in the future (+5h)[. T]his transaction successfully substituted the previously submitted block." "Probably, the combination of the high Ethereum fees (and a delay of the block relaying) and a desire to check whether watchdogs are operational or not, were stimulating an attacker to break the bridge in that exact moment."

"For at least 6 months we knew that watchdog transaction would be front run by the MEV bots (reported by our auditors @sigp_io). [The m]ain reason to keep this mechani[sm] is the additional protection: MEV bots know how to get transactions executed ASAP."

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

An attacker attempted to exploit the bridge protocol.

Key Event Timeline - Near Protocol Rainbow Bridge First 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.
April 30th, 2022 10:01:49 PM MDT	Attacker Brings Funds From TornadoCash	The attacker brings some funds from TornadoCash. He wants to make sure his donation is anonymous.
April 30th, 2022 10:07:35 PM MDT	Attack Smart Contract Prepared	The attacker wallet prepares a smart contract in preparation for their attack.
April 30th, 2022 10:10:47 PM MDT	Attacker Tries Hard To Donate ETH	The attacker first tries to donate his Ethereum but it fails because he "[c]an only replace with a sufficiently newer block".
April 30th, 2022 10:21:00 PM MDT	Attacker Generously Donates 5 ETH	The attacker finally succeeds in making his generous donation of 5 ETH to support the Rainbow Bridge.
April 30th, 2022 10:24:03 PM MDT	Transaction Reverted No Block Can Be Challenged	Two transactions. One transaction fails because "No block can be challenged at this time". The other is successful.
April 30th, 2022 10:27:35 PM MDT	Near Protocol Deployer Transaction	A transaction occurs from the Near protocol depoyer.
May 1st, 2022 11:01:00 AM MDT	Twitter Post About The Attack	Alex Shevchenko posts a summary with details of the unsuccessful attack and that the costs for attacking the protocol will also be increased.
August 22nd, 2022 6:31:00 AM MDT	Referenced in Report of Second Attack	The first attack is reverenced in a report on the second attack attempt.
August 23rd, 2022 6:08:00 AM MDT	Referenced In CoinDesk Article	The first attack is referenced in a CoinDesk article on a second attack attempted on the protocol.

Total Amount Lost

No funds were lost, except by the attacker, who lost 2.5 ETH.

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?

"In a short period one of the bridge watchdogs figured out that the block submitted is not in the NEAR blockchain; created a challenge transaction and sent it to Ethereum." "Immediately, MEV bots detected this transaction and figured out that front-running it would result in 2.5 ETH gain, so they did exactly th[at]."

"As a result, [the] watchdog transaction failed[. The] MEV bot transaction succeeded and rolled back the fabricated block of the attacker. Some min[utes] after this, our relayer submitted a new block[.]" "The attack was mitigated fully automatically, Rainbow Bridge users even didn't saw anything happening, continuing transacting in both directions."

The "[a]ttacker lost 2.5 ETH, which was pa[i]d to the MEV bot because of the successful challenge."

"A bit later we started to investigate the strange behaviour and paused all the connectors. And once figured out the details, unpaused them back."

Ultimate Outcome

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

"We [plan to] redesign a bit the challenge payout mechanics, so the majority of the relayer stake is kept in the contract (so, lost to the attacker too), and some fixed amount payed to the watchdog (or MEV bot)." We also plan to "increase the stake for the relayer manyfold, so similar attempts would cost much more." "Money that attackers would loose will be spent for bug bounties and additional audits." "Every watchdog transaction, that would fail because of the front running will be rewarded with a portion of the attacker stake through the manual process. In case this happens, please send me a message."

"I wish everyone who is innovating in the blockchain to pay enough attention to security and robustness of their products through all the available means: automatic systems, notifications, bug bounties, internal and external audits."

Total Amount Recovered

No funds were lost, except by the attacker. The attacker did not recover their funds.

Ongoing Developments

There are no remaining ongoing developments to be concluded.

General Prevention Policies

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.

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.