NEAR Protocol is a blockchain platform that aims to provide developers with an easy-to-use platform for building decentralized applications . NEAR isn’t just a Layer 1 — it’s also the Blockchain Operating System (BOS) for an open web. The BOS is a fully Web3-native stack that unifies the Web3 space into a single interface and a common layer for building, browsing, and discovering Web3 experiences on any blockchain. On the BOS, developers can create or fork components to build frontends using languages they already know, like JavaScript.
NEAR Protocol uses a consensus mechanism called Proof of Stake, which is designed to be more efficient than the traditional Proof of Work consensus mechanism used by platforms like Bitcoin. This helps to reduce the environmental impact of blockchain technology while maintaining a high level of security.
Overall, NEAR Protocol aims to make it easier for developers to build decentralized applications by providing a high-performance and developer-friendly platform. It has gained popularity in the blockchain community due to its usability and easy onboarding as well as its potential to scale to Web2-scale global usage.
Summary
Two anonymous white hats submitted three vulnerabilities to the NEAR Protocol bug bounty program in January-February of 2023 via HackenProof. Exploitation of the discovered issues by malicious actors could have resulted in substantial financial losses. Due to the diligent efforts of ethical researchers at HackenProof and the prompt response from the NEAR team, these vulnerabilities were responsibly disclosed instead of being exploited, ensuring that no user funds were compromised.
As a result:
- The NEAR team promptly addressed and resolved all identified issues once they were discovered.
- Following the successful remediation of all three vulnerabilities, the NEAR team compensated the researchers with a total payment of $1.8 million.
- Among the three issues, two were classified as “critical”.
This serves as an outstanding testament to the commendable work and responsibility of the NEAR team. Not only did they respond promptly to these incidents, but they also made a valuable contribution to the Web3 security community by responsibly disclosing these issues.
Let’s jump to the review of these vulnerabilities:
Issue #1. Unvalidated BlockHeaderInnerRest ::challenges_result allows to slashing of validators stake
The NEAR protocol provides the mechanism of challenges, intended to identify malicious validators and slash their stake. It takes two consecutive blocks to perform a challenge:
- Newly collected challenges are published in the first block as Block::challenges. When the block is processed by network nodes, challenges are verified and the list of SlashedValidator is computed, each holding an account ID of a validator to be slashed.
- The list of SlashedValidator is published in the second block as BlockHeaderInnerRest::challenges_result. Processing of this block does the actual slashing. If SlashedValidator::is_double_sign is false, then the validator is assumed to be malicious and all of its locked balance is burned.
The problem was that there was no validation of challenges_result by network nodes. A block producer could craft an arbitrary list of validators to be slashed.
For maximal damage, an attacker could slash each of the all validators holding locked balance by sending a single malicious block. This discovery revealed a significant risk, as it could potentially impact almost half of all NEAR.
Issue #2. Total supply manipulation to increase of validators rewards
In the middle of February, the whitehat with username jinxorder discovered a Critical vulnerability in validators’ reward calculation functionality.
The field total_supply inside the block header was never validated. As a result, it was possible to produce blocks with any value set for total_supply. Therefore any block producer producing a block could override the value of total_supply for the entire network.
The value of total_supply is used to determine validators’ rewards which are calculated at the end of every epoch, according to the total_supply written at the header of the last block for that epoch. There is a linear relationship between total_supply and the rewards received by a validator.
The field total_supply inside the block header was never validated. As a result, it was possible to produce blocks with any value set for total_supply. Therefore any block producer producing a block could override the value of total_supply for the entire network.
Discovered vulnerability showed that by setting certain values for total_supply, it was possible to increase validators rewards about 300_000-fold. Or, alternatively, it was possible to set total_supply such that validators rewards were close to 0.
According to NEAR’s staking calculator, an account staking about 100_000 USD in $NEAR could earn about 26 USD per day. If the attack was mounted, the same staking amount could earn 26 * 300_000 = 7_800_000 USD per day!
The staked funds could be unlocked within one or two epochs.
Validation steps:
To successfully exploit this, the attacker would pick an arbitrary value for the total_supply field in the block header and write an integration test that processes a block with a malformed total_supply.
We should add the following test (based on test_block_ordinal() )
Then, select an arbitrary value for new_total_supply at Block::produce()
In our case, we added 1, but it may be changed to any value and the block will still be accepted.
Running our integration test, the bug hunter discovered that indeed the total_supply was not being validated.
But how to get an impact from that?
The function RewardCalculator::calculate_reward() calculates the validators’ rewards based on several parameters, and one of those parameters is total_supply.
Total distributed reward for the epoch is calculated as:
Treasury’s reward is calculated as:
And validators’ reward is calculated as:
let epoch_validator_reward = epoch_total_reward – epoch_protocol_treasury;
Note that in the calculations above, epoch_validator_reward depends linearly
on total_supply. For example, if total_supply is tripled,
epoch_validator_reward is also tripled. This means that by controlling
total_supply, we can change the value of epoch_validator_reward.
Remediation:
To fix this issue, the NEAR Protocol should validate the total_supply field in the block header for every incoming block. For an incoming block, the total_supply header field should equal previous_block_total_supply + minted_amount – balance_burnt. Special care should be taken for the end of each case.
The best place to perform the validation would be at `validate_header() at chain/chain/src/chain.rs.
Issue #3. Unvalidated BlockHeaderInnerLite ::outcome_root could lead to stealing Rainbow Bridge’s locked funds
NEAR’s block header holds the BlockHeaderInnerLite::outcome_root hash, which is the Merkle root of the outcome_root hashes of all chunks belonging to that block. Each chunk’s hash is in turn the Merkle root of execution outcomes belonging to that chunk. A block producer computes the block’s outcome_root here.
The problem was that there was no validation of an incoming block’s outcome_root by network nodes. A block producer could craft an arbitrary hash and get it incorporated in the chain. With a fake outcome_root, an attacker could craft an arbitrary execution outcome by an arbitrary NEAR account along with a Merkle proof of that outcome.
Unfortunately, a block’s outcome_root is the crucial piece of data used by Aurora’s Rainbow Bridge to verify that tokens were burned on the NEAR side before unlocking them on Ethereum side. A crafted proof could request the ERC20Locker to perform a transfer of any amount of any token to any account. In fact, many outcomes could be crafted under a single Merkle root. Once a malicious block was relayed to Ethereum, a single transaction is all that’s needed to steal all the tokens.
The Aurora team was promptly notified roughly 30 minutes after the submission, which led to the immediate suspension of Rainbow Bridge for further investigation.
A detailed review of the Aurora findings, compiled by their CEO Alex Shevchenko, can be accessed and viewed here.
Acknowledgment
We would like to extend our sincere appreciation to the HackenProof security researchers for their diligent efforts and responsible disclosure of their findings. This serves as an important reminder of the value of public bug bounty programs and how independent researchers can contribute to the progress of the entire industry. Our thanks also go out to the NEAR and Aurora teams for their swift investigations, active involvement, and generous bounties.
In addition to the substantial payment of $1.8 million to the researchers for their commendable efforts, the paramount outcome lies in safeguarding the security of over 25 million NEAR users.
A noble cause
The hacker under the nickname “blazezaria”, who received his bounty under unlock period of 1 year, promised to donate 10% of each bounty unlocked to the charity organization in Ukraine “Come Back Alive”, which in total will be resulted in donations an amount of 100 000 dollars.
“Come Back Alive” is a Foundation providing competent assistance to the military. The Foundation purchases equipment that helps save the lives of the military, including thermal imaging optics, quadcopters, cars, security, and intelligence systems.
The process has already started, with the first payment released, amounting to 8,290 USDT. The transaction, verifiable at Tronscan, showcases the promise fulfilled by the hacker.
Every hacker and continue this noble cause and donate part of their bounty for Come Back Alive
Bug Bounty for NEAR Ecosystem
As a prominent Web3 ecosystem, NEAR consistently prioritizes security and supports the members of its community. Recent statistics show that 20% of projects in the ecosystem have undergone a security audit. This number, comparatively higher than the rest of the industry, showcases a proactive and dedicated approach to cultivating a robust and secure ecosystem.
For researchers: we encourage you to stay informed about the current NEAR bug bounty programs on HackenProof by visiting this link: https://hackenproof.com/near. By participating, you have the opportunity to earn up to a $1 million bounty for valid issues you discover.
For the community: If you are involved in building on the NEAR blockchain and considering implementing a bug bounty program, we strongly encourage you to seek advice from the NEAR or HackenProof teams. They are readily available to provide guidance and support in establishing effective bug bounty initiatives to enhance the security of your projects.
Also, please follow NEAR and HackenProof on Twitter to stay updated.
