Che cos'è una vulnerabilità zero-day?

Vulnerabilità, exploit e attacco zero-day

I tre termini vengono spesso usati come sinonimi, ma descrivono cose diverse:

• Vulnerabilità zero-day: il difetto stesso, sconosciuto al vendor o privo di correzione.
• Exploit zero-day: il codice o la tecnica che sfrutta il difetto.
• Attacco zero-day: l'exploit usato contro obiettivi reali.

Quando il vendor rilascia una correzione, il difetto smette di essere uno zero-day e diventa una vulnerabilità nota, spesso chiamata n-day. Inizia così una seconda corsa: gli attaccanti studiano la patch e cercano i sistemi che non l'hanno applicata, quindi una vulnerabilità nota lasciata senza patch può fare tanti danni quanti lo zero-day originale.

Gli zero-day nelle Sue dipendenze

La maggior parte del codice di un'applicazione moderna proviene da pacchetti open source, e la maggior parte di questi sono dipendenze transitive: introdotte da altri pacchetti anziché scelte dal Suo team. Uno zero-day in una qualsiasi di esse è uno zero-day nel Suo prodotto.

Log4Shell (CVE-2021-44228) è l'esempio più noto. Divulgata a dicembre 2021, permetteva a un attaccante che controllava un messaggio registrato nei log di eseguire codice arbitrario tramite Apache Log4j 2, e ha ottenuto il punteggio massimo CVSS 10.0. Per la maggior parte dei team la parte difficile non era la correzione, ma la domanda che la precede: quali delle nostre applicazioni contengono log4j-core, e in quali versioni? Log4j era di solito una dipendenza di una dipendenza, e molti team hanno impiegato giorni per scoprirlo.

Gli zero-day nella supply chain non sono sempre bug. A marzo 2024 Andres Freund ha trovato una backdoor nelle versioni 5.6.0 e 5.6.1 di xz (CVE-2024-3094) dopo aver notato che gli accessi SSH usavano troppa CPU. Le release di pacchetti malevoli, un tipo comune di attacco alla supply chain, funzionano allo stesso modo: i primi team che installano una versione infetta, come quelli colpiti dal worm npm Shai-Hulud, affrontano un attacco che nessun advisory o scanner conosce ancora.

Come rispondere quando uno zero-day colpisce una dipendenza

1. Trovi dov'è. Elenchi ogni applicazione, immagine e release che contiene il componente interessato, anche come dipendenza transitiva. Serve una SBOM accurata per ogni build. Un lockfile non vede le dipendenze scaricate al di fuori del package manager, come il codice scaricato dagli script di installazione o i layer del sistema operativo di un'immagine container.
2. Determini il periodo di esposizione. Quali build hanno distribuito la versione vulnerabile, e da quando? Questo Le dice che cosa indagare e che cosa segnalare.
3. Contenga il problema. Applichi la correzione o un workaround quando ne esiste uno e impedisca alle nuove build di distribuire la versione vulnerabile una volta che ha una CVE. Veda la remediation delle CVE.
4. Cerchi segni di sfruttamento. Verifichi se il difetto è stato usato contro di Lei durante il periodo di esposizione e ruoti tutti i secret che potrebbe aver raggiunto.

Siamo interessati? illustra in dettaglio i primi due passaggi.

Ci si può difendere da uno zero-day che nessuno conosce?

Non con le patch né con gli scanner, perché entrambi dipendono dal fatto che il difetto sia noto. Ciò che funziona prima della divulgazione è limitare ciò che un attaccante può fare con un difetto che trova:

• Privilegio minimo. Dia a ogni sistema e a ogni job CI solo gli accessi e i secret di cui ha bisogno.
• Controllo dell'egress. Blocchi le connessioni in uscita verso host di cui un sistema non ha bisogno, così un exploit in esecuzione non può inviare dati all'attaccante. In una build CI è uno dei pochi controlli che funzionano anche se Lei è la prima vittima di un nuovo pacchetto malevolo. Veda le policy di egress per GitHub Actions.
• Difesa in profondità. Stratifichi i controlli, così un singolo difetto non apre tutto.
• Registri consultabili in seguito. Quando lo zero-day viene divulgato, la velocità della Sua risposta dipende dal sapere che cosa ha compilato e distribuito.

Come aiuta CRACI

CRACI esegue i Suoi job GitHub Actions sui propri runner e registra ogni build mentre avviene:

• Le SBOM in fase di build elencano i pacchetti che ogni job ha effettivamente scaricato, comprese le dipendenze nascoste che gli strumenti basati sui lockfile non vedono, così può rispondere a "dov'è?" partendo da ciò che è stato davvero compilato. Veda le SBOM in fase di build.
• La cronologia delle build mostra ogni build passata con la sua SBOM e quali build contenevano una dipendenza vulnerabile, diretta o transitiva, così Lei conosce il periodo in cui è stato colpito.
• I policy gate possono bloccare una build che contiene una CVE specifica, così una nuova build non distribuisce di nuovo la versione vulnerabile.
• Una policy di egress default-deny blocca le connessioni verso host di cui la build non ha bisogno, anche durante un attacco che nessuno ha mai visto.

Vulnerabilità zero-day: domande frequenti

Che cos'è una vulnerabilità zero-day?

Un difetto di sicurezza che gli attaccanti conoscono, o stanno già sfruttando, prima che il vendor o il maintainer abbia rilasciato una correzione. Il nome conta i giorni che i difensori hanno avuto per applicare la patch: zero.

Qual è la differenza tra vulnerabilità, exploit e attacco zero-day?

La vulnerabilità è il difetto. L'exploit è il codice o la tecnica che lo sfrutta. L'attacco è l'exploit usato contro obiettivi reali.

Quando uno zero-day smette di essere uno zero-day?

Quando è disponibile una correzione. Da quel momento è una vulnerabilità nota, talvolta chiamata n-day, e il rischio si sposta sui sistemi che non hanno ancora applicato la correzione.

Uno scanner può rilevare uno zero-day?

Non con una semplice ricerca. Gli scanner di vulnerabilità confrontano i componenti con gli advisory pubblicati, e uno zero-day non ne ha ancora. Ciò che uno scanner o una SBOM Le offre è l'inventario in cui cercare nel momento in cui compare l'advisory.

Come scopro se uno zero-day interessa il mio software?

Cerchi il componente e le versioni interessate in un inventario accurato di ciò che ogni build e release contiene, comprese le dipendenze transitive. Poi determini quali release lo hanno distribuito e da quando, così conosce il periodo di esposizione.