La minaccia degli attacchi DDoS nel servizio CUPS
Editoriale e commenti aggiuntivi di Tricia Howard
Analisi riassuntiva
I ricercatori di Akamai hanno confermato la presenza di un nuovo vettore di attacco nel servizio CUPS che potrebbe essere sfruttato per sferrare attacchi DDoS (Distributed Denial-of-Service). (CVE-2024-47850)
Dalla ricerca, è emerso che, per lanciare l'attacco, il sistema del criminale deve semplicemente inviare un solo pacchetto al servizio CUPS vulnerabile e connesso a Internet.
Il team Akamai Security Intelligence and Response Team (SIRT) ha riscontrato che più di 198.000 dispositivi sono vulnerabili a questo vettore di attacco e sono accessibili sull'Internet pubblico, dei quali il 34% circa potrebbe essere usato per lanciare attacchi DDoS (più di 58.000 dispositivi).
Centinaia di questi 58.000 dispositivi vulnerabili e oltre hanno mostrato un loop "infinito" di richieste.
Le limitate risorse richieste per sferrare un attacco sottolineano la presenza di questo pericolo: ad un criminale servirebbero solo pochi secondi per appropriarsi di ogni servizio CUPS vulnerabile attualmente visibile su Internet con una spesa inferiore ad un centesimo sulle moderne piattaforme hyperscaler.
Le vulnerabilità CVE
Il 26 settembre 2024, evilsocket, un ricercatore della sicurezza, ha annunciato la presenza di vulnerabilità legate all'esecuzione di codice remoto (RCE) nel sistema CUPS (Common Unix Printing System). In breve, un criminale potrebbe manipolare da remoto gli URL del protocollo IPP (Internet Printing Protocol) per eseguire comandi dannosi con la concatenazione delle quattro diverse vulnerabilità riportate di seguito:
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
Altre informazioni sulla storia del CUPS
Durante la stesura dell'articolo tecnico sulle vulnerabilità, abbiamo scoperto che non era stato esaminato un altro vettore di attacco: quello relativo agli attacchi DDoS. Il vettore di attacco DDoS continua ad essere sfruttato per molestare e per interrompere le attività su Internet delle sue vittime, che vanno dalle grandi aziende agli enti governativi fino ai piccoli creatori di contenuti, ai negozi online e ai giocatori. Benché l'analisi originale si sia focalizzata sulle RCE, che possono avere un impatto più devastante, anche l'amplificazione degli attacchi DDoS viene facilmente sfruttata in questo caso.
Il problema sorge quando un criminale invia un pacchetto creato appositamente in cui viene specificato l'indirizzo di un obiettivo come stampante da aggiungere. Per ogni pacchetto inviato, il server CUPS vulnerabile genera una richiesta IPP/HTTP di maggiori dimensioni e in parte controllata da un criminale che viene indirizzata all'obiettivo specificato. Di conseguenza, non solo viene interessato l'obiettivo preso di mira, ma anche il server CUPS diventa una vittima perché l'attacco utilizza le risorse della CPU e la larghezza di banda della sua rete..
Sfruttamento
È possibile utilizzare un semplice script per inviare il pacchetto UDP dannoso ad un'istanza vulnerabile del sistema CUPS. Il payload appositamente creato forza il sistema CUPS ad inviare una richiesta IPP/HTTP all'obiettivo e alla porta che il criminale ha specificato. La vulnerabilità sorge nel momento in cui cups-browsed tenta di recuperare l'URI specificato per scaricare il file degli attributi IPP.
L'URI del file PPD è in qualche modo arbitrario e può essere modificato dal criminale. In fase di test, abbiamo rilevato che il payload dell'URI può essere compilato fino a 989 byte. Questo padding verrà incluso due volte nella richiesta IPP/HTTP: una volta nelle intestazioni HTTP e un'altra volta nei dati POST che verranno indirizzati al sistema preso di mira.
Utilizzando questa tecnica di padding, i criminali possono inasprire ulteriormente l'impatto degli attacchi DDoS supportati dal sistema CUPS utilizzando una maggiore quantità di risorse e larghezza di banda sulle reti e sui sistemi presi di mira. La Figura 1 è la rappresentazione visiva di quanto abbiamo discusso.
Fig. 1: Network diagram of attack flow
Sistema del criminale
Uno degli aspetti più preoccupanti di questo attacco è rappresentato dal numero limitato di risorse che servono al criminale per sferrarlo. Nelle Figure 2 e 3, viene illustrato come il sistema del criminale deve semplicemente inviare un solo pacchetto ad un servizio CUPS vulnerabile e connesso a Internet per avviare l'attacco sul sistema CUPS.
./cups.py [CUPS_IP] [TARGET_IP]:1337 attacker_controlled-payload%20goes.here
Sending UDP Payload to target [TARGET_IP] and port 1337
Bytes Sent: 78
Figura 2. Sfruttamento dello staging
09:05:03.072432 IP 192.168.12.143.43937 > X.X.X.X.631: UDP, length 78
0x0000: 4500 006a 1991 4000 4011 2ed5 c0a8 0c8f E..j..@.@.......
0x0010: xxxx xxxx aba1 0277 0056 bb25 3020 3000 .......w.V.%0.0.
0x0020: 6874 7470 3a2f 2fxx xxxx 2exx xx2e xxxx http://xxx.xx.xx
0x0030: 2exx xxxx 3a31 3333 372f 7072 696e 7465 .xxx:1337/printe
0x0040: 7273 2f61 7474 6163 6b65 725f 636f 6e74 rs/attacker_cont
0x0050: 726f 6c6c 6564 2d70 6179 6c6f 6164 2532 rolled-payload%2
0x0060: 3067 6f65 732e 6865 7265 0goes.here
Figura 3. Pacchetto UDP in uscita (modificato in un payload non funzionale)
Sistema preso di mira
Alla fine, il servizio CUPS tenta di recuperare ciò che sembra un file di attributi IPP, ma, in realtà, si tratta di ciò che ha specificato il criminale. L'obiettivo specificato nel pacchetto UDP inizia a ricevere le connessioni TCP in entrata dal sistema CUPS (Figura 4).
Fig. 4: CUPS service establishing a connection to the target
Se analizziamo più da vicino i due pacchetti ricevuti che contenevano i dati effettivi della richiesta, possiamo vedere che la richiesta IPP non elaborata e i dati POST corrispondenti, parzialmente controllati dal criminale, provengono dal servizio CUPS (Figura 5).
Fig. 5: IPP/HTTP request received by the target
Dai registri del daemon cups-browsed, possiamo notare che i tentativi di recuperare gli attributi IPP sono, in definitiva, ciò che genera queste richieste indirizzate al sistema host preso di mira (Figura 6).
Fig. 6: Cups-browsed logs
Impatto ed esposizione
Per garantire un'analisi accurata, abbiamo eseguito i test e osservato diversi modelli sui computer sia nel laboratorio controllato che su Internet. Questi modelli influiscono notevolmente sugli scenari degli attacchi e sui fattori di amplificazione.
Il team SIRT di Akamai ha esaminato e analizzato il traffico Internet globale alla ricerca dei dispositivi in cui è presente questa vulnerabilità e che sono accessibili sull'Internet pubblico (oltre 198.000 dispositivi), sulla base dei dati che ci ha fornito evilsocket. Da questi dati, abbiamo riscontrato che circa il 34% di questi dispositivi (oltre 58.000 dispositivi) era vulnerabile a questo attacco.
Inoltre, dai nostri test è emerso che alcuni di questi server CUPS attivi eseguono il beacon dei dati ripetutamente dopo la ricezione delle richieste iniziali, pertanto sembrano effettuare questa operazione incessantemente in seguito alle risposte HTTP/404. Centinaia di questi sistemi in rete hanno effettuato singolarmente migliaia di richieste e le hanno inviato ai nostri sistemi di test.
Questo fenomeno mostra come la potenziale amplificazione di questa vulnerabilità è notevole e potrebbe causare problemi significativi alle organizzazioni in cui vengono eseguiti i server interessati. Tramite i nostri test, abbiamo anche conformato che alcuni dei server CUPS vulnerabili sono stati in grado di completare gli handshake TLS (Transport Layer Security) dai nostri tentativi di probing contro siti web validi protetti dal protocollo HTTPS. La possibilità di influire sul TLS aggiunge ancora più carne al fuoco perché crea una maggiore pressione sulle risorse e sui dispositivi hardware del server a causa dell'handshake e dei processi di crittografia/decrittografia.
Le vecchie tecnologie colpiscono ancora
Dobbiamo notare che su molti computer identificati venivano eseguite versioni obsolete del sistema CUPS, come, ad esempio, la versione 1.3, che è stata rilasciata inizialmente nel 2007. Non è raro per alcune organizzazioni lasciare su alcuni computer versioni hardware e software obsolete ed è improbabile che questi dispositivi vengano aggiornati in breve tempo. Questa pratica rappresenta un'eccellente opportunità per i criminali, che possono trarre vantaggio dalle versioni hardware obsolete per amplificare gli attacchi DDoS o (considerando la vulnerabilità RCE in questo caso) costruire botnet per vari scopi, tra cui sferrare attacchi DDoS.
Stime degli attacchi di amplificazione
L'impatto degli attacchi di amplificazione può variare notevolmente, pertanto andremo a descrivere un caso di media gravità e un caso più grave per aiutare i lettori a valutare la potenziale minaccia.
In definitiva, la direttiva presa di mira stabilisce le dimensioni di questo payload, ma per i nostri calcoli di base useremo un pacchetto UDP minimo di 30 byte e un pacchetto UDP massimo di 1028 byte per il caso peggiore. Questo pacchetto utilizza la direttiva URI dell'IPP e la riempie con un valore di 989 byte (il valore massimo rilevato durante i nostri test), che viene duplicato e incluso nel traffico dell'attacco risultante.
Nel caso più grave, abbiamo osservato ciò che sembrava essere un flusso interminabile di tentativi di connessioni e richieste in risposta ad un solo probe. Questi flussi sembrano interminabili e continueranno finché il daemon non viene distrutto o riavviato. In tal caso, si potrebbe parlare di un'amplificazione infinita. Durante l'esecuzione dei test sugli oltre 58.000 ricevitori, poche centinaia di essi hanno mostrato questo modello.
Circa il 62% dei sistemi (oltre 35.900 dispositivi) ha inviato almeno 10 richieste TCP/IPP/HTTP al nostro sistema preso di mira in risposta alla ricezione del nostro pacchetto UDP. In totale, il numero medio di risposte degli oltre 58.000 ricevitori (inclusi quelli che hanno risposto incessantemente) è stato pari a 45, ossia il valore che useremo per calcolare ulteriormente il potenziale impatto degli attacchi di amplificazione.
Nel caso con il probe minimo (30 byte), notiamo che il computer preso di mira ha ricevuto una connessione TCP completa e due pacchetti con payload. Il primo pacchetto contiene la richiesta e le intestazioni HTTP, mentre il secondo contiene i dati POST per la richiesta (Figura 7).
Fig. 7: Minimal viable amplification flow
Questi pacchetti (226 byte e 174 byte) hanno raggiunto in totale i 400 byte. Supponendo di ricevere queste connessioni e richieste 45 volte per ogni riflettore CUPS, si arriva ad un traffico risultante di 18.000 byte per ogni probe di 30 byte o approssimativamente un fattore di amplificazione di 600 volte su un tentativo medio.
Una minore amplificazione non indica un impatto minore
Il caso peggiore presenta risultati diversi oltre alle dimensioni del pacchetto. Se eseguiamo lo stesso esercizio utilizzando payload UDP con il massimo padding di 1.028 byte (Figura 8), possiamo notare flussi molto più grandi che sono diretti verso il sistema preso di mira, ma con una minore amplificazione.
Fig. 8: Maximally padded attack payloads arriving at the target
In questo caso, il nostro payload con i due pacchetti viene comunque recapitato, ma le rispettive dimensioni dei pacchetti ora sono di 1.217 byte e 1.164 byte per un totale di 2.381 byte. Supponendo la stessa media di 45 risposte per riflettore, arriviamo ad un traffico totale di 107.000 byte per ogni probe di 1.028 byte, mentre la nostra amplificazione si riduce di 104 volte.
Anche se l'amplificazione diminuisce, la larghezza di banda utilizzata sulla rete presa di mira è quasi 6 volte maggiore rispetto al payload minimo. Di conseguenza, anche il server HTTP preso di mira deve allocare le risorse necessaria per gestire ed elaborare queste richieste, pertanto, anche se non migliora l'amplificazione, questo caso presenta un attacco più problematico (e realistico) per gli addetti alla sicurezza.
Valutare queste possibilità
Supponendo che tutti gli oltre 58.000 host CUPS identificati sono stati infettati nella stessa campagna, ne potrebbe risultare un traffico di attacchi in entrata pari ad un impressionante 1 GB per ogni pacchetto UDP nel caso minimo. Nel caso peggiore, potrebbe risultare un'ondata di traffico pari a 6 GB. Anche se queste cifre potrebbero non essere considerate molto elevate in termini di larghezza di banda, andrebbero comunque a creare la necessità per il sistema preso di mira di gestire circa 2,6 milioni di connessioni TCP e di richieste HTTP in entrambi i casi.
Opzioni DDoS nel sistema CUPS
Gli attacchi di questa natura sono parte della preoccupante tendenza che vede ostacolare sempre meno, da un punto di vista tecnico, l'accesso ai sistemi da parte dei criminali che intendono sferrare questi tipi di attacchi, in cui forzano i sistemi vulnerabili su Internet ad inviare enormi quantità di traffico alle loro vittime. A peggiorare le cose, i criminali possono raggiungere il loro obiettivo inviando un solo pacchetto ai servizi CUPS esposti su Internet, pertanto ad un criminale servirebbero solo pochi secondi per appropriarsi di ogni servizio CUPS vulnerabile attualmente visibile su Internet con una spesa inferiore ad un centesimo sulle moderne piattaforme hyperscaler.
Come ha evidenziato la ricerca di evilsocket, sono appena più di 198.000 i dispositivi individuati su Internet che rispondono ai probe UDP e il SIRT ha rilevato che circa il 34% di essi (oltre 58.000 dispositivi) hanno reagito al nostro probe UDP in un modo che poteva essere facilmente sfruttato per sferrare un attacco DDoS.
Un criminale remoto che utilizza un payload appositamente creato potrebbe sfruttare questa vulnerabilità per forzare il daemon cups-browsed a stabilire connessioni TCP in uscita verso una terza parte. Se nel suddetto sistema preso di mira viene eseguito un server HTTPS sulla porta attaccata, il server dovrà impiegare cicli e risorse a tentare di analizzare e gestire queste richieste e questi dati, il che potrebbe aumentare l'impatto dell'attacco. Nel caso delle CDN e del caching, è improbabile che gli URL specificati nella richiesta POST siano esistenti, il che determina un errore 404 che bypassa i riscontri nella cache e inoltra questi payload ai server di origine.
In base alla ricerca condotta da evilsocket, sono state interessate molte distribuzioni e versioni del sistema CUPS. In conclusione, la vulnerabilità risiede in "cups-browsed" incluso nel pacchetto con "cups-filters" quando si riceve la richiesta di aggiungere una stampante tramite UDP. Sembra che questa vulnerabilità venga mitigata in diverse distribuzioni Linux che associano cups-browsed a localhost o disattivano completamente cups-browsed dall'ascolto.
Mitigazione delle vulnerabilità del sistema CUPS
La decisione di aggiornare il sistema CUPS alla versione più recente o di rimuoverlo completamente dipende dalle specifiche esigenze del proprio computer. Se il sistema in uso dipende dalla funzionalità di stampa, l'aggiornamento all'ultima versione del sistema CUPS garantisce migliori livelli di sicurezza, performance e supporto per i moderni dispositivi. Tuttavia, se la funzionalità di stampa non è necessaria per la configurazione del proprio computer, la rimozione del sistema CUPS può consentire di semplificare l'utilizzo del proprio computer, ridurre potenziali vulnerabilità e risparmiare risorse.
In definitiva, questa decisione deve basarsi su quanto sia essenziale la funzionalità di stampa nel proprio ambiente e sull'importanza di mantenere il proprio computer aggiornato e sicuro. Se almeno la rimozione o l'aggiornamento del software CUPS non è praticabile, gli addetti alla sicurezza dovrebbero creare un firewall per le porte di servizio (UDP/631), specialmente se sono accessibili dall'Internet pubblico.
I criminali sono spesso rapidi a sfruttare le vulnerabilità appena segnalate e molti nuovi rilasci vengono sfruttati anche nel giro di una sola settimana dalla loro divulgazione iniziale. L'applicazione delle patch richiede tempo e gli hacker sono ben pronti a trarre vantaggio da questo periodo di transizione, che favorisce le vulnerabilità. Molte organizzazioni, inoltre, non si preoccupano di aggiornare alcuni dei loro programmi software più vecchi, il che potrebbe rendere particolarmente redditizio per gli hacker seguire la tendenza di esplorare nuove vulnerabilità come questa.
Mitigazione degli attacchi DDoS per le vittime
Per le vittime di un attacco DDoS sferrato dai sistemi CUPS vulnerabili, esistono alcune caratteristiche del traffico che possono aiutare a mettere in allerta, confermare ed eliminare il traffico degli attacchi sulla rete o sulle soluzioni WAF (Web Application Firewall).
Tutte le richieste che provengono dal servizio CUPS iniziano con POST /printers/ o POST /classes/ . Inoltre, mentre il payload dopo la stringa /printers/ può essere controllato dal criminale, lo stesso non vale per la parte iniziale del payload. Inoltre, le stringhe User-Agent del sistema CUPS contengono molte informazioni e utilizzano il formato CUPS/[VERSION], oltre a riferirsi all'IPP. Si tratta di stringhe UA univoche, che non vengono solitamente osservato nel traffico strutturato.
Esistono anche elementi statici nelle intestazioni HTTP e nei dati POST. L'intestazione Content-Type di application/ipp e printer-uri del payload nei dati POST sono valori statici che abbiamo identificato durante i nostri test (Figura 9).
Fig. 9: Highlighted values in observed traffic that could aid in detection and blocking
Per aiutare gli addetti alla sicurezza, abbiamo anche incluso una regola Snort che dovrebbe aiutare ad identificare questi flussi in entrata nella rete tramite socket in testo non crittografato (Figura 10).
alert http any any -> any any (msg:"CUPS Reflected DDoS IPP Request";
pcre:"/POST \/printers\/|POST \/classes\//"; http_method;
content:"Content-Type: application/ipp"; http_header;
content:"User-Agent: CUPS/"; http_header;
content:"printer-uri"; http_client_body;
metadata:service http;
reference:url,https://akamai.com/blog/security-research/2024/october-cups-ddos-threat;
sid:100004; rev:2;)
Figura 10. Regola Snort per il traffico degli attacchi nel sistema CUPS
Come abbiamo già detto, abbiamo rilevato alcuni sistemi sfruttati in rete che completano gli handshake HTTPS prima di inviare i loro payload HTTP, pertanto gli addetti alla sicurezza che utilizzano il protocollo HTTPS devono considerare la possibilità di implementare queste regole corrispondenti nelle configurazioni delle loro soluzioni WAF anziché sui loro sistemi di monitoraggio della rete.
Conclusione
I nuovi vettori di attacco DDoS vengono spesso individuati, e molto rapidamente sfruttati, da criminali anche poco esperti. Questa vulnerabilità presente nel sistema CUPS e la grande quantità di dispositivi che possono essere sfruttati in questo modo ci portano a ritenere che, probabilmente, gli addetti alla sicurezza potrebbero incorrere in attacchi basati sul sistema CUPS.
Finché la messaggistica e le operazioni di pulizia non si diffonderanno in modo da ridurre il numero dei dispositivi vulnerabili ed esposti a Internet (attualmente, oltre 58.000 dispositivi), sospettiamo che questo vettore verrà sfruttato in rete. La nostra speranza è che addetti alla sicurezza, gestori di reti e amministratori di sistemi si occupino di questa questione e, per il bene di tutti, riescano a gestire rapidamente le rispettive vulnerabilità o, almeno, a prepararsi per identificare e respingere i criminali che potrebbero sfruttare queste vulnerabilità in futuro.
Desideriamo ringraziare evilsocket (Simone Margaritelli) per la sua preziosa assistenza e il suo impagabile contributo. ♥️
