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' section 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.

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

About Near Protocol

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

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

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

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

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

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

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.

Key Event Timeline - Near Protocol Rainbow Bridge First Attack Mitigated
Date	Event	Description
April 30th, 2022 10:07:35 PM	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.

Total Amount Lost

No funds were lost.

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

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?

Ultimate Outcome

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

Total Amount Recovered

There do not appear to have been any funds recovered in this case.

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

What parts of this case are still remaining to be concluded?

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.