A08:2021 – Software and Data Integrity Failures ⚓︎

Fattori⚓︎

CWEs corrispondenti	Tasso di incidenza Max	Tasso di incidenza Medio	Sfruttabilità pesata	Impatto Medio	Copertura Max	Copertura media	Occorrenze Totali	CVE Totali
10	16.67%	2.05%	6.94	7.94	75.04%	45.35%	47,972	1,152

Panoramica⚓︎

Una nuova categoria per il 2021 che è relativa alla verifica dell'integrità di aggiornamenti software, dati critici, e pipeline di CI/CD. Uno dei più alti impatti pesati dai dati di Common Vulnerability e Exposures/Common Vulnerability Scoring System (CVE/CVSS). Le Common Weakness Enumerations (CWEs) incluse sono CWE-829: Inclusion of Functionality from Untrusted Control Sphere, CWE-494: Download of Code Without Integrity Check, e CWE-502: Deserialization of Untrusted Data.

Descrizione⚓︎

Le problematiche dell'integrità del software e dei dati riguardano il codice e l'infrastruttura che non ne verificano adeguatamente l'integrità. Un esempio è quando un'applicazione si affida a plugin, librerie o moduli da fonti, repository e content delivery network (CDN) non attendibili. Una pipeline CI/CD insicura può aprire la porta ad accessi non autorizzati, codice dannoso o compromissione completa del sistema. Infine, molte applicazioni ora includono funzionalità di auto-aggiornamento, dove gli aggiornamenti vengono scaricati senza una sufficiente verifica dell'integrità e applicati all'applicazione. Gli attaccanti potrebbero potenzialmente caricare i propri aggiornamenti malevoli da distribuire e da eseguire su tutte le installazioni. Un altro esempio è la deserializzazione insicura, quando gli oggetti o i dati sono codificati o serializzati in una struttura che un attaccante può ispezionare e modificare liberamente.

Come prevenire⚓︎

Usare firme digitali o meccanismi equivalenti per verificare che il software o i dati provengano dalla fonte prevista e non siano stati alterati.
Assicurarsi che le librerie e le dipendenze, come npm o Maven, siano collegati a repository affidabili. Se avete un profilo di rischio più alto, considerate l'hosting di un repository interno ben conosciuto e controllato.
Assicuratevi che venga usato uno strumento di sicurezza della supply chain del software, come OWASP Dependency Check o OWASP CycloneDX, per verificare che i componenti non contengano vulnerabilità note
Assicurarsi che ci sia un processo di revisione per le modifiche al codice e alla configurazione per ridurre al minimo la possibilità che codice o configurazione dannosi vengano introdotti nella pipeline del software.
Assicurarsi che la pipeline CI/CD sia adeguatamente segregata, configurata adeguatamente e sia presente un meccanismo di controllo degli accessi per assicurare l'integrità del codice che passa attraverso i processi di compilazione e distribuzione.
Assicuratevi che i dati serializzati non firmati o non crittografati non vengano inviati a client non fidati senza qualche forma di controllo dell'integrità o firma digitale per rilevare la manomissione o il replay dei dati serializzati.

Esempi di scenari d'attacco⚓︎

Scenario #1 Aggiornamenti senza firma: Molti router domestici, set-top box, e altri dispositivi non verificano gli aggiornamenti attraverso una firma. Il firmware non firmato è sempre più spesso un obiettivo per gli attaccanti e questo è un trend che sembra non essere destinato a cessare. Questa è una problematica rilevante in quanto molte volte non è presente alcun meccanismo per rimediare se non quello di correggere in una versione futura e aspettare che le versioni precedenti invecchino.

Scenario #2 Aggiornamento malevolo di SolarWinds: Gli stati-nazione sono sempre stati noti per perpetrare attacchi verso i meccanismi di aggiornamento, con un recente e degno di nota attacco a SolarWinds Orion. L'azienda che sviluppa il software aveva processi per svolgere le build in modo sicuro e controlli sull'integrità degli aggiornamenti. Tuttavia, questi controlli sono violati e per parecchi mesi l'azienda distribuì un aggiornamento malevolo altamente mirato a più di 18,000 organizzazioni, delle quali, circa 100 sono state infettate. Questo è uno dei breach di questa natura di più ampia portata e più significativo nella storia.

Scenario #3 Deserializzazione insicura: Un'applicazione React chiama un insieme di microservizi Spring Boot. Essendo stata scritta nel paradigma funzionale, gli sviluppatori hanno cercato di garantire l'immutabilità del codice. La soluzione che hanno trovato è serializzare lo stato dell'utente e passarlo avanti e indietro ad ogni richiesta. Un attaccante nota la firma dell'oggetto Java "rO0" (in base64) e usa lo strumento Java Serial Killer per ottenere esecuzione di codice remoto sul server dell'applicazione.