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.
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.
While the results of these engagements are mostly private, they often have positive effects beyond the individual project. During off-chain reviews, we sometimes uncover bugs in widely used libraries that affect the broader ecosystem. For example, we discovered that viem's verifyTypedData() accepted signatures with arbitrary length, causing a mismatch between off-chain and on-chain signature validation. Off-chain applications relying on this function could accept crafted signatures that would then fail on-chain. Reporting these upstream benefits everyone.
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.
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.