Preparazione efficace per la vulnerabilità di OpenSSL 3.x
Aggiornamento: (1 novembre 2022): La delivery dei contenuti Akamai tramite HTTP e HTTPS non è interessata da questa vulnerabilità poiché i server utilizzano una versione di OpenSS non interessata. Inoltre, i sistemi Akamai utilizzano meccanismi di protezione dello stack standard del settore che mitigano il vettore di attacco descritto. Akamai sta applicando patch a tutti i sistemi interni potenzialmente interessati, ma non prevediamo che questi sforzi causeranno downtime per i nostri clienti.
Il 25 ottobre, il team del progetto OpenSSL ha annunciato una correzione di sicurezza per una vulnerabilità critica in OpenSSL versione 3.x. Il rilascio della patch è previsto per il 1° novembre 2022, tra le 13:00 e le 17:00 UTC.
Questo annuncio ha generato molto rumore a causa dell'uso estensivo di OpenSSL. Con questo articolo, speriamo di farci sentire e fornire informazioni e suggerimenti su come rilevare e mitigare la minaccia senza speculazioni. La prima parte del post descriverà OpenSSL e la portata della vulnerabilità. La seconda parte descriverà come OpenSSL viene utilizzato nelle applicazioni e fornirà strumenti per rilevare le risorse vulnerabili. Potete passare direttamente a queste utilità, se preferite.
Nota: questo post del blog descrive un incidente in evoluzione e verrà aggiornato man mano che verranno raccolte ulteriori informazioni e la correzione verrà rilasciata.
Qual è la portata di questa vulnerabilità?
Questa vulnerabilità ha causato preoccupazione nella comunità della sicurezza perché, per il team OpenSSL è insolito classificare una vulnerabilità come critica, successivamente declassata ad "Alta". Dall'introduzione delle etichette di questa vulnerabilità dopo Heartbleed (una vulnerabilità che causa una perdita di memoria e la possibile divulgazione di chiavi), ce n'è stata solo un'altra, CVE-2016-6309 che è stata classificata come "Critica".
Secondo i requisiti del team OpenSSL, per essere classificata come critica, una vulnerabilità interessa le configurazioni comuni ed è probabile che sia sfruttabile. Un esempio di tali vulnerabilità potrebbe includere "la divulgazione significativa del contenuto della memoria del server (potenzialmente rivelando i dettagli dell'utente), vulnerabilità che possono essere facilmente sfruttate in remoto per compromettere le chiavi private del server o in cui l'esecuzione di codice in modalità remota è considerata probabile in situazioni comuni".
Considerando quanto sia comune la libreria OpenSSL, una sua vulnerabilità può essere dannosa. Tuttavia, sebbene la consapevolezza sia necessaria, non c'è ancora motivo di panico. OpenSSL è molto comune, ma la sua versione più diffusa è 1.X.X, e la vulnerabilità interessa solo le versioni OpenSSL 3.0.0 e successive (rilasciato solo a settembre 2021). Pertanto, la vulnerabilità sarà probabilmente meno comune rispetto alla distribuzione della stessa libreria OpenSSL.
Abbiamo eseguito i nostri strumenti di rilevamento su alcune delle nostre reti gestite e abbiamo appreso quanto segue:
Circa il 50% degli ambienti monitorati disponeva di almeno un computer con almeno un processo dipendente da una versione vulnerabile di OpenSSL.
Di quelle reti, la percentuale di computer nella rete che avevano una certa dipendenza da una versione vulnerabile di OpenSSL variava dallo 0,2% al 33%.
La copertura mediana era del 6,1% e la media era dell'11,3% con una deviazione standard dell'11,6%.
Queste statistiche non tengono conto dell'utilizzo non vulnerabile di OpenSSL. L'unica metrica sono i computer con almeno un processo che dipende da una versione vulnerabile di OpenSSL (3.0–3.6). Né sono stati presi in considerazione altri processi in esecuzione sullo stesso computer.
Che cos'è OpenSSL?
OpenSSL è un toolkit software open source e, pertanto, le versioni di OpenSSL sono fondamentalmente versioni del codice sorgente. Per il rilevamento, ciò che significa che ci sono molti modi in cui un'applicazione può essere caricata o basarsi su OpenSSL, con una conseguente criticità della vulnerabilità.
Innanzitutto, dobbiamo definire i tre componenti di OpenSSL.
libcrypto : una libreria crittografica con implementazione di molti protocolli (ad es. AES, RSA, ChaCha, ecc.)
libssl : una libreria che implementa tutti i protocolli TLS fino a TLSv1.3
openssl : un'utilità della riga di comando per varie operazioni (ad esempio, generazione di certificati)
Affinché un'applicazione faccia affidamento su OpenSSL, deve chiamare una logica di codice di libcrypto o libssl (openssl è un'applicazione che si basa su queste due librerie).
Mitigazione della vulnerabilità OpenSSL
Il primo passo per mitigare la minaccia OpenSSL è rilevare le risorse vulnerabili. Sebbene questo consiglio sia comune, raramente è accompagnato da metodi pratici. Forniamo un elenco di applicazioni vulnerabili note (di seguito), nonché un metodo generale per trovare le applicazioni vulnerabili nella rete.
Segmentazione: una mitigazione pre e post-patch
Sebbene l'applicazione di patch potrebbe non essere immediatamente possibile, poiché la maggior parte della dipendenza da OpenSSL deriva dal software dei fornitori (che devono applicare la correzione autonomamente), possiamo comunque sfruttare la visibilità ottenibile dal rilevamento. Possiamo utilizzare la segmentazione e il routing per ridurre la diffusione che un autore di attacchi potrebbe ottenere abusando della vulnerabilità.
Possiamo imporre ulteriori restrizioni sulle risorse Internet, sotto forma di una DMZ (più rigorosa).
Possiamo creare una maggiore segmentazione in tutto il dominio, in modo che un computer interno violato non possa essere utilizzato per propagarsi all'intera rete. Questo può anche essere utilizzato per ridurre la superficie di attacco di un computer vulnerabile solo alla parte della rete con cui deve effettivamente comunicare.
Inoltre, possiamo sfruttare questa visibilità e rilevamento per creare un piano d'azione per l'applicazione delle patch e per garantire che nulla venga ignorato. Dopo il rilascio delle patch e il completamento del processo di applicazione delle patch, è possibile eseguire nuovamente la logica di rilevamento e confrontare i risultati. Idealmente, non ci saranno più computer vulnerabili.
Quali applicazioni note sono vulnerabili?
BoringSSL (utilizzato in Google Chrome) e LibreSSL sono due librerie basate sul codice OpenSSL e non sono ancora interessate dall'imminente vulnerabilità.
Diverse distribuzioni Linux spesso vengono fornite con la libreria OpenSSL. Se eseguite un ambiente Linux, potreste verificare se state utilizzando una delle seguenti versioni, fornite con la versione OpenSSL vulnerabile.
Red Hat Enterprise Linux 9
Ubuntu 22.04+
CentOS Stream9
Kali 2022.3
Debian 12
Fedora 36
Se state utilizzando una distribuzione Linux che non è nell'elenco, la sicurezza dalle vulnerabilità non è garantita. Se avete aggiornato attivamente la libreria (nell'ambito del comando di aggiornamento di un gestore di pacchetti, ad esempio), sarete vulnerabili anche voi. Potete digitare "openssl version" nel vostro terminale per visualizzare la versione della libreria.
Docker ha anche pubblicato un avviso per la sua prossima versione, in cui stima che potrebbero essere interessati circa 1.000 repository di immagini, tra varie immagini Docker Official e immagini Docker Verified Publisher. Sono incluse le immagini basate su variazioni delle distribuzioni Linux sopra menzionate.
Anche alcuni framework potrebbero essere interessati. Node.js v18.x e v19.x utilizzano OpenSSL 3 e, pertanto, si presume siano interessati dalla vulnerabilità. Eventuali nuovi aggiornamenti verranno annunciati in questo Haifei Li.
Un altro linguaggio di programmazione che ha destato preoccupazione agli sviluppatori è Golang. Le librerie nei binari Go sono collegate staticamente, il che potrebbe aver richiesto agli sviluppatori Go di ricompilare il proprio software. Quando il team di Golang ha annunciato nuove versioni minori che includevano correzioni di sicurezza nella stessa data dell'imminente patch OpenSSL, le persone hanno collegato le due cose pensando che fossero correlate. Non preoccupatevi: si trattava di un falso allarme. Le versioni di Golang non sono correlate all'imminente vulnerabilità.
È probabile che l'elenco delle applicazioni vulnerabili cresca nei prossimi giorni e aggiorneremo questo post di conseguenza. Le sezioni successive forniranno metodi e strumenti di rilevamento per aiutarvi a capire quali applicazioni nel vostro ambiente utilizzano OpenSSL 3 e sono quindi anch'esse vulnerabili. Se preferite, potete passare direttamente ai meccanismi di rilevamento.
Un metodo generale per rilevare le applicazioni che utilizzano OpenSSL 3
Nota: questa sezione presenta i dettagli interni di come un'applicazione utilizza OpenSSL. Se siete interessati semplicemente al rilevamento, potete passare direttamente alle nostre regole YARA o query OSQuery.
OpenSSL può essere collegato a un'applicazione sia in modo statico che dinamico. Con il collegamento statico, il codice sorgente di OpenSSL viene incluso come parte del codice dell'applicazione ed entrambi vengono compilati insieme nello stesso file binario. Con il collegamento dinamico, OpenSSL viene compilato separatamente in una libreria condivisa (libssl.dll e libcrypto.dll su Windows; libssl.so e libcrypto.so su Linux). Il codice dell'applicazione contiene quindi riferimenti nella libreria condivisa e questi vengono risolti dal sistema operativo quando carica l'applicazione.
Come si traduce questo in rilevamento? In pratica, sarà sufficiente un metodo per rilevare binari compilati staticamente. Perché? Perché se un'applicazione in esecuzione carica dinamicamente OpenSSL, o anche se carica dinamicamente una libreria che a sua volta carica dinamicamente OpenSSL (e così via), alla fine verrà caricata una libreria OpenSSL compilata staticamente. Poiché tutti i caricamenti dinamici avvengono nel contesto dello stesso processo, non ci resta che esaminare l'elenco delle librerie caricate in ciascun processo e trovare quella compilata staticamente.
Quindi, dobbiamo capire qual'è l'aspetto di OpenSSL compilato staticamente. Fortunatamente, è abbastanza semplice. Tutte le compilazioni statiche di OpenSSL contengono una stringa di versione, simile a questa: OpenSSL 3.0.6 11 Oct 2022, dove 3.0.6 è il numero di versione. Il rilevamento di questa stringa è piuttosto semplice e può essere eseguito con Regex o YARA.
Questa, tuttavia, potrebbe non essere una corrispondenza perfetta. Poiché OpenSSL è un codice open source, gli utenti possono facilmente modificare la logica di controllo delle versioni in base alle proprie esigenze (e quindi eludere il nostro rilevamento). L'abbiamo visto accadere solo una volta (con Cisco, che ha utilizzato invece la stringa CiscoSSL 1.1.1k.7.2.225 ), ma potrebbe accadere anche con altri fornitori.
Cosa sappiamo?
Anche se non sapremo molto fino al rilascio della correzione, ci sono alcune cose che gli addetti ai sistemi di difesa possono fare preventivamente per essere preparati alla patch. Il nostro team ha creato alcune utilità che potete eseguire nel vostro ambiente per visibilità e facilità di mitigazione. I clienti di Akamai Guardicore Segmentation con la funzionalità Insight abilitata possono facilmente eseguire questa logica nel proprio ambiente.
YARA
La regola principale che possiamo scrivere è per la stringa che abbiamo menzionato sopra. Per brevità, limiteremo il nostro rilevamento solo alle versioni effettive di OpenSSL che sono interessate dal rilascio, ma possiamo facilmente modificare i nostri criteri.
rule openssl_version {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
Nel caso in cui non vogliamo fare affidamento sulla stringa, possiamo anche cercare l'applicazione principale che si basa su OpenSSL, ma analizzare le importazioni dell'eseguibile. Tuttavia, questo è un metodo meno infallibile, e dovrebbe essere trattato come tale.
import "elf"
import "pe"
rule elf_import_openssl {
condition:
(elf.type == elf.ET_EXEC or elf.type == elf.ET_DYN) and
(
for any i in (0..elf.symtab_entries):
(
elf.symtab[i].name contains "@OPENSSL_3"
)
)
}
rule pe_import_openssl {
condition:
pe.is_pe and
(
for any i in (0..pe.number_of_imports):
(
pe.import_details[i].library_name contains "libcrypto-3" or pe.import_details[i].library_name contains "libssl-3"
)
)
}
osquery
Utilizzando le query di cui sopra, possiamo anche sfruttare la tabella YARA di osquery, per eseguire tali regole su tutti i processi in esecuzione.
WITH FIRST_QUERY AS (SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid))
SELECT *
FROM FIRST_QUERY
JOIN yara ON yara.path = FIRST_QUERY.mmap_path
WHERE sigrule = 'rule openssl_3 {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
'
AND yara.count > 0
Naturalmente, potete anche inserire le altre regole YARA che abbiamo menzionato o aggiungere più o meno filtri per restringere o ampliare il numero di file controllati.
Riepilogo
Il team di OpenSSL ha adottato un approccio interessante informando i team di sicurezza dell'imminente rilascio della correzione. Questo annuncio ha dato agli addetti ai sistemi di difesa il tempo di preparare e mappare le risorse critiche in coda per l'applicazione delle patch. In questo post del blog, abbiamo tentato di aiutare a fare esattamente questo, individuando le applicazioni e le risorse su cui sarà necessario intervenire il giorno della patch.
Si tratta di una questione in continua evoluzione e aggiorneremo questo post del blog non appena verranno rilasciate nuove informazioni, quindi assicuratevi di rivisitare questo post per eventuali aggiornamenti. Potete anche seguirci su Twitter per ulteriori aggiornamenti in tempo reale.
