misbahu

This hacker got free $500k from a single bug on ERC404 On February 14, 2024, the MINER project, built on the experimental ERC404 standard, was exploited for 168.8 ETH, roughly $470,000. The hack was possible due to a misimplemented transfer function in the project’s ERC-X contract, a hybrid of ERC20, ERC721, ERC1155, and ERC404 standards. I will break down the technical and conceptual details of the hack. What is ERC404? ERC404 is an experimental Ethereum token standard that combines fungible (ERC20) and non-fungible (ERC721) token properties. It is a framework where one whole ERC404 token represents both an ERC20 token and an ERC721 NFT. If a wallet holds one full ERC404 token, it owns the corresponding NFT. If the balance drops below one token (e.g., 0.5 tokens), the NFT is burned, and the wallet holds only the fractional ERC20 tokens. This mint-and-burn mechanism ties ERC20 liquidity to ERC721 uniqueness, enabling fractional NFT ownership. What is the MINER Project? MINER is a collection of 100,000 avatars linked to ERC-X tokens, which are built on a custom implementation of ERC404. Each ERC-X token is a hybrid asset that can function as both a fungible token (tradable on decentralized exchanges like Uniswap) and an NFT (tradable on marketplaces like OpenSea). The project aimed to leverage ERC404’s fractionalization to increase liquidity for its avatars. The Misimplemented Transfer Function The ERC-X contract’s transfer function is the mechanism that moves tokens between addresses. In the MINER project, this function contained a critical flaw: it failed to check if the sender (`from`) and receiver (`to`) addresses were different. Here’s how it worked: - The Bug: The transfer function checked that `from` and `to` were not null addresses but did not verify that `from != to`. This allowed an attacker to call the transfer function with the same address as both sender and receiver. - The Exploit: When the transfer function was called, it invoked an internal `_update` function. This function cached the sender’s and receiver’s balances in memory, subtracted the transfer amount from the sender’s balance (`fromBalance - value`), and added it to the receiver’s balance (`toBalance + value`). If `from` and `to` were the same address, the subtraction and addition canceled out, but the function still updated the balance to `toBalance + value`. This effectively increased the attacker’s balance without any actual transfer, allowing them to mint new tokens for free. - The Impact: The attacker exploited this double-spend vulnerability to siphon 168.8 ETH from the contract, causing a 60% price drop in MINER tokens, as reported by Geckoterminal. Why Did This Happen? The root cause is a lack of input validation in the transfer function. A simple check (`if (from == to) revert;`) could have prevented the exploit. The ERC404 standard’s experimental nature also contributed, as it has not been formally audited or adopted by the Ethereum community. Deployed just days before the hack, the MINER contract lacked rigorous testing, exposing it to known vulnerabilities. For Developers: - Input Validation is Non-Negotiable: Always validate that `from` and `to` addresses differ in transfer functions. A single line of code can prevent catastrophic losses. - Before deploying contracts using experimental frameworks, conduct thorough audits and stress-test edge cases. - Follow Best Practices: Use established libraries like OpenZeppelin for ERC20 and ERC721 implementations, which include battle-tested transfer logic. For Security Researchers: - ERC404’s mix of ERC20 and ERC721 introduces unique risks, such as collisions in transfer events or mint-and-burn logic. Prioritize analyzing these overlaps for new attack vectors. - Test Self-Transfer Scenarios - Monitor New Deployments For Crypto Traders: - Avoid Unaudited Projects - Watch for Price Anomalies, A 60% price drop signaled the MINER exploit. - Use Burner Wallets

I just found a bug and got paid on @immunefi #immunefitribe immunefi.com/s/ss/?severity=…

I just found a bug and got paid on @immunefi #immunefitribe immunefi.com/s/ss/?severity=…