Una recente campagna di malware su npm ha mostrato come un registro di pacchetti possa essere usato come hosting gratuito per distribuire un sito web dannoso. Sono stati individuati 148 pacchetti npm mascherati da proxy web per studenti, creati per aggirare i filtri scolastici e accedere a giochi o siti bloccati.
In apparenza il proxy funzionava davvero, ma in realtà trasformava i browser dei visitatori in nodi di una botnet DDoS, sfruttando il traffico degli utenti ignari invece di colpire direttamente gli sviluppatori che installano dipendenze.
I pacchetti includevano una web app di proxy denominata Lucide e pagine camuffate da servizi di tutoraggio. Il punto chiave è che il codice malevolo non si attivava durante l’installazione del pacchetto: non c’erano hook del ciclo di vita npm né script nativi pensati per essere eseguiti in build. Il payload si attivava solo quando qualcuno apriva la pagina web ospitata tramite quei pacchetti, rendendo il vettore di attacco più simile al malvertising e agli abusi lato browser.
Moduli principali nell’app
All’interno dell’app erano presenti due moduli principali.
1) Loader remoto
Il primo era un loader remoto che scaricava JavaScript da una repository tramite CDN, senza bloccare la versione su un commit specifico e senza controlli di integrità. Questo consentiva agli operatori di cambiare il codice eseguito nei browser in qualsiasi momento, con accesso a cookie, local storage e risorse same origin. In un caso documentato, il loader distribuiva un flood HTTP che inviava richieste POST no-cors a intervalli rapidissimi, generando un consumo di banda in upload significativo per ogni tab aperta.
2) WebSocket e protocollo Wisp
Il secondo modulo sfruttava WebSocket e il protocollo Wisp, comune nell’ecosistema dei proxy browser. Scaricava una configurazione testuale e apriva molte connessioni WebSocket in parallelo, inviando frame CONNECT e CLOSE ad alta frequenza per stressare il server Wisp remoto. Questo tipo di attacco punta al piano di controllo e alle risorse del server, causando esaurimento di file descriptor e crescita dei log, con conseguente interruzione del servizio.
Durata della campagna e mitigazione
La campagna è durata circa due settimane a maggio, poi i componenti DDoS sono stati rimossi dal build pubblico, ma la presenza del loader mutabile mantiene la possibilità di riattivare rapidamente le funzionalità malevole senza aggiornare i pacchetti. Per la mitigazione sono consigliati blocchi DNS dei domini coinvolti, pulizia di cache e storage del browser e rimozione di eventuali service worker registrati, oltre a bonifica di manifest e lockfile negli ambienti di sviluppo.