Vulnerabilità RCE critica di CUPS in Linux: cosa sappiamo e come possiamo prepararci
Analisi riassuntiva
Una catena di vulnerabilità critica per l'esecuzione di codice remoto (RCE), che sembra interessare molti host Unix, è stata segnalata il 26 settembre 2024.
Il componente vulnerabile si chiama CUPS (Common Unix Printing System), nello specifico è un componente cups-browsed.
Per sfruttare correttamente questo componente, è richiesta una catena di quattro vulnerabilità: CVE-2024-47176, CVE-2024-47076, CVE-2024-47175 e CVE-2024-47177.
In questo blog, Akamai condivide informazioni utili su questa vulnerabilità, analizza l'informativa tecnica e fornisce consigli su cosa fare per prepararsi e per mitigare i rischi in modo efficace mentre si aspetta la pubblicazione di una patch.
Introduzione
Il 23 settembre 2024, Simone Margaritelli , un ricercatore che si occupa di sicurezza, ha condiviso utili informazioni sui social media riguardo all'imminente segnalazione di una vulnerabilità. Nel suo post, Margaritelli ha descritto una vulnerabilità critica che aveva segnalato agli sviluppatori tre settimane prima: una vulnerabilità RCE non autenticata che può interessare tutti i sistemi GNU/Linux.
Il 26 settembre 2024, è stata pubblicata un' informativa tecnica completa. Sono presenti quattro vulnerabilità in totale:
CVE-2024-47176 in cups-browsed, che forza l'invio di una richiesta ad un indirizzo controllato da un criminale
CVE-2024-47076 in libcupsfilters, che non convalida né verifica l'integrità dei dati restituiti dal server del criminale e li trasmette al resto del sistema CUPS
CVE-2024-47175 in libppd, che, nuovamente, non verifica l'integrità dei dati immessi e li scrive su un file temporaneo
CVE-2024-47177 in cups-filters, che consente di eseguire un comando arbitrario
Il nostro obiettivo con questo blog è aiutare le organizzazioni a prepararsi per facilitare il più possibile il processo di mitigazione. A tal scopo, offriamo un riepilogo tecnico della catena di vulnerabilità e alcune operazioni di mitigazione (sotto forma di consigli per la segmentazione) che gli amministratori di rete possono utilizzare mentre attendono la pubblicazione di una patch.
Cosa fare per prepararsi?
Per sfruttare una vulnerabilità RCE, ad un criminale servono due componenti: una parte di software vulnerabile e (ovviamente) un accesso remoto. Poiché sappiamo che, nel nostro caso, il componente vulnerabile è CUPS, possiamo semplicemente correggerlo con una patch (se disponibile) o eseguire alcune operazioni di mitigazione specificamente per questo componente, anche se riteniamo che il modo migliore sia usare questa opportunità per trattare l'accesso remoto più ampiamente.
Iniziamo comunque dalla questione più urgente.
Le vulnerabilità CUPS e come possono essere sfruttate
L'oggetto della nostra discussione è il componente vulnerabile CUPS, un servizio che consente ad un computer di fungere da server di stampa. Si tratta di un servizio molto comune, che si può trovare su molti computer Unix.
A causa della sua popolarità, può sicuramente risultare un bersaglio allettante per i criminali poiché tende ad essere vulnerabile su altri computer (e, potenzialmente, su Internet) per sua natura intrinseca. Alcune precedenti vulnerabilità dei servizi di stampa, come CVE-2021-34527 (PrintNightmare) o, persino, CVE-2010-2729, hanno dimostrato il potenziale impatto di questo vettore di attacco.
Anche prima della sua divulgazione "ufficiale", abbiamo teorizzato che il servizio CUPS fosse il componente vulnerabile. Esaminando l'account GitHub di Margaritelli ,ci siamo imbattuti in un dettaglio interessante: un fork del repository di Apple CUPS del 17 settembre 2024, ossia pochi giorni prima del suo post iniziale (Figura 1).
È stato trovato anche un problema sul componente cups-browsed dell'account GitHub che cita Margaritelli (@evilsocket) relativamente ad una potenziale conseguenza della vulnerabilità principale (ci sono anche alcuni commenti qui, armiamoci di pazienza... )
Analisi dello sfruttamento
L'attacco non è particolarmente complesso, ma richiede più operazioni per la sua riuscita. Nella Figura 2, viene riportato il nostro riepilogo del processo, ma vi consigliamo di leggere tutto il blog informativo per una spiegazione più dettagliata.
Fase 1: innanzitutto, il daemon cups-browsed ascolta le connessioni UDP in entrata tramite la porta 631. Il suo scopo è aggiungere le stampante rilevate al sistema. Un criminale che comunica con il daemon può semplicemente forzare il computer preso di mira a registrare un indirizzo dannoso come se si trattasse di una stampante legittima. In tal caso, si parla di una vulnerabilità CVE-2024-47176.
Fase 2: nella fase successiva, durante la registrazione della "stampante" dannosa, il componente libcupsfilters invia una richiesta in uscita al criminale, richiedendo gli attributi della stampante tramite l'IPP (Internet Printing Protocol). In quanto parte di questi attributi, le stampanti possono definire specifici file PPD (PostScript Printer Description) da poter poi usare per definire in modo legittimo le funzionalità della stampante, che, a loro volta, vengono scritte in un file .ppd, di cui non è stata verificata l'integrità e che non presenta vincoli. In tal caso, si parla delle vulnerabilità CVE-2024-47076 e CVE-2024-47175.
A questo punto, abbiamo un file .ppd dannoso, ma come avviamo l'esecuzione di comandi tramite questo file?
Fase 3: inseriamo il comando cupsFilter2 nel file PPD, che esegue vari filtri (file eseguibili) ogni volta che viene creato un nuovo lavoro di stampa. Usiamo il comando del filtro per eseguire il filtro foomatic-rip , che è vulnerabile ad un comando arbitrario di tipo injection. In tal caso, si parla della vulnerabilità CVE-2024-47177.
Uno sguardo ravvicinato
Tramite Shodan, siamo riusciti ad osservare circa 75.000 computer in tutto il mondo con il componente CUPS esposto su Internet, nella maggior parte dei casi, tramite la porta predefinita 631 (Figura 3).
È possibile usare il filtro riportato di seguito per cercare i server CUPS vulnerabili tramite Shodan.
product:"CUPS (IPP)"
Informazioni aggiuntive
Tramite le esclusive informazioni di Akamai sui dati relativi al traffico, abbiamo osservato il servizio CUPS eseguito su un'ampia gamma di piattaforma, tra cui Ubuntu, macOS, CentOS, Debian, Fedora, OpenShift, Oracle Linux Server, Red Hat, Rocky Linux, SUSE, openSUSE, AlmaLinux, Amazon Linux e molti altri.
In totale, il 10,1% dei computer Linux presenti nell'ecosistema di Akamai dispongono della porta 631 (ossia, la porta CUPS) aperta. Tuttavia, solo il 3% di questi computer riceve regolarmente una quantità di traffico esterno su questa porta.
Anche se queste cifre possono indicare che il servizio non è esposto, di solito, all'esterno, è comunque importante per le organizzazioni valutare il proprio livello di esposizione e rivedere di conseguenza le proprie policy di sicurezza.
Analisi dell'esposizione su Internet
Uno dei modi più comuni per violare le organizzazioni da parte dei criminali è utilizzare i servizi su Internet. Il componente CUPS è solo un esempio di questi servizi, ma ovviamente il problema non finisce qui. Anche in questo caso, utilizzando le informazioni di Akamai sui dati relativi al traffico, abbiamo valutato lo stato di esposizione di diversi servizi in migliaia di organizzazioni.
In base ai dati di Akamai, circa il 5,4% dei computer Linux sono esposti a Internet e ricevono una quantità di traffico in entrata da fonti esterne (Figura 4).
Esaminando le policy di rete che interessano questo traffico, abbiamo osservato che il 19,3% di questi computer accetta automaticamente il traffico Internet in entrata , ossia non hanno implementato specifiche policy di rete per restringere o controllare il flusso di questo traffico.
Poiché i servizi esposti su Internet possono diventare facilmente un vettore di attacco, è fondamentale per le organizzazioni rivedere i propri controlli degli accessi e applicare policy più rigorose.
Suggerimenti
Poiché la vulnerabilità non è ancora pubblica e non si sa quando saranno pubblicate le patch, il modo migliore per prepararsi è mappare tutti i punti vulnerabili della propria rete (ad esempio, stilare un elenco di tutti i computer Linux presenti, il loro livello di esposizione a Internet o, persino, se usano il componente CUPS) e le relative policy di segmentazione.
Una volta mappati tutti i componenti interessati, si consiglia di applicare le policy di segmentazione appropriate per limitare il raggio d'azione di un potenziale attacco. Si tratta di una buona prassi da adottare indipendentemente dalla situazione corrente perché il movimento laterale di Linux non è limitato agli SSH o alle RCE.
Identificazione dell'utilizzo del componente CUPS in un'organizzazione
Per identificare il componente CUPS eseguito sui propri computer, è possibile effettuare una ricerca per il nome del servizio e/o del processo. In base a quanto abbiamo osservato su vari sistemi e distribuzioni Unix, i seguenti processi possono indicare l'utilizzo del componente CUPS:
cups-browsed (il processo interessato).
cupsd
cancel.cups
lpq.cups
cupsfilter
lpc.cups
lp.cups
cupsaccept
cups-lpd
lpstat.cups
lpr.cups
cupsctl
Le organizzazioni che impiegano la osquery possono utilizzare le seguenti query per identificare il potenziale utilizzo del componente CUPS sui propri sistemi (i clienti di Akamai Guardicore Segmentation possono eseguire queste query tramite la funzione Insight).
Rileva computer in ascolto sulla porta 631:
SELECT pid, port, protocol, family, address, path
FROM listening_ports
WHERE port = 631
Rileva processi in esecuzione potenzialmente correlati al componente CUPS:
SELECT name, parent, cwd, cmdline, pid, start_time, path
FROM processes
WHERE path LIKE '%cups%'
Identificazione dell'esposizione su Internet
È possibile usare appositi servizi di analisi, come, ad esempio, Shodan, per identificare i servizi esposti a Internet, tra cui CUPS.
I clienti di Akamai Guardicore Segmentation possono usare il filtro della connessione a Internet che si trova nella scheda Reveal per visualizzare tutti i propri servizi e computer che ricevono traffico proveniente da Internet (Figura 5).
Utilizzo della segmentazione per limitare il potenziale raggio d'azione
Consideriamo il seguente scenario: la vulnerabilità è stata segnalata, non si presenta come previsto né siamo preparati per gestirla, qualcuno tenta di sfruttarla e un criminale la utilizza per violare la rete presa di mira.
Poi cosa succede? Il criminale può semplicemente utilizzare un controller di dominio, infettare l'intera rete, rilasciare una botnet/cryptominer/ransomware/trojan e uscire indisturbato dal sistema preso di mira? Oppure il criminale deve lavorare più duramente, eseguire complesse analisi di ricognizione, utilizzare più passaggi di movimento laterale e mostrarsi proattivo in modo più generico per offrire all'organizzazione presa di mira una maggiore opportunità di rilevare la violazione e intraprendere le misure appropriate?
Le violazioni si verificano continuamente, ecco perché la segmentazione è importantissima. Se oggi non viene sfruttata una RCE, potrà essere sfruttata domani. Le reti flat sono bersagli facili, ma se rendiamo difficile la vita ad un criminale, possiamo farli desistere dal loro intento (e farli spostare verso vulnerabilità più semplici da sfruttare) oppure forzarli ad impiegare tempo e ad eseguire azioni tali da prendere sviste, commettere errori e così venire rilevati.
Miglioramento del sistema di sicurezza con 2 operazioni
Sono due le operazioni relativamente semplici che possono migliorare notevolmente il sistema di sicurezza di un'organizzazione: implementare una DMZ e segmentare i server applicativi.
Implementare una DMZ. I server rivolti a Internet sono, per loro natura, maggiormente esposti ai rischi; pertanto, non dovrebbero avere un accesso completo al resto della rete. L'implementazione di una DMZ perimetrale tale da impedire a questi server di accedere alle parti critiche della rete complica di molto la vita dei criminali.
Segmentare i server applicativi. Di solito, è possibile segmentare insieme server applicativi simili e restringere facilmente il loro traffico in entrata e in uscita sulla base della logica delle loro applicazioni.
Ad esempio, prendiamo il server CUPS: conosciamo la sua porta (UDP 631) e il suo processo (cupsd) e sappiamo che, tecnicamente, dovrebbe generare solo traffico indirizzato alle stampanti attuali. Possiamo quindi creare un segmento delle applicazioni per questi server CUPS per consentire di accettare una specifica parte del traffico in entrata e rifiutare il resto del traffico.
In tal modo, un criminale che riesce a sfruttare la vulnerabilità CUPS per violare il server sarà solo in grado di accedere alla stampante, nulla di più.
Ulteriori informazioni
Esistono altre soluzioni che un'organizzazione può applicare per ottenere vantaggi immediati tramite la segmentazione allo scopo di migliorare il suo sistema di sicurezza. Per ulteriori informazioni, si prega di leggere il nostro blog sulla segmentazione pratica.