Web3 Security Auditor's 2024 Rewind - The Highlights

Author: Ionut-Viorel G?ngu Co-authors: Yuguang Ipsen & Frank Lei

Introduction

Previously known as the Ethereum Smart Contract Auditor's Rewind, the article series was originally authored by Patrick Drotleff, an Information Security and Privacy advocate, independent security researcher, and mentor in the Secureum community. After connecting at TrustX Istanbul, Patrick entrusted us with continuing this tradition while he shifted focus to new endeavors.

We've adhered to the original format, delivering concise, actionable insights for each incident—highlighting the vulnerabilities and offering just enough context to identify these issues during security reviews or bug hunting. To increase the diversity of issues, this year's compilation expands beyond exploits to include bugs uncovered through traditional audits, contests, and bug bounty platforms. Additionally, as auditing increasingly encompasses off-chain infrastructure, we've included vulnerabilities from Rust and Golang systems like blockchain nodes or CEX on-ramping infrastructure.

The Highlights

EIP-1153: Transient Storage

The Ethereum Cancun-Deneb upgrade introduced transient storage, a short-lived data space similar to persistent storage but lasting only through a transaction. Developers can declare a variable transient or leverage tstore and tload assembly instructions to interact with transient storage, benefiting from its cost-efficiency. At roughly 100 gas per operation, it is significantly cheaper than traditional storage, which typically requires around 20,000 gas for reads and writes. However, with increased complexity comes increased risk, and transient storage is no exception:

• Due to the low gas cost of accessing transient storage, reentrancy attacks with low gas stipends (like the 2300 gas allowance through address.transfer) are now possible. If a code block does not follow the checks-effects-interactions pattern nor uses ReentrancyGuard, security researchers should ensure that transient storage variables are safe from reentrancy-based modifications, as such changes could lead to malicious or unintended contract behaviors.
• Currently, transient storage supports only reading and writing value types. Because data structures are reference-types, developers that want to use them must implement workarounds that sacrifice type-safety. This Solidity Underhanded Contest submissiondemonstrates how the absence of type-safety can lead to accidental decoding of data into a structure with a similar layout but different meaning, which can introduce subtle and potentially exploitable errors.
• Lastly, while transient storage is automatically cleared at the end of a transaction, developers should explicitly clear it to prevent possible interactions with the contract in a "dirtied" transient state. The following article details how reverts or incorrect behavior can occur during multicalls or complex interactions between contracts within the same transaction.

Uniswap V4 Double-Entrypoint Tokens Critical

In 2024, Uniswap V4 has gone through several thorough audits, one of which uncovered a critical issue involving the deployment of the protocol on chains where the native tokens also have an ERC20 representation.

In Uniswap V4, the settle function manages debt by increasing the account delta for the specified token. It uses msg.value for native token deltas and the balance change since the last sync or settle call for ERC-20 tokens. This mechanism can be exploited on chains where native tokens, like CELO on Celo, also have ERC-20 representations: After syncing to load current balances, an attacker can first call settle with msg.value > 0 to increase the delta for the native token, then call settle with the ERC-20 token's address. Since the balance of the ERC-20 token has increased from the first call, the attacker can inflate the delta without transferring actual tokens in the second call, allowing them to later withdraw more tokens than they deposited, effectively draining the pool.

The fix ensures that the settle call must settle the previously synced token, otherwise the transaction will revert.

Polygon PoS Voting Takeover and Infinite Mint Bug

The following research article uncovers how the Polygon bridge could have been drained by combining a rogue validator with two issues found in the Heimdall validator code.

The Polygon Proof-of-Stake network is made of three layers:

1. Ethereum Contracts: Manage staking, checkpoint submissions and validator rewards.
2. Consensus Layer (Heimdall): Determines block producers based on Ethereum's staking state and pushes checkpoint updates.
3. Execution Layer (Geth fork): Produces new blocks.

When users stake MATIC on Ethereum, a StakeUpdate(uint256 validatorId, uint256 nonce, uint256 newAmount)event is emitted. Off-chain components notify Heimdall, which increases the validator's voting power for consensus. To verify the legitimacy of such events, Heimdall queries Ethereum to ensure the event indeed exists, the field values match and the nonce aligns with the one stored on Polygon.

The first issue arises because Heimdall fails to validate event types. If the Ethereum contracts emit a similarly structured event like SignerChange(uint256 validatorId, address oldSigner, address newSigner), Heimdall could misinterpret it as StakeUpdate. In this scenario, Heimdall would parse oldSigner as nonce and newSigner as newAmount. A rogue validator could emit a SignerChange event with an oldSigneraddress matching their Polygon nonce and a newSignerthat parses into a massive newAmount, artificially inflating their voting power.

The second issue lies in how Heimdall validates nonce. The event's 256-bit nonce is truncated to uint64, dramatically lowering the computational difficulty of generating an oldSigneraddress matching the nonce on Polygon.

An attacker needs only the last 64 bits of oldSigner to align. Although quite limited, the attacker can further reduce the necessary computational effort by altering their nonce through on-chain actions.

With overwhelming voting power, the attacker could have manipulated consensus to accept fake deposit events, arbitrarily minting funds on Polygon. By bridging the funds back to Ethereum, they could have drained the Polygon bridge. Fortunately, the bug was responsibly disclosed and fixed without any incident and loss of funds.

Compound DAO Governance Attack

In July, the Compound DAO faced an attack aiming to pass a malicious governance proposal. This proposal sought to transfer 499K COMP tokens — 5% of the total supply, valued at $25 million at the time — from the treasury to an investment vault. Besides the transfer, the tokens' voting power would also be delegated to the proposers. Given that Compound's voting turnout is usually 4-5% of the total token supply, the attackers could have controlled the governance process by passing this proposal. By being able to pass any malicious proposals, the Compound TVL and treasury funds would be put at risk.

The attack involved three proposals:

• Proposal 247 (May 6th): was created directly on-chain, without a corresponding forum post detailing it, process which is customary within the Compound community. The proposal meant to send 92K COMP tokens from the treasury to a multisig owned by the “GoldenBoyz”, promising the tokens would be further invested into a vault that deposits them for yield into Balancer. This raised suspicions within OpenZeppelin and one of our colleagues promptly notified the community about the possibility of malicious activity. The proposal was subsequently cancelled after being heavily voted down.
• Proposal 279 (July 15th): This time accompanied by a forum post, it intended to transfer funds via a TrustSetup smart contract directly into the vault, bypassing the "GoldenBoyz" multisig. While this was an improvement, new concerns were raised that the tokens' voting power was delegated to the "GoldenBoyz" multisig before investment. This proposal was heavily voted down and did not pass.
• Proposal 289 (July 24th): Identical to the secondary proposal, except for the amount now being 499k tokens instead of 92k. Despite the community being promptly made aware, the "GoldenBoyz" mustered enough votes to pass the proposal. It is suspected that the first two proposals were only created to gauge the usual voting power of the community, only to accumulate more funds in the meantime and overwhelm the opposition at the vote of the third proposal. Moreover, most "for" votes were cast right at the end of the voting period (See "Timeline" in Tally), restricting the community's capacity to respond.

Given the previous voting power of the "GoldenBoyz" and the newly granted 499K COMP tokens, the succesful execution of Proposal 289 could have given the attackers control over Compound Governance, rendering other large delegates powerless against any malicious proposals.

The community counteracted with Proposal 290, aiming to transfer the timelock admin to the Community Multisig and restrict the "GoldenBoyz" from executing malicious actions against the DAO treasury and the protocol. Thanks to rapid action by Compound delegates in collaboration with OpenZeppelin and other parties, this emergency proposal neutralized the threat by preventing the misuse of the newly acquired voting power.

Ultimately, the "GoldenBoyz" reached an agreement with the DAO and canceled Proposal 290 before its execution. While they and affiliated accounts retain significant voting power, it currently doesn't pose an immediate threat to the DAO but warrants ongoing vigilance.

As an additional security measure, the Compound protocol added a temporary proposal admin which has the power to cancel malicious proposals.

Kraken Exchange Balance Printing Bug

Centralized exchanges typically maintain user balances off-chain, updating them based on observed on-chain deposits and exchange activity. Users are assigned deposit addresses, and once a transfer to these addresses is detected, their exchange account is credited with the deposited tokens.

In June, a critical bug in the Kraken Centralized Exchange was reported, allowing malicious users to inflate their account balances without completing the actual on-chain deposit process. While user funds remained safe, this flaw endangered Kraken's treasury by enabling attackers to create and withdraw fake balances as real on-chain funds, totaling ~3M USD.

Details from DanielVF's analysis and his proof of concept suggest that if crafted correctly, a reverting token transfer would be interpreted by the Kraken system as a valid deposit. It is important to note we could not find an official post-mortem detailing the exact technical details behind it.

A transaction containing an inner call that transferred funds and subsequently reverted was mistakenly considered as valid deposit, without taking into consideration the rollback of the inner call. The credited exchange amount matched the token transfer in the reverted transaction, and hence attackers could amplify their gains using flash loans to inflate the apparent deposit value.

Ongoing investigations aim to clarify whether this was a proof-of-concept demonstration by researchers or a malicious attempt at fund theft.

Radiant Capital Hack

In October, Radiant Capital suffered a security breach resulting in the loss of approximately $50 million. At least three developer devices were compromised through a sophisticated malware injection further detailed in an incident update. The compromise allowed the attackers to intercept authentic transaction data from the Safe UI and tamper with it by the time it reached the signature process done by hardware wallets, ultimately resulting in gathering signatures of different, malicious on-chain actions.

The attack involved altering transaction details sent to the hardware wallet. While the Safe frontend displayed legitimate transaction data, the actual transactions being signed were malicious, enabling attackers to execute a transferOwnershipcall after a quorum of 3/11 authorized signers was reached.

By becoming the owner of Radiant's LendingPoolAddressesProvider contract, the attackers changed the implementation behind lending pools proxies and stole all funds and previously given token approvals. The discrepancy between the signature expected by Safe and the signature given by the hardware wallet caused errors within the Safe UI and during on-chain execution, but this did not cause immediate suspicions as such errors were common when submitting meta-transactions and hence, were not subject to detailed analysis.

For a deeper understanding of how Safe interacts with hardware wallets and the risks of blind signing, refer to this analysis.

Conclusion

Similar to previous years, 2024 has been rich in valuable research, innovative vulnerabilities and creative exploits. It's important to emphasise that the intent behind the article is not to criticise or blame the affected projects, but rather provide objective overviews that serve as educational material for the community to learn from and better protect projects in the future.

Read the whole blog post to discover both “The Highlights” and “The Usual” for a fuller perspective: https://blog.openzeppelin.com/web3-security-auditors-2024-rewind