OpenSSL è una libreria software open source ampiamente utilizzata per implementare comunicazioni sicure su reti di computer. Quanto ampiamente utilizzato? Bene, è probabile che se hai mai avuto accesso a una pagina web HTTPS lo hai fatto tramite una crittografia OpenSSL. La libreria fornisce funzioni e protocolli crittografici per la crittografia, la decrittografia, l'autenticazione e la verifica della firma digitale dei dati. OpenSSL può essere trovato quasi ovunque sia necessario proteggere server Web, server di posta elettronica, reti private virtuali (VPN) e altri tipi di comunicazione di rete.
Osservando il paragrafo precedente dovrebbe essere chiaro quanto sia importante OpenSSL per il corretto funzionamento di Internet. È un componente critico dell'infrastruttura di sicurezza per molti sistemi e applicazioni informatici. Aiuta a proteggere i dati sensibili da accessi non autorizzati e aiuta a garantire l'integrità e l'autenticità delle comunicazioni di rete. Ecco perché i manutentori della libreria prendono molto sul serio le vulnerabilità e tentano di risolverle il prima possibile. Immaginare che gli aggressori possano accedere alle linee di comunicazione sicure dell’infrastruttura World Wide Web è quasi impensabile.
In questo articolo esamineremo le vulnerabilità che hanno portato alla patch 3.0.7 di OpenSSL nell'ottobre 2022 e vedremo cosa possiamo imparare dal modo in cui i manutentori di OpenSSL hanno affrontato il problema.
Le vulnerabilità
Il 25 ottobre 2022, il progetto OpenSSL ha pubblicato un consultivo avvertendo che presto arriverà una nuova patch per risolverne alcuni critico vulnerabilità. Il tag "critico" implica che è probabile che le vulnerabilità siano sfruttabili e che è probabile il furto di chiavi private e/o RCE sui server interessati.
Una settimana dopo, il 1° novembre 2022, il progetto OpenSSL ha rilasciato sia la nuova patch, 3.0.7, sia la vulnerabilità specifiche miravano a risolvere. Nel frattempo la valutazione delle vulnerabilità è stata abbassata da critica a “elevata gravità”.
Quindi, quali sono queste vulnerabilità?
CVE-2022-3602 – Overflow del buffer di 509 byte dell'indirizzo e-mail X.4 – Nella verifica del certificato X.509, in particolare nel controllo dei vincoli del nome, può verificarsi un sovraccarico del buffer di quattro byte. Quattro byte nello stack controllati dall'aggressore possono essere traboccati da un utente malintenzionato che utilizza un indirizzo e-mail dannoso. Questo overflow del buffer potrebbe causare un arresto anomalo del sistema (con conseguente negazione del servizio) o un'esecuzione potenzialmente remota di codice. Inizialmente era stato classificato come critico, ma ulteriori test hanno dimostrato che numerose piattaforme utilizzano misure di protezione dallo stack overflow per ridurre il rischio di esecuzione di codice in modalità remota.
CVE-2022-3786 – Overflow del buffer a lunghezza variabile dell'indirizzo e-mail X.509 – Nella verifica del certificato X.509, in particolare nel controllo dei vincoli del nome, può verificarsi un sovraccarico del buffer. Un utente malintenzionato può creare un indirizzo e-mail dannoso in un certificato per riempire lo stack con un numero qualsiasi di byte che contengono il carattere ".", che è il numero decimale 46. Potrebbe verificarsi un arresto anomalo del sistema come risultato di questo overflow del buffer (causando un negazione del servizio).
Giusto per ribadire quanto siano gravi queste vulnerabilitàies sono, CISA, l'agenzia statunitense per la sicurezza informatica e la sicurezza delle infrastrutture, ha rilasciato un consultivo lo stesso giorno di OpenSSL, incoraggiamentoinvitare gli utenti e gli amministratori a rivedere il Documentazione OpenSSL e aggiornamento, ove applicabile, alla nuova patch 3.0.7.
Come discusso in precedenza, l'RCE (esecuzione di codice remoto) sui sistemi operativi o sui server di posta che eseguono OpenSSL sarebbe molto dannoso, quindi ha senso rivelare solo il vulnerabilità una volta trovata e offerta la patch adeguata.
Che cosa succede dopo
Non appena è stato pubblicato l’avviso iniziale, le persone hanno iniziato ad agitarsi. "Niente panico" era una frase comune al tempo dimostrando quanto seriamente le persone abbiano preso la notizia che OpenSSL ha un carattere critico vulnerabilità.
Non appena l'avviso è stato pubblicato, tutte le parti interessate si sono affrettate a capire quale versione di OpenSSL fosse utilizzata nel proprio server, sistema operativo, applicazione, pacchetto, ecc. Oltre al semplice utilizzo interno di OpenSSL, le persone avevano anche bisogno di capire se qualcuno dei loro terzi i fornitori di terze parti o i fornitori di servizi utilizzavano una versione OpenSSL vulnerabile. All'epoca, se non eri sicuro di quale versione stavi utilizzando o di quale versione stessero utilizzando i tuoi fornitori e fornitori di servizi, era ritenuto più sicuro portare un'applicazione offline piuttosto che rischiare un potenziale RCE.
Dal momento che l'avviso ha fornito in anticipo la tempistica per la patch, ciò ha dato alle persone il tempo di capire la propria infrastruttura e quella dei propri fornitori e fornitori di servizi. L'idea era quella di pianificare tutto il necessario in termini di infrastruttura coinvolta in modo che non appena fosse stata rilasciata la patch, l'aggiornamento, se necessario, potesse avvenire.
Come lo gestiresti?
Ora supponiamo che tu sia un ingegnere di un'azienda che, per quanto ne sai, utilizza OpenSSL nei suoi server. Non appena viene rilasciato l'avviso, è necessario capire quale versione della libreria è in uso e dove (incluso qualsiasi codice legacy se è ancora in esecuzione) e quindi calcolare la stessa cosa per uno qualsiasi dei propri fornitori o fornitori di servizi.
Qui è dove un file SBO potrebbe davvero tornare utile. Una SBOM sta per distinta base del software ed è un elenco di tutti i componenti e le dipendenze software che compongono un particolare prodotto software. Una SBOM include in genere informazioni come i nomi e le versioni di tutti i componenti software (vedi dove andrò con questo), le loro fonti e licenze ed eventuali vulnerabilità note o problemi di sicurezza associati a ciascun componente.
Se tu, come ingegnere responsabile quale sei, ti assicurassi di avere una SBOM aggiornata per ciascuno dei tuoi prodotti, allora scoprire dove stavi utilizzando OpenSSL e quale versione era in uso sarebbe stato semplice eseguire una ricerca sul file SBOM . Se ti fossi anche assicurato di chiedere SBOM aggiornati a qualsiasi fornitore o fornitore di servizi con cui la tua azienda stava lavorando, avresti potuto fare la stessa ricerca anche lì.
Dato che ti è stato detto che le vulnerabilità interessavano solo le versioni comprese tra la 3.0.0 e la 3.0.6, tutto ciò che devi fare è controllare quali versioni stavi utilizzando per sapere quali applicazioni devono essere rimosse o aggiornate con la nuova patch – 3.0.7. XNUMX.
Giusto per mostrare quanto sia ampio l'elenco dei sistemi operativi e delle applicazioni aziendali più noti che utilizzano OpenSSL, dai un'occhiata a questo stratagemma pubblicato come servizio pubblico in modo che le persone sapessero quanto dovrebbero essere preoccupate.
In che modo un hub di sicurezza basato sull'evidenza può essere d'aiuto
Nell’ambito dell’evoluzione del panorama della sicurezza informatica, anche di così ampia portata vulnerabilità, stiamo attualmente assistendo l'evoluzione della sicurezza applicativa verso la sicurezza della catena di fornitura del software. Una nuova generazione di strumenti e tecnologie è stata sviluppata per cercare di risolvere questi problemi. Offrendo una piattaforma di garanzia continua della sicurezza del codice basata sull'evidenza in grado di garantire l'affidabilità del ciclo di vita dello sviluppo del software e dei componenti software, gli strumenti e le soluzioni automatizzati aiutano le organizzazioni a raggiungere un nuovo livello di sicurezza. La mappatura continua delle dipendenze e delle vulnerabilità semplifica la correzione o l'applicazione delle patch quando diventano disponibili.
Scriba è un hub per la sicurezza della catena di fornitura del software. Raccoglie prove e le presenta per ogni build che passa attraverso la pipeline CI/CD. L'obiettivo della soluzione di Scribe era facilitare l'adesione alle normative e alle migliori pratiche dell'UE e degli Stati Uniti per migliorare la trasparenza del software e promuovere la fiducia tra sviluppatori di software e utenti. La piattaforma consente di creare e condividere SBOM complete e altri approfondimenti sulla sicurezza. Inoltre, la piattaforma può confermare che la build che stai visualizzando è conforme sia al framework SSDF del NIST che ai requisiti SLSA di livello 3. Non devi più armeggiare cercando di capire dove stai utilizzando quale versione di quale libreria perché hai un archivio prove con una SBOM per ciascuna delle tue build. Ora, capirlo è semplice come cercare una frase particolare in un documento di testo.
Un’ultima parola: preparati alla prossima grande scoperta di vulnerabilità
La storia del progetto OpenSSL della patch 3.0.7 ci offre due punti di vista, ugualmente importanti, su come gestire le vulnerabilità potenzialmente critiche.
Dal lato interessato, ovvero l’azienda o il progetto che è stato potenzialmente compromesso da queste vulnerabilità, abbiamo informato la trasparenza. Non divulgano immediatamente informazioni che potrebbero causare danni, ma rivelano tutto ciò che possono non appena vengono a conoscenza di un problema. Non solo offrono anche una sequenza temporale per la risoluzione oltre a quante più informazioni possibili sul problema. Una volta creata una patch o una soluzione, non erano timidi nel rivelare esattamente cosa non andava e come poteva essere potenzialmente sfruttato. Questo tipo di trasparenza incoraggia la fiducia. Utenti e clienti vogliono sapere e sentire che l'azienda si prende cura di loro di più, o almeno tanto quanto fa per i profitti o per il suo consiglio di amministrazione.
Nel 2014 il progetto OpenSSL è caduto vittima di un bug critico denominato 'sanguinamento' – un difetto critico nell'implementazione TLS/DTLS di OpenSSL che ha reso possibile a un utente malintenzionato di ottenere segreti come materiale della chiave di crittografia, password e altre informazioni sensibili dai server interessati. Heartbleed ha mostrato cosa può fare una vulnerabilità critica in OpenSSL poiché colpisce un'ampia varietà di programmi e distribuzioni Linux. Cercare di identificare e riparare ogni sistema vulnerabile ha dato ai team di sicurezza mesi di grattacapi. L'implementazione di uno strumento, come una SBOM, che potrebbe rendere più semplice e veloce l'aggiornamento e l'applicazione di patch al software sarebbe un vantaggio per il team di sicurezza informatica di qualsiasi azienda.
Dal punto di vista correttivo, sapere esattamente con cosa devi lavorare, quale versione di quali pacchetti stai utilizzando e dove è essenziale per essere in grado di gestire qualsiasi potenziale emergenza di questo tipo. Prendendo Log4J come esempio: alcune aziende stanno ancora cercando di capire se sono interessate o meno da questa vulnerabilità a più di un anno dalla sua scoperta.
Il fatto che non devi preoccuparti solo del tuo software e dei tuoi server, ma anche di quelli di eventuali fornitori di terze parti che utilizzi o di fornitori di servizi con cui lavori, anche utilizzando connessioni API, significa che noi, tutti di noi, abbiamo davvero bisogno di costruire una rete di fiducia tra di noi. Tale fiducia dovrebbe dipendere il più possibile da prove concrete. Crea e monitora le tue SBOM e quelle di qualsiasi azienda con cui sei in affari, condividi tali SBOM e mostra buona fede nell'annunciare e correggere qualsiasi vulnerabilità sfruttabile di cui vieni a conoscenza.
Sarebbe necessario che tutti noi lavorassimo insieme per arrivare a un mondo in cui condividere tali prove sia un luogo comune quanto condividere le ultime PR dell'azienda sui social media. Senza questa fiducia, stiamo solo preparando il terreno per la prossima grande vulnerabilità critica che distruggerà l’infrastruttura interconnessa per la quale tutti lavoriamo così duramente da mantenere.
Questo contenuto è offerto da Scribe Security, un fornitore leader di soluzioni di sicurezza end-to-end per la catena di fornitura di software, che offre sicurezza all'avanguardia per artefatti di codice e processi di sviluppo e distribuzione del codice attraverso le catene di fornitura di software. Per saperne di più.
Post Correlati
