questa è la scoperta di sicurezza più affascinante del 2025 secondo me: un "zero‑day" su cui gli hacker si stavano silenziosamente posizionando, scommettendo che sarebbe rimasto nascosto mentre il guadagno futuro cresceva. fortunatamente catturato giusto in tempo dai buoni. lavoro eccezionale di @deeberiroz @pcaversaccio @deeberiroz
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /10 lug, 22:13
Diventa ancora più sofisticato: il modo in cui Etherscan è stato ingannato a mostrare il contratto di implementazione errato si basa sull'impostazione di 2 diversi slot proxy nella stessa transazione di frontrunning. Quindi Etherscan utilizza una certa euristica che incorpora diversi slot di archiviazione per recuperare il contratto di implementazione. C'è un vecchio proxy di OpenZeppelin che utilizzava il seguente slot: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Ora abbiamo anche lo slot standard EIP-1967 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Quindi, ciò che è successo è che il vecchio slot proxy di OpenZeppelin è stato scritto con l'indirizzo di implementazione benigno _e_ lo slot standard EIP-1967 è stato scritto anche con l'indirizzo di implementazione malevolo. Poiché Etherscan interroga prima il vecchio slot proxy, ha recuperato prima quello che sembrava benigno e quindi lo ha visualizzato.
80