Nella giornata di ieri, un ricercatore di sicurezza ha pubblicato un articolo, poi rimbalzato da molte fonti, secondo cui, in determinate condizioni, attori malintenzionati potrebbero sfruttare in concatenazione una serie di vulnerabilità in diversi componenti del sistema di stampa open-source CUPS per eseguire codice arbitrario da remoto su macchine vulnerabili.

Tracciate come CVE-2024-47076 (libcupsfilters), CVE-2024-47175 (libppd), CVE-2024-47176 (cups-browsed) e CVE-2024-47177 (cups-filters), gli è stato inizialmente assegnato uno score complessivo CVSS3 di 9.9.

Tuttavia, ed è nostra opinione personale, ci sono tanti fattori che non sono stati considerati o che lo sono stati ma solo superficialmente, che abbasserebbero di molto la reale criticità di quanto scoperto. Ma prima di arrivare al dunque, vediamo più nel dettaglio quanto individuato.

I dettagli delle Vulnerabilità

Le vulnerabilità non sono ancora state analizzate dal NIST al momento della pubblicazione di questo articolo. A ragion di ciò, riportiamo lo score rilasciato su GitHub:

  • CVE-2024-47176 – CVSS3 8.6 (GitHub): Libreria cups-browsed (versioni uguali o precedenti alla 2.0.1), il servizio utilizza la porta la porta UDP 631, accettando pacchetti da qualsiasi fonte. Consentirebbe ad un attaccante di utilizzare una richiesta IPP “Get-Printer-Attributes” verso un URL malevolo.
  • CVE-2024-47076 – CVSS3 8.6 (GitHub): Libreria libcupsfilters (versioni uguali o precedenti alla 2.1b1), la funzione “cfGetPrinterAttributes5” non verifica gli attributi IPP ricevuti da un server IPP, permettendo ad un attaccante di inviare dati del sistema CUPS.
  • CVE-2024-47175 – CVSS3 8.3 (GitHub): Libreria libppd (versioni uguali o precedenti alla 2.1b1), la funzione “ppdCreatePPDFromIPP2” non verifica correttamente gli attributi IPP prima di scriverli in un file PPD temporaneo, permettendo ad un attaccante di iniettare dati nel PPD risultante.
  • CVE-2024-47177 – CVSS3 9.0 (GitHub): Libreria cups-filters (versioni uguali o precedenti alla 2.0.1), la funzione “foomatic-rip” consente l’esecuzione di comandi arbitrari tramite il parametro “FoomaticRIPCommandLine” presente nel PPD.

CUPS (Common UNIX Printing System) è il sistema di stampa più diffuso sui sistemi Linux, ed è generalmente supportato anche su dispositivi che eseguono sistemi operativi Unix-like come FreeBSD, NetBSD, OpenBSD e i loro derivati.

Uno dei suoi componenti è il demone cups-browsed, che cerca nella rete locale stampanti condivise all’interno della rete e le rende disponibili per la stampa sul dispositivo. Questo è simile al modo in cui Windows e macOS possono cercare stampanti di rete remote per la stampa.

Margaritelli ha scoperto che, se il daemon cups-browsed è abilitato (il che non avviene sulla maggior parte dei sistemi), esso ascolta sulla porta 631/UDP. Inoltre, per impostazione predefinita, consente connessioni remote da qualsiasi dispositivo sulla rete per creare una nuova stampante.

Inoltre, sarebbe possibile creare una stampante malevola con una PostScript Printer Description (PPD), che potrebbe essere manualmente “proposta” ad un servizio cups-browsed esposto in esecuzione sulla porta 631/UDP.

Facendo ciò, si causerebbe l’installazione automatica della stampante utilizzata dall’attaccante sulla macchina remota, rendendola disponibile per la stampa. Se l’utente sul server esposto stampa su questa nuova stampante, il comando malevolo contenuto nel file PPD verrà eseguito localmente sul computer.

Il comando da eseguire durante la stampa viene aggiunto attraverso un filtro foomatic-rip, che esegue comandi su un dispositivo per garantire che un lavoro di stampa venga reso correttamente.

L’impatto è davvero Critico? Secondo noi, no

Iniziamo con il sottolineare che l’impatto, nella grande maggior parte dei casi, è limitato alla sola rete locale, il che prevede che l’attaccante sia in grado di accedervi, e non può quindi essere sfruttata attraverso internet.

Questo perché, di default, la porta 631 e il relativo servizio CUPS non sono esposti in internet e, inoltre, tutti i firewall recenti come policy di default limitano le porte esposte esternamente.

Inoltre, sebbene si tratti di una catena con impatto RCE, va notato che gli attaccanti devono superare diversi ostacoli non indifferenti per poter sfruttare le vulnerabilità e ottenere effettivamente l’esecuzione di codice remoto.

Il primo ostacolo è che i sistemi target devono avere abilitato il demone cups-browsed, che nella maggior parte delle distribuzioni OS non è abilitato di default, per esporre le porte UDP sulla rete.

In ultima fase, poiché la catena di attacco richiede una stampante malevola nella rete locale, aggiunta tramite il rilevamento di rete, l’attaccante deve riuscire ad indurre un utente a stampare da un server di stampa malevolo sulla rete locale, che improvvisamente compare sul dispositivo.

A seguito di quanto detto finora, il nostro giudizio è di esser di fronte sicuramente ad una CVE chain ad alto impatto, ma, allo stesso tempo, le probabilità che questa possa essere sfruttata nel mondo reale risulterebbero essere molto basse, abbassando quindi di molto il rischio derivato da questa vulnerabilità.

Stiamo suggerendo che non sia necessario procedere a nessuna attività di verifica e/o mitigazione? Assolutamente no.

È imprescindibile verificare qualsiasi vulnerabilità che possa avere un impatto sufficientemente considerevole per i sistemi IT di un’organizzazione, chiaramente in riferimento al contesto individuale.

Quello che suggeriamo è, quindi, di procedere alle opportune verifiche il prima possibile (che indichiamo in fondo all’articolo), valutare l’eventuale impatto attraverso un processo di Risk Management e, infine, applicare le mitigazioni più opportune, tenendo sempre a mente le principali best practice nell’ambito della sicurezza informatica, che prevedono di non esporre direttamente in internet nessun servizio non strettamente necessario alle attività di business.

Cosa dicono gli esperti

“Si tratta di una catena di bug che si basa sullo spoofing di una stampante nella rete locale che viene automaticamente aggiunta tramite il rilevamento di rete, se questa funzione è attivata, cosa che non avviene di solito nella configurazione predefinita. Successivamente, una variabile non verificata viene utilizzata per sfruttare altre vulnerabilità nel sistema CUPS per eseguire codice, ma solo quando viene avviato un lavoro di stampa” – ha dichiarato Ilkka Turunen, Field CTO di Sonatype.

“La buona notizia è che si tratta di un RCE, ma con diverse mitigazioni, tra cui il fatto che l’attaccante deve essere in grado di connettersi a un computer tramite UDP, che è ampiamente disabilitato in ingresso nelle reti, e il servizio di solito non è attivo di default. Sembra quindi che l’impatto nel mondo reale sia basso.”

Per questi motivi, Red Hat ha classificato le vulnerabilità con un impatto di severità “Importante” anziché critico.

Nessuna patch disponibile, solo misure di mitigazione

Mentre le patch sono ancora in fase di sviluppo, Red Hat ha condiviso un wordaround per impedire lo sfruttamento della falla: interrompere l’esecuzione del servizio cups-browsed e di impedire che venga avviato al riavvio, per spezzare la catena di exploit.

Di seguito i comandi da utilizzare:

Per verificare se cups-browsed è in esecuzione sui propri sistemi:

Se il risultato mostra “Active: inactive (dead)”, la catena di exploit è interrotta e il sistema non è vulnerabile. Se il risultato mostra “running” o “enabled”, e la direttiva **BrowseRemoteProtocols** nel file di configurazione **/etc/cups/cups-browsed.conf** contiene il valore “cups”, allora il sistema è vulnerabile.

In conclusione, suggeriamo a tutti di verificare quali porte aperte stiano esponendo i propri Server in Internet, provvedendo immediatamente a modificare qualsiasi configurazione non sicura, non solo in relazione alla porta 631/udp, ma per qualsiasi porta la cui esposizione non sia fondamentale per le attività di business.

Ti è piaciuto l’articolo? Seguici su Linkedin per sostenerci!

consigliati