Da 'Allarme Rosso' a 'Tempesta in un bicchier d'acqua': L'exploit NPM è stato esagerato?

Un ‘nulla di fatto’ con un campanello d’allarme

Le prime segnalazioni di un attacco su larga scala alla supply-chain di JavaScript Node Package Manager (NPM) hanno innescato un breve ma intenso periodo di panico all’interno della comunità cripto. Per alcune ore, i catastrofisti hanno colto l’avvertimento, speculando su un furto diffuso di fondi degli utenti. All’epoca, il CTO di Ledger, Charles Guillemet, consigliava agli utenti di portafogli software di cessare le transazioni on-chain e agli utenti di portafogli hardware di ricontrollare ogni transazione.

Tuttavia, con il passare delle ore, la portata dell’attacco è diventata più chiara. Si è rivelato che il codice malevolo era altamente mirato, e il numero di applicazioni colpite era limitato. Progetti prominenti come Uniswap, Metamask, OKX Wallet e Aave hanno tutti rilasciato comunicati confermando di non essere stati colpiti.

La mancanza di danni diffusi ha rapidamente trasformato il panico iniziale in un dibattito. Alcuni utenti cripto sollevati hanno iniziato a mettere in discussione la gravità dell’avvertimento originale, con alcuni che ora lo considerano allarmista e potenzialmente anche un attacco indiretto ai portafogli software. Questa prospettiva suggerisce che l’avvertimento, pur evidenziando una vulnerabilità reale, potrebbe essere stato esagerato per promuovere l’uso di portafogli hardware.

Sebbene i danni in termini di cripto rubati abbiano portato alcuni a definire l’exploit un “nulla di fatto,” alcuni esperti di sicurezza blockchain insistono sul fatto che l’incidente dovrebbe servire come un campanello d’allarme per tutti gli sviluppatori di software. Questi esperti concordano che l’incidente convalida il modello di sicurezza dei portafogli hardware, ma avvertono anche che gli utenti di tali portafogli potrebbero ancora perdere fondi in un attacco simile in determinate circostanze.

Augusto Teixeira, co-founder di Cartesi, ha illustrato questo punto, affermando: “Persino gli utenti di portafogli hardware potrebbero essere colpiti da tali attacchi. Ad esempio, diverse persone usano i loro portafogli hardware con l’aiuto di Metamask, senza verificare i dati sullo schermo del dispositivo. Questo sta diventando più comune, dato che le transazioni diventano più elaborate e le persone le firmano alla cieca. Verificare è difficile.”

Secondo Teixeira, i portafogli hardware mancano di funzionalità importanti come rubriche o integrazione con ABI JSON, che consentirebbero agli utenti di comprendere meglio ciò che stanno firmando dallo schermo del dispositivo.

Implicazioni a livello di settore e migliori pratiche

L’incidente di NPM ha messo in discussione le pratiche di sicurezza utilizzate da sviluppatori, gestori di pacchetti e organizzazioni. Alcuni nel settore cripto credono che seguire le migliori pratiche—come la revisione tra pari e non permettere agli sviluppatori di caricare codice in produzione senza approvazione—possa ridurre al minimo la probabilità di un tale attacco. Inoltre, sostengono che gli sviluppatori dovrebbero mantenere i sistemi aggiornati ed evitare di riutilizzare le password.

Shahaf Bar-Geffen, co-founder e CEO di COTI, ritiene che i gestori di pacchetti come NPM dovrebbero rendere più difficile il processo di accesso per un potenziale attaccante. Egli sostiene che un “Critical Package Security Framework,” potenzialmente supervisionato da enti come la OpenJS Foundation, “potrebbe richiedere l’autenticazione forte (2FA, token API limitati), build riproducibili e audit annuali di terzi per pacchetti che superano soglie elevate di download.” Bar-Geffen crede che questo modello di verifica a livelli aiuterebbe a incentivare le migliori pratiche proteggendo al contempo l’infrastruttura critica.

Per evitare di dover fare affidamento su una singola persona (che potrebbe avere interessi personali) per esporre attività malevole, Carlo Fragni, Solution Architect di Cartesi, incoraggia i progetti a seguire i canali utilizzati dai ricercatori. Egli promuove anche “l’uso di strumenti di analisi delle dipendenze e lo svolgimento di una due diligence su ogni dipendenza ogni volta che viene aggiornata a una nuova versione.”