BlockThreat - Settimana 28, 2025 💙 Sponsorizzato da @SecurityOak 🔥 Sfruttamento di massa di contratti proxy scoperto da @deeberiroz e whitehatted da @pcaversaccio @dedaub e @_SEAL_Org 💸 Hack di reentrancy di @GMX_IO $42M ($37M recuperati) 💸 @KintoXYZ proxy non inizializzato. $1.55M

Lezioni per esperti di sicurezza: Auditare rigorosamente le inizializzazioni dei proxy. Monitorare le catene di delegatecall (facile da fare nella nostra app) e garantire l'integrità dello storage con schemi di proxying complessi. Riconoscimenti a @deeberiroz @VennBuild @pcaversaccio @_SEAL_Org Rimanete vigili.

quindi ho scoperto che è ancora più sofisticato. Ho osservato che la tx di frontrunning (da parte degli attaccanti) chiama `initialize` e i protocolli chiamano anche _con successo_ `initialize` dopo (quindi pensano che tutto sia normale). Ma aspetta, come è possibile? Ho dovuto esaminare molto a fondo le modifiche agli slot di memoria e indovina cosa ho trovato: _resettano_ il valore dello slot di memoria `_initialized` alla fine della tx di frontrunning (dopo che hanno scambiato il contratto di implementazione malevolo). Questo significa che la memoria del proxy appare ora come se non fosse mai stata inizializzata. Lo slot di memoria rilevante da esaminare è `keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))` = `0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00` Questo è un livello di malvagità superiore.

All'inizio di questa settimana, è stata identificata una potenziale vulnerabilità nel contratto del gestore cross-chain di Orderly sulla catena BNB. In risposta, il nostro vault BNB per depositi e prelievi è stato immediatamente messo in pausa, i contratti sono stati migrati e i depositi/prelievi sono ripresi entro 2 ore. ✅ Nessun fondo degli utenti è a rischio o è stato perso. Un ringraziamento speciale a @deeberiroz, @VennBuild, @seal_911, @pcaversaccio e al resto del team che ha aiutato a segnalare questo! Più sicuri insieme 🤝

[5/5] Chiamata di gratitudine • @SlowMist_Team per il triage e la correzione incessanti • @dedaub, @pcaversaccio e il war-room di @seal_911 per un controllo del codice di 36 ore • @etherscan per la pulizia dell'interfaccia utente fulminea • E ancora, grazie @deeberiroz, @VennBuild, @davidberiro—il vostro avviso ha salvato la giornata 💙

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.

RT @devops199fan: .@seal_911 funge fondamentalmente da centro operativo globale di sicurezza volontaria (GSOC) per le criptovalute siamo fortunati ad avere persone come...

Non lo so, amico, ma la vera minaccia per Ethereum non è lo stato, in realtà (almeno non oggi). Sono i VC e i professionisti dei protocolli che cercano di trasformarlo in un lucido parco giochi fintech per un DeFi "sicuro" e conforme. Ascoltami: non vogliono codice inarrestabile. Non vogliono resistenza. Vogliono cazzo di _controllo_. Perché nel profondo sanno cosa potrebbe diventare Ethereum se fosse lasciato libero: un layer di esecuzione globale resistente alla censura e incentrato sulla privacy che nessuno stato, nessuna azienda, nessun cartello di tute potrebbe mai fermare. Rendiamo questa realtà.

Quindi qualcuno ti contatta su LinkedIn con un'opportunità di lavoro promettente. Sembra bello, vero? Sembrano legittimi (dopo averli controllati per 1 minuto) e dopo una breve conversazione ti inviano un repository GitHub con un semplice "compito di reclutamento" in Next.js. Lo cloni, lo esegui... e 10 minuti dopo, il tuo dispositivo è completamente compromesso quando scopri che i tuoi portafogli caldi sono stati svuotati. Ok, cosa è successo? Dato che noi (= SEAL 911) abbiamo visto questo attacco ripetersi più e più volte, lascia che ti sveli alcuni dei dettagli più importanti: - prima di tutto, la cosa più importante: NON eseguire codice casuale che ti ha inviato un tizio a caso. Onestamente, non farlo. - controlla sempre i file di configurazione _eseguibili_ dei repository con attenzione. In questo caso particolare, il file `next.config.js` aveva un grande padding che nascondeva il payload malevolo molto a destra. - scorri sempre orizzontalmente - solo perché non vedi nulla di malevolo quando guardi il contenuto non significa che sia pulito. Importante: il codice malevolo può essere nascosto all'interno di file di cui ti fidi, proprio non dove te lo aspetti. Spero davvero che questo tweet raggiunga abbastanza persone per prevenire almeno alcune future vittime da cadere in questo tipo di attacco.

Guarda, di solito sono un grande sostenitore di Proton. Ma in un mondo pieno di infostealer, non puoi dire alla gente di conservare le chiavi private del proprio wallet crypto in un gestore di password - anche se si tratta di Proton Pass! E chiariamo: non dovresti nemmeno conservare cose come passaporti, patenti, cartelle cliniche o numeri di previdenza sociale in un gestore di password. Se vieni compromesso, tutto ciò può essere usato per superare i controlli KYC e rubare la tua identità o i tuoi beni. Rispetto Proton, ma seriamente, fottiti. Non è così che si protegge i propri dati più critici.