The Confused Deputy Problem
Often, the off-chain component will hold a cryptographic key, which gives it power. Many security reviews (rightly) focus on the secure storage of the cryptographic keys, but they tend to forget something. What attackers are ultimately after is the power the key represents.
In information security, this is known as the Confused Deputy Problem: tricking another program into using its power in an unintended way.
A famous example in the blockchain world was the wave of bridge exploits, where off-chain components were tricked into misinterpreting EVM events. Those tricked components then bridged or unlocked funds without receiving the correct counterpart.
Notable examples include:
- THORChain's Bifrost module was tricked by manipulated Deposit events emitted through crafted contract interactions, causing it to credit deposits that never occurred (~$13M lost).
- pNetwork's off-chain nodes processed fake peg-out event logs from attacker-deployed contracts without verifying that the events originated from legitimate pToken contracts, leading to 277 BTC stolen.
- Qubit Finance's off-chain relayer could not distinguish between a genuine ETH deposit event and one triggered by a no-op call through a legacy function, resulting in ~$80M drained.
- Meter.io's bridge deposit handler misinterpreted ERC-20 deposit calls as native token wraps, allowing an attacker to trigger deposit events without sending real native tokens (~$4.4M lost).
As multiple of these issues were found, we raced against attackers to identify further vulnerable projects and inform them. Later, we circulated best practices to prevent these issues.
While one might think that tricking off-chain components with events is a thing of the past, we only recently informed a customer of another such vulnerability.
Keeper and Bot Risks: Monitoring ERC-20 Balances the Wrong Way
But events are not the only way to trick off-chain components. Often semi-trusted bots or keepers advance the state machine of DeFi protocols once certain conditions have been reached. A commonly monitored condition is ERC-20 balances. But monitoring balances can also lead to mistakes, as anyone can typically increase a contract's ERC-20 balance. If the monitored conditions are imprecise, e.g. "balanceOf(contract) > 0", then incorrect state transitions can be triggered.
Race Conditions Between Off-Chain and On-Chain State
Race conditions between off-chain and on-chain components represent another critical class of vulnerabilities. A common example can be found in off-chain order books, where users grant on-chain token allowances to back the orders they place. Since the order book operates off-chain, it has no real-time awareness of on-chain state changes. A user — or attacker — can place an order backed by a valid allowance, wait for it to be matched against other orders, and then revoke the on-chain allowance before settlement occurs. When the system attempts to execute the matched trade on-chain, the transaction fails due to insufficient allowance. The consequences extend beyond the single failed order: all legitimately matched counterparty orders are now stuck in a recovery process, effectively removed from the order book until the system detects the failure and re-queues them. Depending on the implementation, this recovery can take considerable time, during which the affected orders cannot participate in new matches. This creates a denial-of-service vector where a malicious actor can repeatedly disrupt the order book by placing and invalidating orders, degrading the trading experience for all participants without any significant cost to themselves.
Reorg Safety: Handling Forks and Finality in Proof-of-Stake Ethereum
Last but not least, off-chain components can even be tricked by blocks. With Ethereum's switch to Proof-of-Stake, forks have been considered a relic of the past. But they are not gone. Off-chain components either need to rely on finalized blocks (and then deal with the associated delay) or correctly handle re-organizations.
Key Takeaway: Preventing Confusion in Off-Chain Components
Overall, it is very important for off-chain components not to get confused. Feel free to reach out to us if you want to learn more about how to avoid these issues or if you want us to help prevent confusion in your off-chain components.