Negli ultimi tempi la sicurezza della supply chain del software è diventata una delle principali preoccupazioni per aziende e sviluppatori. Recenti scoperte hanno evidenziato come pacchetti malevoli pubblicati sui repository PyPI e npm, fondamentali per lo sviluppo software in Python e JavaScript, siano sfruttati per compromettere sistemi attraverso dipendenze manipolate.
Un esempio significativo: il caso termncolor su PyPI
Un esempio significativo riguarda il pacchetto termncolor su PyPI, che sfrutta una dipendenza chiamata colorinal per attivare una catena di infezione multi-stadio. Termncolor è stato scaricato 355 volte, mentre colorinal ha raggiunto 529 download, prima di essere rimossi dal repository. Il meccanismo dell’attacco prevede l’utilizzo del caricamento laterale di DLL per decifrare ed eseguire payload dannosi, stabilire la persistenza nel sistema e instaurare una comunicazione command-and-control (C2).
Il malware, una volta installato, importa colorinal che a sua volta carica una DLL malevola. Questa DLL è in grado di raccogliere informazioni sul sistema e comunicare con un server C2 tramite Zulip, una popolare chat open-source, rendendo difficile rilevare l’attività sospetta. La persistenza viene ottenuta creando una chiave di registro nel Run di Windows, così che il malware venga eseguito automaticamente ad ogni avvio del sistema. La minaccia non riguarda solo Windows: anche sistemi Linux risultano vulnerabili, grazie all’uso di file shared object come terminate.so.
Minacce anche su npm
Non si tratta di casi isolati. Anche su npm sono stati individuati pacchetti, come redux-ace e rtk-logger, progettati per scaricare ed eseguire script Python, rubare credenziali, monitorare clipboard e registrare screenshot. Questi pacchetti vengono spesso distribuiti spacciandoli per proof-of-concept di vulnerabilità o come patch di ottimizzazione, inducendo soprattutto sviluppatori e ricercatori di sicurezza a installarli.
L’automatismo degli aggiornamenti e i rischi connessi
Il rischio viene amplificato dall’uso di strumenti di aggiornamento automatico delle dipendenze, come Dependabot, che potrebbero aggiornare progetti con versioni compromesse senza il controllo umano, specie se una dipendenza viene erroneamente impostata come principale e non come devDependency, come emerso nel recente caso di eslint-config-prettier.
La lezione principale è che, in un contesto di software open source, è fondamentale monitorare costantemente la provenienza e la sicurezza delle dipendenze, adottando pratiche di verifica e limitando l’automatismo degli aggiornamenti, al fine di ridurre il rischio di attacchi supply chain sempre più sofisticati e mirati.