dit is 2025's meest fascinerende beveiligingsvondst imo: een "zero‑day" waar hackers stilletjes op aan het inzetten waren, in de hoop dat het verborgen zou blijven terwijl de toekomstige opbrengst groeide. gelukkig op tijd opgemerkt door de goede jongens. uitstekend werk van @deeberiroz @pcaversaccio @deeberiroz
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /10 jul, 22:13
Het wordt nog fancier: de manier waarop Etherscan werd misleid om het verkeerde implementatiecontract te tonen, is gebaseerd op het instellen van 2 verschillende proxy slots in dezelfde frontrunning tx. Etherscan gebruikt een bepaalde heuristiek die verschillende opslagslots incorporeert om het implementatiecontract op te halen. Er is een oude proxy van OpenZeppelin die de volgende slot gebruikte: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` We hebben nu ook de standaard EIP-1967 slot `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Wat er gebeurde, is dat de oude OpenZeppelin proxy slot werd geschreven met het onschuldige implementatieadres _en_ de standaard EIP-1967 slot ook werd geschreven met het kwaadaardige implementatieadres. Aangezien Etherscan eerst de oude proxy slot opvraagt, haalde het eerst het onschuldige uitziende adres op en toonde het dus.
73