Merkle proof

Slow Fog: The eligibility for the Connext airdrop is verified through a Merkle proof, and users who are not eligible cannot bypass the verification to claim someone else's airdrop

ChainCatcher message, according to SlowMist intelligence, some accounts' NEXT tokens have been claimed to unintended addresses. The SlowMist security team followed up with an analysis and shared a brief summary as follows:Users can claim NEXT tokens through the claimBySignature function of the NEXT Distributor contract. There are two roles involved: the recipient role, which is used to receive the claimed NEXT tokens, and the beneficiary role, which is the address eligible to receive NEXT tokens, determined when the Connext protocol announced the airdrop eligibility.When a user claims NEXT tokens, the contract performs two checks: first, it checks the signature of the beneficiary role; second, it checks whether the beneficiary role is eligible to receive the airdrop. During the first check, it verifies whether the recipient provided by the user is signed by the beneficiary role, so arbitrarily providing a recipient address without the beneficiary's signature cannot pass the check.If a beneficiary address is specified to construct a signature, it may pass the signature check, but it will not pass the second check for airdrop eligibility. The airdrop eligibility check is performed through a Merkle proof, which should be generated by the official Connext protocol. Therefore, users who are not eligible to receive the airdrop cannot bypass the check to claim someone else's airdrop.

Cosmos Co-founder: Hackers forged Merkle proofs through RangeProof in the BNB Chain attack incident

Chain Catcher news, Cosmos co-founder Ethan Buchman commented on the attack incident of the BNB Chain cross-chain bridge BSC Token Hub, stating that the key issue in this incident is that the hacker was able to forge the Merkle proof. This should not have happened, as Merkle proofs are supposed to provide high integrity. Blockchain light clients (and IBC) are built on top of Merkle proofs, and many blockchains store data in Merkle trees, allowing for the generation of proofs that certain data is included in the tree.The Cosmos chain uses a Merkle tree called IAVL, and the IAVL repository has made an API available that uses a RangeProof. However, it has been found that there are serious flaws in the internal workings of RangeProof. The issue with the IAVL RangeProof code is that it allows the Left and Right fields of the InnerNode to be filled, and the attacker essentially exploited the advantage of pasting information into the Right field, which was never validated and never affected the hash calculation, leading the verifier to believe that certain leaf nodes are part of the tree. As a result, they successfully forged the Merkle proof.Buchman stated that while using RangeProof is not a good idea, there is a way to address this issue: preemptively rejecting the proof when any internal node has both the left and right fields filled. For the Merkle proof in IBC, IBC does not use the built-in RangeProof system of the IAVL tree, but instead uses the ICS23 standard to generate and validate Merkle proofs from the IAVL tree. The ICS23 code does not have this vulnerability, as it explicitly "rejects" RangeProof. (Source link)
ChainCatcher Building the Web3 world with innovators