Man mano che lo sviluppo del software avanza lungo il ciclo di vita della catena di fornitura del software, la fase del pacchetto emerge come un momento cruciale, convertendo il codice sorgente in artefatti eseguibili preparati per la distribuzione. Questa fase critica, tuttavia, non è immune alle vulnerabilità, il che la rende un obiettivo primario per gli autori malintenzionati che cercano di compromettere l’integrità e la sicurezza del software. Questo post del blog approfondisce le minacce prevalenti che possono sorgere durante questa fase e delinea strategie efficaci per mitigarle. Questo contenuto funge da continuazione della nostra serie di blog sull'esplorazione software supply chain security attraverso l' SDLC.
La fase del pacchetto nel ciclo di vita dello sviluppo del software
La fase del pacchetto del ciclo di vita della catena di fornitura del software comprende il processo di confezionamento e preparazione del software per la distribuzione agli utenti. Questa fase prevede la creazione di pacchetti di installazione, la gestione delle dipendenze e la generazione di metadati per il software.
Le minacce all'integrità della build sono vulnerabilità che potrebbero consentire agli aggressori di introdurre modifiche non autorizzate al software durante il processo di confezionamento. Queste minacce possono essere introdotte attraverso vari metodi, come la compromissione del registro dei pacchetti, lo sfruttamento delle vulnerabilità negli strumenti di confezionamento o la manipolazione delle dipendenze di terze parti.
La dipendenza totale dai componenti open source nei software moderni ha reso questa fase la più frequente SSCA target. L'introduzione di malware stealth in un componente open source popolare è un sogno per molti criminali informatici. Ecco perché più di Nel 245,000 sono stati rilevati 2023 pacchetti dannosi.
Esempi di Software Supply Chain Security Minacce nella fase del pacchetto
Utilizza il pacchetto compromesso
Si riferisce all'atto di distribuire o utilizzare un pacchetto software che è stato manomesso o modificato da un avversario.
Ciò può accadere dopo che il pacchetto ha lasciato il registro ufficiale dei pacchetti, tramite l'accesso diretto al sistema dell'utente o tramite tattiche di ingegneria sociale che inducono l'utente a scaricare o installare un pacchetto dannoso. Un esempio di questo vettore è stato il Sfogliare typosquatting Attacco.
Un utente malintenzionato, nel tentativo di compromettere i sistemi Linux e Mac, si è infiltrato nel processo di sviluppo di una popolare libreria Node.js chiamata Browserify. L'aggressore ha inserito codice dannoso nel codice sorgente del progetto, con l'intenzione di distribuirlo attraverso il registro dei pacchetti NPM. Una volta caricato il pacchetto Browserify contaminato su NPM, gli ignari sviluppatori lo scaricavano e lo installavano, credendo che fosse la versione legittima. Il codice dannoso, incorporato nel pacchetto, verrebbe eseguito silenziosamente, compromettendo l'integrità dei sistemi infettati. Ciò potrebbe portare al furto di dati, all’instabilità del sistema o persino all’accesso remoto da parte dell’aggressore.
Compromettere il registro dei pacchetti
Un registro dei pacchetti compromesso è un repository software in cui un avversario si è infiltrato e ha ottenuto l'accesso non autorizzato all'interfaccia amministrativa o all'infrastruttura del registro.
Ciò consente all'aggressore di modificare o sostituire pacchetti software legittimi con pacchetti software dannosi, che possono poi essere distribuiti a utenti ignari. Un esempio di questo tipo di minaccia è stato il Attacco ai mirror dei pacchetti: Un ricercatore, con l'intento di promuovere software open source, ha compromesso diversi registri di pacchetti popolari, tra cui Maven Central, NPM e RubyGems. Ottenendo l'accesso a questi registri, il ricercatore è stato in grado di creare mirror e repliche dei repository originali, che hanno fornito agli sviluppatori una comoda alternativa per scaricare i pacchetti.
Tuttavia, questi specchi nascondevano uno scopo sinistro. I mirror compromessi fungevano da canali attraverso i quali il ricercatore distribuiva pacchetti dannosi. Questi pacchetti hanno sostituito quelli legittimi, senza essere rilevati dai registri primari, e gli sviluppatori ignari li hanno scaricati e installati inconsapevolmente. Una volta installati, questi pacchetti dannosi liberavano il loro carico utile, eseguendo codice arbitrario, rubando dati sensibili o interrompendo le operazioni.
Carica pacchetto modificato
Un avversario carica un pacchetto modificato in un repository o in un canale di distribuzione che contiene codice o payload dannosi. Questo può essere fatto modificando il codice sorgente, il packaging o i metadati del pacchetto.
Una delle più note minacce di questo tipo è stata l' Attacco CodeCov nel 2021. Un aggressore che cerca di compromettere progetti software utilizzando CodeCov, un popolare strumento di integrazione continua e distribuzione continua (CI/CD), ha utilizzato credenziali trapelate per ottenere l'accesso non autorizzato al bucket Google Cloud Storage (GCS) di un progetto. Una volta ottenuto l'accesso al bucket GCS, l'aggressore ha caricato un artefatto dannoso, una versione modificata del pacchetto CodeCov, che è stato poi distribuito agli utenti tramite il servizio CodeCov. Gli sviluppatori ignari, affidandosi alla funzionalità di aggiornamenti automatici, scaricavano e installavano il pacchetto dannoso, credendo che fosse quello legittimo. Una volta installato, il codice dannoso veniva eseguito silenziosamente, compromettendo l'integrità dei sistemi infettati. Ciò poteva portare al furto di dati, all'instabilità del sistema o persino all'accesso remoto per l'aggressore.
Gli attacchi ai registri dei pacchetti sono così comuni che alcuni modelli di attacco hanno ricevuto un nome:
In Typosquatting, il malintenzionato carica nel registro più pacchetti dannosi con lievi errori di battitura o nomi simili a quelli legittimi e popolari, con la speranza che gli sviluppatori scrivano erroneamente il nome del pacchetto previsto con uno dannoso. Spesso il pacchetto dannoso si maschera da legittimo per passare inosservato, aumentando la probabilità di essere colpiti dall'osservazione delle stelle.
Confusione delle dipendenze sfrutta il modo in cui alcuni gestori di pacchetti risolvono i pacchetti richiesti da più registri. Quando un'organizzazione utilizza componenti interni pubblicati in un registro interno, un utente malintenzionato che è a conoscenza del fatto può pubblicare un componente dannoso con lo stesso nome in un registro pubblico. Se il nome utilizzato per il componente interno non ha un ambito, alcuni gestori di pacchetti recupereranno il componente dannoso anziché quello interno.
Con Pacchetti Trojan, il criminale informatico maschera il malware con codice utile e valido. Questo potrebbe essere utilizzato dal vero autore o da un contributore che si offre di mantenere il pacchetto. Questo è anche noto come Dirottamento dei pacchetti. Gli aggressori hanno utilizzato molte tecniche per dirottare un pacchetto esistente, come Acquisizione del dominio dove un dominio scaduto abbandonato è stato preso dall'aggressore che ha ricreato la vecchia email del manutentore ed ha eseguito il recupero della password per prendere il controllo dell'account del manutentore.
Osservazioni finali
Poiché le organizzazioni adottano sempre più metodologie di sviluppo software che danno priorità all'automazione e alla distribuzione continua, l'importanza di proteggere la fase del pacchetto software non è mai stata così importante. Implementando solide misure di sicurezza durante questa fase critica, le organizzazioni possono mitigare sostanzialmente il rischio di soccombere ad attacchi dannosi che possono compromettere l'integrità e la sicurezza del loro software.
Le strategie delineate in questo post del blog, insieme agli esempi forniti, servono a ricordare chiaramente che la fase del pacchetto rappresenta un punto vulnerabile all'interno della catena di fornitura del software. Le organizzazioni devono prestare attenzione a queste minacce e implementare le misure di sicurezza necessarie per salvaguardare il proprio software dagli attacchi. In questo modo, possono garantire l'integrità, la sicurezza e l'affidabilità del proprio software per i propri utenti e clienti.
Unisciti al nostro viaggio verso un ecosistema software sicuro
Non perdere l'occasione di rimanere un passo avanti nel regno di software supply chain security. Iscriviti oggi stesso al nostro blog e sarai tra i primi a ricevere i nostri ultimi approfondimenti, assicurando che la tua organizzazione rimanga resiliente e sicura nonostante le minacce in evoluzione. Insieme possiamo costruire un ecosistema software più solido e sicuro per tutti.
Ricordate, software supply chain security è un viaggio continuo, non una destinazione. Valutando e adattando continuamente le pratiche di sicurezza per affrontare le minacce emergenti, le organizzazioni possono salvaguardare la catena di fornitura del software e fornire software affidabile ai propri utenti.
Guarda la nostra demo video
