The smart contract platform NEAR protocol contained a vulnerability that could have allowed an attacker to crash every node on the network, effectively shutting it down.
According to a Sept. 26 report from blockchain security firm Zellic, which discovered it, the vulnerability was quietly eliminated through a patch in January, but some networks may still contain similar flaws.
In the report, Zellic referred to the flaw as a “Web3 Ping of Death,” due to its ability to bring down an entire network “in an instant.”
Researchers discovered it while investigating NEAR’s peer-to-peer networking protocol for validator nodes, which allows its validators to effectively communicate with each other. NEAR uses a “handshake mechanism” to establish connections between nodes and ensure that nodes are not acting maliciously.
The “remote peer,” or the peer that wants to connect, sends a handshake message to the local peer. In response, the local peer sends back an acknowledgment of the message.
NEAR peer-to-peer connection process. Source: Zellic.
During this process, the remote peer is required to prove its identity by providing a public key and by signing a message proving that it is the owner of that public key. This identity verification process is intended to prevent known malicious nodes from connecting to the network.
When researchers looked at the signature verification function, they discovered an alarming fact. The nodes allowed two types of cryptographic signatures to be accepted.
The first type, based on the Digital Signature Algorithm on Twisted Edwards Curves 25519 (Ed25519), could be verified securely by the nodes.
However, attempting to verify the second type, based on the Standards for Efficient Cryptography Prime Field 256K1 (SECP256K1) curve, would result in a “panic” response that crashes the node.
The verification function for this type of cryptographic signature contained two different vulnerabilities. First, it called an “expect” function and required that the answer contain no more than 32 bytes of data.
However, the answer given by this function was never 32 bytes in length. This meant that the node would crash anytime it attempted to verify a SECP256K1 signature.
NEAR code section containing “.expect()” vulnerability. Source: Zellic.
Second, if the last byte of the signature was not between zero and three, the function “from_i32(),” which was called as part of the verification process, would produce an error.
This error would cause the final “unwrap()” function called at the end of the process to stall, crashing the node. This meant that even if the first vulnerability were fixed, an attacker could deliberately create a malicious signature that could crash the node using the second vulnerability.
Error-throwing function vulnerability in NEAR. Source: Zellic.
Having discovered this flaw, the researchers were surprised that it had not either been caught previously in tests or else crashed the network already.
However, they found that the NEAR node software has “no code path that allows a NEAR node to generate SECP256K1 type keys.” In other words, although the software allowed nodes to accept SECP256K signatures, it did not allow them to produce such signatures.
As a result, no node had ever accidentally crashed the network by creating SECP256K keys and attempting to connect to another node.
Even so, a malicious node could alter the software to allow SECP256K keys to be generated. And once they did, they would have the power to crash any NEAR node simply by attempting to connect to it. The result could take down the entire network, constituting a “Web3 Ping of Death.”
To prove that the vulnerability was real, the researchers first created a version of the NEAR software containing a malicious patch that allowed SECP256K keys to be generated.
They then launched two nodes on a private testnet version of NEAR. The first node ran the legitimate software provided by developers, while the second ran the malicious version.
After the first node began producing blocks, the second node attempted to crash the first one by exploiting the two vulnerabilities. They found that the malicious node succeeded at crashing the legitimate one every time.
Magazine: Suspicious arrest of crypto scam reporter, Japan’s pro-crypto PM: Asia Express
Zellic secretly disclosed the vulnerability to the NEAR team in December, using HackenProof’s bug bounty platform to facilitate the disclosure. In response, the team paid Zellic a $150,000 reward and patched the node software in January.
During this intervening time period between discovery and patch, no attacker discovered the flaw, and the network remained online.
The discovery of the vulnerability provided a happy ending to what otherwise could have been a story of crisis.
Other blockchains have not been lucky enough to avoid flaws that resulted in crashes. In December, the Arbitrum network went down for over 78 minutes, preventing users from making any transactions.
Developers later revealed that this downtime was caused by a surge of inscription minting, which the network was inadequately prepared to handle.
According to developers, in January, around 50% of Cardano nodes went down due to an “anomaly.” The disruption caused block production to slow, giving rise to longer transaction confirmation times. However, it did not cause the entire network to go down.
In February, the Solana network failed to produce a block for over 25 minutes. This was the latest of several Solana crashes, which some users have heavily criticized.
