Cosa è successo durante l’exploit di NEAR Intents?
NEAR Intents ha perso circa 3,8 milioni di USDT su BNB Chain dopo che gli attaccanti hanno sfruttato una vulnerabilità nell’interazione tra l’infrastruttura Omni di deposito e prelievo e lo smart contract di NEAR Intents. Il prelievo era visibile prima della divulgazione pubblica, mentre NEAR Intents ha sospeso i servizi, ha sistemato il problema lato contratto e ha dichiarato che gli utenti coinvolti sarebbero stati completamente compensati.
L’attività sulla chain indica che piccoli trasferimenti di 10 USDT e 11 USDT hanno lasciato il contratto drenato durante il pomeriggio del 30 settembre, ora orientale degli Stati Uniti. Questi trasferimenti sono coerenti con una fase di convalida in cui un attaccante testa se una via di prelievo, contabilità o rilascio si comporta come previsto prima di tentare estrazioni di maggior entità.
Successivamente, cinque trasferimenti di dimensioni maggiori sono stati eseguiti tra le 23:54 UTC del 30 settembre e le 06:08 UTC dell‘1 ottobre. Questi trasferimenti variavano da circa $35.000 a $1,5 milioni ciascuno. L’analisi di sicurezza ha stimato la perdita a 3,865 milioni di dollari da un hot wallet di BNB Smart Chain, mentre un tracciamento on-chain separato ha individuato circa 3,87 milioni di USDT raccolti dal contratto drenato.
NEAR Intents ha divulgato pubblicamente l’exploit intorno alle 12:53 UTC dell’1 ottobre. Il protocollo ha affermato che i servizi si sono fermati dopo che SHIELD ha rilevato attività insolite, e che la correzione del contratto è stata implementata in circa un’ora. I depositi e i prelievi su 11 reti sarebbero rimasti non disponibili per circa altre 12 ore mentre l’infrastruttura veniva riparata.
| Fase dell’incidente | Data o ora | Evento concreto | Rilevanza per la sicurezza |
|---|---|---|---|
| Prime verifiche | 30 settembre, pomeriggio ora orientale US | 10 USDT e 11 USDT lasciarono il contratto BNB Chain drenato | Piccoli trasferimenti possono rivelare se una via di rilascio è sfruttabile |
| Inizio del drenaggio principale | 30 settembre, 23:54 UTC | Iniziato uno dei cinque trasferimenti più grandi | L’exploit è passato dalla fase di probing a quella di estrazione |
| Fine del drenaggio principale | 1 ottobre, 06:08 UTC | Completato il quinto trasferimento maggiore | Il periodo di estrazione visibile durò diverse ore |
| Divulgazione pubblica | 1 ottobre, circa 12:53 UTC | NEAR Intents ha informato di aver sospeso i servizi e di un bug nell’interazione tra infrastruttura e contratto | La comunicazione dell’incidente è seguita al drenaggio on-chain |
| Deadline di restituzione annunciata | 2 ottobre, 00:18 UTC | È stato dato un periodo di 48 ore per restituire i fondi | La scadenza indicata è circa il 4 ottobre, 00:18 UTC |
L’asset interessato pubblicamente segnalato era USDT su BNB Chain. Questo dettaglio è importante perché distingue un incidente applicativo e di infrastruttura bridge da un compromesso della rete principale NEAR o un fallimento generale di tutti gli asset di NEAR Intents.
NEAR Intents ha processato oltre 30 miliardi di dollari attraverso circa 35 blockchain, con un dashboard che mostrava 31,4 miliardi di all-time volume al 22 settembre. Sistemi di questa scala di routing non necessitano solo di smart contract sicuri, ma richiedono assunzioni coerenti sullo stato tra le chain, operatori di bridge, contratti di regolamento, sistemi di monitoraggio e procedure di pausa operativa.
Come muove normalmente gli asset NEAR Intents tra le chain?
NEAR Intents regola gli outcome cross-chain indirizzati dall’utente tramite il suo contratto Verifier intents.near, che mantiene un registro dei saldi di token depositati, aggiorna tali record quando avvengono swap e rilascia token solo tramite percorsi di prelievo e bridge. L’exploit riguardava il limite tra l’infrastruttura di deposito e prelievo e il livello di appoggio del sistema di regolamento.
Un utente di NEAR Intents firma un risultato previsto anziché specificare direttamente ogni passaggio esecutivo. Risolutori e market maker competono per soddisfare tale risultato, e il risultato selezionato si settle on-chain. Questo modello può migliorare l’esecuzione cross-chain, ma crea anche una superficie di fiducia e verifica ampia: il ledger di regolamento deve riconoscere correttamente cosa è stato depositato, cosa è stato scambiato e cosa può essere prelevato.
La documentazione di NEAR Intents identifica tre sistemi di bridge con diversi modelli di trust:
- Omni Bridge, gestito da Near One.
- POA Bridge.
- HOT Bridge.
Il design di HOT Bridge è particolarmente rilevante per l’analisi dell’incidente perché l’analisi pubblica ha identificato il contratto BNB Chain drenato come l’indirizzo di tesoreria HOT Bridge elencato nella documentazione di NEAR Intents, piuttosto che la vault principale di NEAR Intents. Questo collegamento è analisi piuttosto che una definitiva determinazione ufficiale della causa, e NEAR Intents non aveva ancora confermato quale componente fosse fallito al 2 ottobre.
In HOT Bridge, i contratti locker su ogni chain supportata detengono asset nativi. Un contratto su NEAR conia omni-token corrispondenti in rapporto uno-a-uno. Le firme MPC dei validator autorizzano depositi e prelievi, e il design prevede che ogni nonce sia monouso.
Questa architettura presenta diverse proprietà di sicurezza non negoziabili:
- Un rilascio su BNB Chain deve corrispondere a un vero lock, debit, o diritto settato.
- Un messaggio di deposito non deve poter essere riprodotto dopo l’esecuzione.
- L’approvazione del signer deve essere vincolata alla chain, asset, destinatario, importo e nonce specifici.
- Una richiesta di prelievo non deve essere accettata solo perché un componente esterno sostiene che sia valida.
- Il saldo della tesoreria deve essere riconciliato continuamente con il ledger e lo stato di bridge autorizzato.
Dalla nostra esperienza di audit di smart contract in Soken, i fallimenti di bridge più pericolosi avvengono ai confini di sistema. Un contratto può applicare correttamente le sue regole locali, pur rilasciando asset perché un messaggio upstream, un servizio off-chain o un’ipotesi di contabilità cross-chain sono stati accettati senza abbastanza verifica indipendente.
Le 11 reti in pausa corrispondevano alla lista di chain HOT Bridge in documentazione di NEAR Intents: BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll e Plasma. Ethereum, Base, Arbitrum, Solana e Bitcoin non erano in pausa. Le liste di chain corrispondenti supportano un’ipotesi focalizzata su HOT Bridge, ma non dimostrano quale componente fosse effettivamente vulnerabile.
Cosa si sa del bug e cosa rimane ignoto?
NEAR Intents ha confermato l’esistenza di un bug nell’interazione tra infrastruttura Omni di deposito e prelievo e lo smart contract di NEAR Intents, ma non ha ancora divulgato la componente precisa o la classe di vulnerabilità entro il 2 ottobre. Ogni affermazione che il problema fosse sicuramente un bypass di firma, una vulnerabilità di replay, un errore di contabilità o un compromesso dei validator sarebbe oltre le prove disponibili.
Il termine “interazione” è centrale. Suggerisce che la vulnerabilità non fosse necessariamente un difetto di codice isolato in una singola funzione. I sistemi cross-chain spesso falliscono quando due componenti ragionevoli singolarmente discordano sul significato, la finalità o l’unicità di una transizione di stato.
Ad esempio, un percorso di rilascio di un bridge può fallire se un componente off-chain produce un’approvazione per un evento che non è mai diventato finale, se un contratto accetta un messaggio di prelievo senza consumarlo definitivamente, o se il layer di contabilità accredita un saldo che il locker sottostante non ha realmente ricevuto. Sono meccanismi tecnici distinti, ma condividono lo stesso fallimento di sicurezza: gli asset vengono rilasciati senza un asset bloccato equivalente o un debito valido.
L’evento di NEAR Intents ricorda la forma generale di diversi grandi incidenti di bridge, pur rimanendo distinto nei dettagli confermati.
| Incidenti | Data | Perdita segnalata | Forma di fallimento confermata |
|---|---|---|---|
| Wormhole | Febbraio 2022 | Circa 325 milioni di dollari | Un bug di verifica firma ha permesso di falsificare l’approvazione del guardian e di mintare 120.000 wETH senza collateral |
| Nomad | Agosto 2022 | Circa 190 milioni di dollari | Un upgrade ha impostato la root di fiducia a zero, causando che ogni messaggio fosse considerato provato |
| Kelp DAO su LayerZero | Aprile 2026 | Circa 292-293 milioni di dollari | Una configurazione di verifier 1-su-1 ha permesso un burn fantasma per rilasciare fondi su Ethereum |
| Liquid Network | 6 settembre 2026 | Circa 320 milioni di dollari | Un bug nel cache di verifica del range-proof ha consentito di peggare L-BTC non garantiti a BTC reale |
| NEAR Intents | 1 ottobre 2026 | Circa 3,8 milioni di dollari | Un bug confermato nell’interazione tra infrastruttura Omni di deposito e prelievo e lo smart contract di NEAR Intents |
Wormhole, Nomad, Kelp DAO e Liquid Network condividono un pattern di fallimento del lato di rilascio: un bridge ha accettato un credito, una prova o un messaggio che non corrispondeva a un vero lock o debit. NEAR Intents non ha ancora confermato che l’exploit del 1 ottobre abbia seguito esattamente questo meccanismo, ma il contesto del suo bridge-tesoreria rende questa invariabile il primo punto che dovrebbe essere affrontato in un’analisi post-mortem.
Ronin Bridge si distingue come esempio utile. L’incidente di marzo 2022 coinvolse la compromissione di 5 delle 9 chiavi validator. Questo è principalmente un fallimento di gestione delle chiavi e di soglia di validator, piuttosto che un caso in cui un contratto riconosca erroneamente un credito non garantito come legittimo.
NEAR Intents si è impegnata ad aggiungere tecniche di verifica formale nel suo processo di rilascio. I metodi formali sono particolarmente utili quando vengono usati per codificare direttamente le invarianti di bridge: un prelievo valido non può superare il diritto settato, un messaggio di prelievo non può essere eseguito due volte, e i rilasci aggregati non possono superare la copertura verificata attraverso il sistema di bridge.
Per i protocolli che progettano infrastrutture simili, revisioni di sicurezza tecniche dovrebbero testare l’intero ciclo deposito-rilascio piuttosto che considerare singolarmente ciascun contratto, servizio o dominio del signer come un diverso confine di sicurezza.
Perché le decisioni di risposta e contenimento sono state importanti?
NEAR Intents ha contenuto l’incidente sospendendo i servizi dopo che SHIELD ha rilevato attività insolite, ha applicato una patch al vulnerabilità lato contratto in circa un’ora, e ha messo in pausa i depositi e i prelievi su 11 reti interessate. Un contenimento rapido limita ulteriori prelievi, ma il pieno recupero dipende dal tracciamento, dall’escalation legale e dalla dimostrazione che i flussi di bridge riavviati rispettano l’invariante di sicurezza corretto.
L’immediato stop dei servizi è stata una risposta adeguata all’incertezza. Quando un percorso di prelievo cross-chain potrebbe produrre rilasci non garantiti, continuare le operazioni normali può trasformare un exploit limitato in un’ampia perdita di tesoreria. Il compromesso è una perturbazione severa per gli utenti legittimi, motivo per cui i controlli di pausa dei bridge dovrebbero essere granulari, esercitati e osservabili.
NEAR Intents ha dichiarato di aver segnalato l’incidente alle forze dell’ordine e di lavorare con partner di sicurezza e analisi blockchain per tracciare i fondi e tentare il recupero. La comunicazione pubblica ha indicato che i fondi rubati sono stati inviati a KuCoin e bridgedati a Bitcoin. Un tracciamento separato ha individuato circa 1,5 milioni di USDT in movimento attraverso il contratto di regolamento CoW Protocol.
Un rappresentante di NEAR Intents ha concesso all’exploiters una finestra di 48 ore per restituire i fondi, ha pubblicato indirizzi di restituzione su Bitcoin, BNB Chain e Solana, e non ha annunciato alcun bounty. Al 2 ottobre, nessuna restituzione né piano di rimborso era stato ancora segnalato.
L’impegno di compensazione è anch’esso importante. Il co-fondatore di NEAR, Illia Polosukhin, ha affermato che tutti gli utenti coinvolti saranno completamente risarciti. Questo impegno affronta l’impatto sui clienti, ma non sostituisce l’obbligo tecnico di pubblicare un resoconto post-mortem e di remediation preciso prima di ripristinare le rotte interessate.
Un pacchetto post-incidente utile dovrebbe includere:
- La componente vulnerabile esatta e la classe di bug.
- Le modifiche a contratto e infrastruttura che eliminano la via di exploit.
- Se qualche invariante di messaggio, nonce, ledger, signer o riconciliazione è fallita.
- Risultati delle revisioni indipendenti sul ripristino.
- Un piano di ripristino per catena per BNB Chain, Polygon, TON, Optimism, Avalanche, Stellar, Monad, X Layer, ADI, Scroll e Plasma.
- Regole di monitoraggio per individuare prima il medesimo schema di prelievo anomalo.
L’incidente solleva anche domande di governance e operatività oltre il codice. La pubblicazione degli indirizzi di ritorno, il tracciamento dei fondi, il coordinamento con gli exchange, il risarcimento agli utenti e l’impegno con le forze dell’ordine coinvolgono decisioni legali e di divulgazione. I team che preparano procedure di recupero di bridge dovrebbero allineare i controlli tecnici con supporto legale e di conformità, soprattutto quando diventa rilevante la custodia, le richieste degli utenti, le sanzioni o il recupero trans-frontaliero.
Cosa dovrebbero cambiare i team cross-chain dopo l’incidente di NEAR Intents?
I team cross-chain dovrebbero trattare ogni prelievo di bridge come una verifica di conservazione del valore: il rilascio deve essere vincolato a un lock o debit verificato, a un messaggio unico, a una destinazione specifica e a un importo limitato. L’incidente di NEAR Intents dimostra che il monitoraggio e le emergenze sono fondamentali, ma la prevenzione dipende dal rendere impossibile autorizzare stati invalidi tra componenti cross.
Il primo compito ingegneristico è definire l’invariante centrale del bridge in termini aziendali e tecnici. Per un sistema di tipo HOT Bridge, l’invariante non è semplicemente “la firma MPC è valida.” È piuttosto: “questa esatta richiesta di prelievo è autorizzata una sola volta, per questo asset e destinatario, dopo un deposito finalizzato e non speso o un debit del ledger corrispondente.”
Questo invariante deve essere verificato attraverso diversi scenari di fallimento:
- messaggi duplicati e riutilizzo di nonce;
- identificatori di chain non corrispondenti;
- indirizzi token o conversioni decimali non allineate;
- approvazioni di signer obsolete;
- interruzioni parziali dell’infrastruttura;
- saldo del ledger e del locker incoerenti;
- transizioni di pausa di emergenza;
- tentativi di replay dopo aggiornamenti o migrazioni del contratto.
In secondo luogo, i protocolli devono separare il rilevamento dalla fiducia. SHIELD ha rilevato attività insolite durante l’evento NEAR Intents, contribuendo a innescare il contenimento. Tuttavia, il monitoraggio non dovrebbe essere l’unico baluardo tra errore contabile e perdita di tesoreria. Un sistema di monitoraggio dovrebbe identificare comportamenti sospetti una volta che sono iniziati. Regole di verifica di contratto e bridge dovrebbero respingere i movimenti di valore invalidi prima che l’operazione sia eseguibile.
In terzo luogo, i team dovrebbero costruire riconciliazioni che confrontano i lock della chain di origine, i crediti del ledger di regolamento, le releases della chain di destinazione e le autorizzazioni di prelievo pendenti. Una discrepanza dovrebbe automaticamente ridurre i limiti o interrompere la route interessata. Questo controllo è particolarmente importante per le route di hot-wallet e tesoreria, dove una transazione dall’aspetto legittimo potrebbe comunque spostare rapidamente asset liquidi.
Quarto, la verifica formale dovrebbe mirare a proprietà che contano per il modello di business del bridge, non solo alla sicurezza aritmetica. L’impegno di NEAR Intents di integrare la verifica formale ha un indirizzo corretto se copre le transizioni di stato tra deposito, settlement, creazione di messaggi di bridge e esecuzione di prelievi. Una prova formale di una funzione di contratto non è sufficiente se un componente infrastrutturale esterno può fornirle un presupposto errato ma accettato.
Il centro di ricerca di Soken analizza le modalità ricorrenti di fallimento di smart contract e di sicurezza di protocollo, incluse le differenze tra una verifica locale del contratto e una garanzia di sicurezza a livello di sistema. Per i team di bridge, la lezione pratica è chiara: il campo di audit deve comprendere contratti, formati di messaggi, policy di signer, controlli operativi, telemetria di monitoraggio e procedure di recovery.
NEAR Intents deve ora trasformare la promessa di post-mortem in un piano di ripristino verificabile: individuare l’interazione fallita, dimostrare perché il percorso fixato non può rilasciare USDT non garantiti, e testare indipendentemente ogni route di HOT Bridge riattivata. I team che gestiscono infrastrutture cross-chain simili dovrebbero partire mappando ogni autorizzazione di prelievo al suo lock o debit sottostante, e verificare se tale collegamento sopravvive a retry, ritardi, aggiornamenti e ordine dei messaggi adversariali.