tak jsem zjistila, že je to ještě hezčí. Všiml jsem si, že frontrunning tx (útočníky) volá 'initialize' a protokoly také volají _úspěšně_ 'initialize' poté (takže si myslí, že je vše v pořádku). Ale počkat, jak je to vůbec možné? Musel jsem se podívat velmi hluboko na změny slotu úložiště a odhadnout, co jsem našel: _resetovali_ hodnotu slotu úložiště '_initialized' na konci frontrunning tx (poté, co přešli na škodlivý implementační kontrakt). To znamená, že úložiště proxy nyní vypadá tak, jak nebylo nikdy inicializováno. Relevantní slot pro úložiště, na který se musíte podívat, je 'keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))' = '0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00' To je zlo další úrovně.
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /10. 7. 22:13
Je to ještě úžasnější: způsob, jakým byl Etherscan oklamán a ukázal nesprávnou implementační smlouvu, je založen na nastavení 2 různých slotů proxy ve stejném frontrunning tx. Etherscan tedy používá určitou heuristiku, která zahrnuje různé úložné sloty k načtení implementační smlouvy. Existuje starý proxy server od OpenZeppelin, který používal následující slot: 'keccak256("org.zeppelinos.proxy.implementation")' = '0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3' Nyní máme také standardní slot EIP-1967 'bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)' = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc' Stalo se tedy, že do starého proxy slotu OpenZeppelin byl zapsán s neškodnou implementační adresou _a_ do standardního slotu EIP-1967 se zapsalo také se škodlivou implementační adresou. Vzhledem k tomu, že se Etherscan nejprve dotazuje na starý slot proxy, načetl nejprve neškodně vypadající slot a tak jej zobrazil.
21,49K