Sommario
Un pacchetto apparentemente innocuo pubblicato su npm si è rivelato il vettore di una delle più complesse e raffinate campagne malevole mai osservate nella filiera del software open source. Il modulo, denominato os-info-checker-es6, sfrutta tecniche avanzate di steganografia basata su caratteri Unicode invisibili, l’uso di moduli compilati nativi per ogni piattaforma, e un meccanismo di comando e controllo (C2) che si appoggia a eventi pubblici su Google Calendar per eludere le misure di rilevamento convenzionali.
Il caso, portato alla luce dai ricercatori di Veracode, segna un punto di svolta nell’evoluzione degli attacchi alla supply chain del software, rendendo obsoleti molti dei controlli automatici implementati finora nei repository pubblici. L’impiego combinato di codice evasivo, esecuzione condizionata e infrastrutture fidate dimostra come gli attori malevoli stiano consolidando strategie sofisticate che sfruttano falle culturali e tecniche nella fiducia tra sviluppatori.
Il pacchetto npm camuffato da tool diagnostico per il sistema operativo
Il pacchetto os-info-checker-es6, apparso su npm per la prima volta il 19 marzo, si presentava come una semplice utility per raccogliere informazioni sul sistema operativo. Le prime cinque versioni pubblicate eseguivano solo funzioni basilari: rilevamento della piattaforma, rilascio del sistema, architettura e nome host. Nessun comportamento sospetto o tentativo di esfiltrazione dati veniva osservato.
Questa apparente innocuità si è rivelata funzionale a una strategia di lungo termine. Solo dopo alcuni giorni, gli sviluppatori del pacchetto hanno introdotto moduli compilati per macOS, Linux e Windows, associati a un file preinstall.js modificato che, pur mantenendo una struttura familiare, ha iniziato a includere codice offuscato tramite caratteri Unicode appartenenti al piano Supplementary Special Purpose di UTF-8.
Nel codice, un’istruzione apparentemente banale – un carattere pipe (|) – veniva seguito da una lunga sequenza di simboli non visibili, codificati come variation selectors. Questi caratteri, classificati come modificatori non visivi, sono stati utilizzati per trasportare dati nascosti nei byte bassi del codice Unicode, eseguendo una forma di steganografia testuale di altissimo livello.
Decodifica, esecuzione e evasione: la struttura multilivello del payload
Il meccanismo si fonda sull’esecuzione dinamica di una funzione decode, importata da uno dei moduli compilati in base al sistema operativo. Tale funzione interpreta la stringa invisibile, decodificandola in un payload base64. Questo viene quindi trasformato in stringa UTF-8, decodificato con atob() ed eseguito tramite eval(), una delle tecniche più temute nella sicurezza JavaScript.
In un primo stadio, il codice eseguito si limitava a un semplice console.log('Check');, probabilmente per testare la stabilità del canale. Ma nelle versioni successive, in particolare a partire dalla release 1.0.8, il payload è diventato estremamente più complesso e potenzialmente dannoso.
Decodificando il nuovo payload, i ricercatori hanno identificato una sequenza di operazioni che portano alla creazione di una connessione a una pagina di Google Calendar tramite short link (calendar.app.google). Da lì, il malware estrae l’attributo data-base-title, che contiene un ulteriore URL codificato in base64, indirizzante a un secondo livello di payload ospitato su un server esterno.
Google Calendar usato come dropper: infrastrutture fidate diventano vettori malevoli
Il ruolo di Google Calendar in questo attacco è cruciale. Invece di gestire il comando e controllo in modo diretto, il malware impiega eventi pubblici del calendario per mascherare i riferimenti a server esterni. La presenza del valore data-base-title nei metadati di un evento permette agli attaccanti di modificare dinamicamente il link verso il payload, senza dover aggiornare il codice del malware stesso.
Questa strategia complica enormemente la rilevazione: né l’URL iniziale (calendar.app.google) né il contenuto dell’evento violano, di per sé, policy di sicurezza o triggerano allarmi nei sistemi automatici. Il malware riesce quindi a nascondere i propri movimenti sfruttando la reputazione e la resilienza infrastrutturale di Google, esattamente come avviene nei casi di phishing che utilizzano Google Drive, Docs o Firebase.
La flessibilità del meccanismo consente di aggiornare il contenuto remoto in tempo reale, reindirizzando il flusso d’esecuzione in base a condizioni come sistema operativo, linguaggio di sistema, presenza di sandbox o analisi forense in corso.
Persistenza, anti-analisi e attivazione condizionata: il malware si adatta all’ambiente
Il malware include anche tecniche di persistenza basate su file lock nel file system temporaneo, impedendo l’esecuzione simultanea di più istanze e segnando i sistemi già infetti. Le routine di errore sono progettate per riattivarsi dopo crash o eccezioni, con un limite di tentativi prima della terminazione. Il codice intercetta uncaughtException, registra i log su disco e rilancia la routine principale dopo un timeout, massimizzando la resilienza operativa.
Inoltre, l’infrastruttura di comando e controllo sembra includere meccanismi di anti-emulazione e filtri per ambienti virtuali o sistemi di reverse engineering, portando a risposte innocue (come process.exit(0)) se il sistema target non supera determinati controlli.
Questi dettagli suggeriscono che il pacchetto sia parte di una campagna malevola ancora in corso, progettata per restare dormiente fino a condizioni specifiche, rendendone l’analisi complessa e il rilevamento affidabile estremamente difficile.
Distribuzione attraverso altri pacchetti: la catena si ramifica
La minaccia non si limita a un solo modulo. Il pacchetto os-info-checker-es6 è risultato dipendenza diretta di altri quattro pacchetti npm: skip-tot, vue-dev-serverr, vue-dummyy, e vue-bit. Tutti sono stati pubblicati da utenti apparentemente distinti, ma con nomi sovrapponibili ai pacchetti, tecnica nota per occultare ownership e autenticità.
Questi moduli, seppur privi inizialmente di codice malevolo, potrebbero fungere da vettori secondari o moduli di carico per componenti più complessi. Il fatto che siano stati pubblicati prima dell’introduzione del codice dannoso nel pacchetto principale suggerisce una pianificazione coordinata e premeditata, coerente con la strategia di infiltrazione silente nelle filiere di distribuzione del software.
Implicazioni per la sicurezza della supply chain: un nuovo modello di attacco prende forma
Questo attacco segna un passaggio decisivo verso una nuova generazione di minacce informatiche, in cui la complessità tecnica si sposa a una strategia psicologica fondata sulla fiducia che gli sviluppatori ripongono nei repository ufficiali. I controlli automatici di npm, basati su firma, frequenza di aggiornamento e contenuto testuale, non sono riusciti a rilevare comportamenti anomali fino alla fase finale.
La steganografia testuale con Unicode, l’uso di eventi su Google Calendar come vettore dinamico di secondo livello, e la compilazione di moduli nativi mirati a ogni sistema operativo dimostrano che gli autori del pacchetto possiedono competenze multidisciplinari, che spaziano dal reverse engineering al linguaggio macchina, fino alla manipolazione di API pubbliche.
Gli attori hanno evitato strumenti già noti come Google Calendar RAT (GCR), optando per una struttura originale e modulare, più difficile da rilevare attraverso firme preesistenti. Questo conferma la tendenza crescente a usare infrastrutture legittime per aggirare il tracciamento, rendendo gli attacchi non solo più insidiosi, ma anche più resilienti a blocchi e blacklisting tradizionali.
Verso una nuova cultura della sicurezza nel software open source
Il caso os-info-checker-es6 rappresenta una lezione cruciale per il mondo dello sviluppo moderno. L’affidabilità di una libreria non può essere valutata soltanto in base alla documentazione o alla data di pubblicazione. La presenza di script preinstall, moduli binari o comportamenti opachi deve diventare oggetto di indagine automatizzata e revisione umana approfondita, soprattutto quando si integrano dipendenze sconosciute nei propri progetti.
La sicurezza della supply chain open source non è più un problema teorico, ma una realtà che evolve più rapidamente degli standard di difesa. Le community, le piattaforme e le aziende devono collaborare per sviluppare strumenti intelligenti di audit e rilevamento, ma anche per diffondere una cultura della vigilanza attiva, capace di reagire prima che la minaccia raggiunga lo stadio operativo.
