Near Protocol Rainbow Bridge Second 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.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

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.

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

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

"As a wholly decentralized platform, Rainbow relies on several validators, called bridge relayers, who submit block info on Near blocks to Ethereum. Anyone can submit information to Rainbow, and false information could likely result in a loss of all user funds."

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

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

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

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

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 Second Attack Mitigated

Date	Event	Description
August 20th, 2022 10:49:19 AM MDT	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?

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.