Welcome back to Sherlock's Vulnerability Spotlight, where we highlight an impactful vulnerability uncovered during a Sherlock audit. This week, we have Deposit Spoofing. It was uncovered by @0xalpharush & @bernd_eth on the @zetablockchain Cross-Chain Contest. 🧵

Here is @bernd_eth's summary of the vulnerability: 1. ZetaChain’s observers monitor transactions on external chains (e.g., Ethereum, Solana) and add them to a centralized inbound tracker to process them as deposits and withdrawals, assuming transaction success. 2. Unlike the EVM integration, Solana’s implementation skips transaction success checks, allowing a malicious observer to add failed deposits, minting unbacked ZRC20 SOL, and draining bridged funds. 3. Despite observers being explicitly allowlisted by ZetaChain, it is critical to ensure that no single party can compromise the chain or siphon assets.

Normally, observers don't process failing transactions, but this code path fails to perform the same validation as its EVM counterpart. While this requires a "privileged" role, every validator is an observer, and BFT consensus is supposed to be byzantine tolerant, i.e., tolerate <1/3 malicious parties. Thus, one malicious observer should not be able to forge a deposit and induce honest validators to vote to mint ZRC20 Sol for failed transactions through the inbound tracker, which lacks validations for its Solana implementation.

The root cause of this vulnerability: The ProcessInboundEvents function does not require a transaction to have succeeded, unlike the EVM inbound observer, which does this correctly here. Since the instruction is decoded as if it succeeded, a malicious observer can spoof a deposit for the entire ZRC20-SOL balance and then withdraw the SOL locked in the Solana side of the bridge, stealing all lamports in the bridge. This attack could also be used to withdraw SPL tokens or perform arbitrary deposits and calls. For example, removing the writable property from the gateway’s PDA in the deposit instruction results in a failing transaction (see the anchor constraint error in the POC), and it can still be processed once added to the inbound tracker via MsgAddInboundTracker.

Internal Pre-conditions: A malicious or negligent observer adds a failing Solana tx that contains Gateway instructions to the inbound tracker using MsgAddInboundTracker, resulting in all validators processing and voting to mint ZRC20 Sol on Zetachain. The CCTX receives sufficient votes, and unbacked ZRC20 Sol on Zetachain is minted.

External Pre-conditions: Any party sends a failing transaction to the gateway with a deposit instruction (or deposit and call). The recipient of the ZRC20 Sol on Zetachain withdraws it and receives lamports on Solana.

The Attack Path: 1) Any party sends a failing transaction to the gateway with a deposit instruction (or deposit and call). 2) A malicious or negligent observer adds a failing Solana tx that contains Gateway instructions to the inbound tracker using MsgAddInboundTracker, resulting in all validators processing and voting to mint ZRC20 Sol on Zetachain. 3) The ProcessInboundTrackers task causes the spoofed CCTX to receive sufficient votes, and unbacked ZRC20 Sol on Zetachain is minted. 4) The recipient of the ZRC20 Sol on Zetachain withdraws it and receives lamports on Solana.

What's the impact? All lamports and SPL tokens deposited in the Solana bridge can be stolen, given that deposits can be forged for any amount (they are processed despite the Gateway program causing the transactions to revert).

The Mitigation: In the Solana Observer's inbound tracker processing, check if the transaction is successful before voting on it.

We are proud to have helped secure @zetablockchain through this discovery. When it absolutely needs to be secure, Sherlock is the right choice.