Se avete mai vissuto nel timore di essere hackerati e di veder sottratti i vostri fondi da un malintenzionato, giovedì 12 febbraio l'azienda leader nella sicurezza della blockchain Certora ha cercato di alleviare queste paure con un livestream intitolato "How DeFi Hacks Have Changed in the Last 5 Years and What This Means for Protocols".
Seth Hallem, CEO di Certora, si è unito a Ofek Ray Orlev, ricercatore senior di sicurezza e team lead dell'azienda, per analizzare le differenze tra gli attacchi moderni e i precedenti exploit DeFi e le azioni che i team di protocollo dovrebbero intraprendere in risposta.
Seth è entrato in Certora otto mesi fa dopo aver costruito una carriera nell'analisi statica, nella qualità del software e nella sicurezza informatica. Ora applica questa esperienza a Web3 e DeFi. Ofek vanta dodici anni di esperienza nella ricerca di vulnerabilità in ambiti offensivi e difensivi. Prima di entrare nello spazio DeFi due anni fa, ha guidato le attività di red teaming e penetration testing presso Intel, dove ha sviluppato strumenti offensivi e difensivi per i sistemi embedded.
Piuttosto che rivisitare hack ben noti, la discussione si è concentrata su due attacchi recenti e sofisticati. Il primo, CPIMP, sta per Clandestine Proxy In The Middle of Proxy. Il secondo, GlassWorm, rappresenta il primo worm crittografico mirato e autopropagante ad attaccare la catena di fornitura NPM e OpenVSX. Insieme, questi attacchi illustrano come la sicurezza DeFi sia passata da bug evidenti a campagne sistemiche, pazienti e a più livelli.
Attacco Clandestino Proxy In The Middle of Proxy (CPIMP)
L'attacco CPIMP sfrutta gli schemi di inizializzazione dei proxy negli smart contract. Nel suo nucleo, l'attacco dirotta la fase di inizializzazione di un contratto proxy. Se un attaccante esegue in anticipo la prima chiamata di inizializzazione, può inizializzare il proxy con un'implementazione dannosa.
Ciò che rende CPIMP particolarmente notevole non è solo la sua posizione iniziale, ma anche la persistenza e la furtività che ne conseguono. Il proxy dannoso imita l'implementazione prevista, quindi tutti i test e le normali interazioni continuano a passare. Sviluppatori e utenti non notano alcun malfunzionamento evidente. L'aggressore inserisce un proxy clandestino tra il proxy legittimo e la logica prevista, consentendo all'aggressore di intercettare e manipolare le chiamate senza essere immediatamente individuato.
Gli attori maligni hanno anche progettato la persistenza attraverso gli aggiornamenti. Quando gli sviluppatori aggiornano il proxy per aggiungere funzionalità, il livello maligno reinietta il suo codice nella nuova implementazione. Una volta infettato, ogni aggiornamento successivo passa attraverso la pipeline dell'attaccante. Questo design consente un controllo a lungo termine piuttosto che un rapido exploit "smash-and-grab".
Gli aggressori hanno persino sfruttato una vulnerabilità in Etherscan che ha permesso loro di falsificare l'indirizzo dell'implementazione visualizzata popolando uno slot di memoria obsoleto. Gli osservatori esterni che si affidavano agli esploratori di blocchi avrebbero visto l'implementazione sbagliata, oscurando ulteriormente il rilevamento.
Seth e Ofek hanno paragonato questo approccio a un "rug pull", ma hanno sottolineato un diverso orizzonte temporale. Un'estrazione tradizionale spesso prosciuga rapidamente i fondi. CPIMP sembra progettato per aspettare che un protocollo cresca abbastanza da giustificare l'attivazione. L'attaccante può trattare il sistema compromesso come una risorsa dormiente che matura nel tempo. Questa pazienza suggerisce una mentalità da campagna piuttosto che da sfruttamento opportunistico.
Attacco GlassWorm: Estrazione di chiavi private da 50 estensioni di portafogli
GlassWorm sposta il campo di battaglia dalla logica onchain alla catena di sviluppo. Gli aggressori hanno introdotto un'estensione VS Code dannosa che ha infettato le macchine degli sviluppatori. Una volta installata, l'estensione ha estratto le chiavi private da circa cinquanta estensioni di portafogli. Inoltre, ha cercato le credenziali di GitHub e ha determinato se lo sviluppatore infetto avesse altre estensioni di VS Code.
Se lo sviluppatore pubblicava un'estensione, il worm iniettava codice dannoso in tale estensione prima della distribuzione. Questo meccanismo di propagazione ha trasformato il malware in un vero e proprio worm. Ogni nuova estensione infettata diffonde ulteriormente il payload, amplificando la sua portata nell'ecosistema.
Prendetevi un secondo per capire queste informazioni. Siete uno sviluppatore. La vostra macchina viene infettata. Probabilmente ti vengono prosciugati i fondi. Le estensioni che sviluppate vengono infettate e chiunque le scarichi viene infettato anche lui, e così via.
L'etichetta "glass" si riferisce all'uso di caratteri non stampabili per nascondere il codice dannoso. Il payload appare come righe vuote o spazi bianchi negli editor. I tradizionali strumenti di analisi statica non sono riusciti a segnalare il codice prima che i ricercatori identificassero l'attacco.
GlassWorm ha combinato tecniche note con nuove innovazioni. Ha riutilizzato strategie consolidate di compromissione della catena di fornitura e metodi di estrazione di chiavi private. Tuttavia, ha introdotto un nuovo meccanismo di comando e controllo sfruttando la blockchain Solana. Il worm leggeva le istruzioni crittografate incorporate nei campi memo delle transazioni. Poiché gli aggressori firmavano le transazioni con il proprio portafoglio, le macchine infette potevano verificare ed eseguire nuove istruzioni senza affidarsi a un server tradizionale.
Questa struttura di comando e controllo onchain ha reso molto più difficili le operazioni di takedown. Le forze dell'ordine o le squadre di sicurezza non potevano semplicemente sequestrare un server centralizzato. Gli aggressori hanno anche utilizzato i soggetti degli eventi di Google Calendar come canale di comunicazione di riserva. Questi livelli hanno creato una resilienza e una flessibilità che i ricercatori di sicurezza hanno raramente osservato nei precedenti worm Web2.
Il worm ha anche installato un client VNC nascosto e configurato un proxy SOCKS sulle macchine infette. Queste capacità indicano che gli aggressori non volevano solo prosciugare i portafogli. Il loro obiettivo era ottenere un ampio accesso ai sistemi delle vittime. L'attacco ha offuscato il confine tra Web2 e Web3 e ha dimostrato che la sicurezza della DeFi non si ferma più ai contratti intelligenti.
Cosa si può fare per proteggersi?
Entrambi i relatori hanno sottolineato che gli sviluppatori non dovrebbero adottare una mentalità nichilista. La sicurezza perfetta non esiste, ma i miglioramenti pratici riducono significativamente il rischio.
Ofek ha consigliato ai team di esaminare le loro toolchain, limitare le estensioni non necessarie e mantenere aggiornate le dipendenze. Ha esortato gli sviluppatori a comprendere realmente come vengono eseguiti i processi di distribuzione.
Ha anche raccomandato la verifica post-deployment. I team dovrebbero ispezionare direttamente gli slot di archiviazione onchain, anziché affidarsi esclusivamente agli esploratori di blocchi. Dovrebbero confermare che non si sono verificate chiamate di delegati o fasi di inizializzazione inaspettate.
Seth ha posto l'accento sul pensiero architettonico. Ha affermato che "l'idea che un'estensione del browser sia un luogo sicuro per decriptare una chiave privata e firmare transazioni che spostano denaro è un concetto errato costruito a partire dal modello di minaccia sbagliato", sostenendo che le estensioni del browser vengono eseguite in ambienti altamente dinamici e non dovrebbero gestire operazioni crittografiche di alto valore. I moduli di sicurezza hardware e gli ambienti di firma isolati offrono maggiori garanzie.
Mert Mumtaz, CEO di Helius Labs, ha fatto eco a questo sentimento in un post pubblico, scrivendo che l'idea che i portafogli siano estensioni di Chrome rappresenta una delle decisioni UX più discutibili del settore.
Entrambe le prospettive evidenziano la necessità di ripensare le ipotesi di sicurezza dei portafogli con l'aumento dell'afflusso di capitali.
A cosa bisogna prestare attenzione nel 2026?
Guardando al 2026, entrambi i relatori prevedono un aumento della partecipazione istituzionale al Web3. Man mano che i governi e le grandi istituzioni finanziarie valuteranno un maggiore coinvolgimento, i protocolli dovranno affrontare requisiti di due diligence e di conformità più severi. La documentazione, la verifica formale, le procedure standardizzate e le partnership di sicurezza continue diventeranno probabilmente le aspettative di base.
Sul fronte offensivo, gli aggressori continueranno a mescolare tecniche Web2 e Web3. Man mano che la qualità degli smart contract migliora e le verifiche diventano più comuni, gli aggressori prenderanno di mira l'ingegneria sociale, l'esfiltrazione di chiavi private, i frontend, i processi di governance e le catene di approvvigionamento. Seth ha paragonato questo cambiamento all'aumento del ransomware nel Web2, dopo che le organizzazioni hanno indurito i servizi esposti.
I protocolli devono aspettarsi che gli aggressori si comportino come le aziende. Alcune campagne perseguiranno vantaggi transazionali, come il phishing e il prosciugamento dei portafogli. Altre perseguiranno opportunità strategiche che mirano a debolezze sistemiche in infrastrutture da mille miliardi di dollari.
Riflessioni finali
Il livestream ha evidenziato un chiaro cambiamento nella sicurezza della DeFi. I primi exploit si basavano spesso su evidenti errori di codifica. Gli attacchi moderni operano con pazienza, persistenza e sofisticazione cross-domain. CPIMP ha dimostrato come gli aggressori possano nascondersi all'interno di architetture proxy e attendere che il valore si accumuli. GlassWorm ha mostrato come la compromissione della catena di approvvigionamento e il comando e controllo onchain possano estendersi oltre i contratti intelligenti negli ambienti degli sviluppatori.
I protocolli non possono prevedere ogni tecnica futura. Tuttavia, possono aumentare il costo degli attacchi attraverso un'architettura disciplinata, un'attenta distribuzione, superfici di minaccia ridotte al minimo e una verifica continua. Con l'aumento del capitale e del controllo normativo, la sicurezza passerà da una verifica puntuale a un requisito operativo continuo.
Per saperne di più su SolanaFloor
Gli sviluppatori su Solana aumentano di quasi 10 volte dal 2020 e la rete accoglie un record di 3830 nuovi sviluppatori nel 2025
La scena dei criminali di Solana è ancora una volta snobbata mentre il terminale troiano si integra altrove
I Treasury degli asset digitali possono sopravvivere al crollo?
