Cuando hay demasiados CUPS: la amenaza de los ataques DDoS
Comentario editorial y adicional de Tricia Howard
Resumen ejecutivo
Los investigadores de Akamai han confirmado un nuevo vector de ataque mediante CUPS que podría explotarse para llevar a cabo ataques distribuidos de denegación de servicio (DDoS). (CVE-2024-47850)
La investigación demuestra que, para iniciar el ataque, el sistema atacante solo necesita enviar un paquete a un servicio CUPS vulnerable y expuesto con conexión a Internet.
El equipo de respuesta a incidentes e inteligencia en seguridad de Akamai (SIRT, por sus siglas en inglés) descubrió que existen más de 198 000 dispositivos vulnerables a este vector de ataque y que se puede acceder a ellos a través de la red pública de Internet; aproximadamente el 34 % de estos dispositivos podría utilizarse para realizar ataques de DDoS (más de 58 000).
Entre los más de 58 000 dispositivos vulnerables, cientos de ellos mostraban un "bucle infinito" de solicitudes.
Los limitados recursos necesarios para iniciar un ataque con éxito ponen de manifiesto el peligro: un atacante tardaría tan solo unos segundos en adueñarse de todos los servicios de CUPS vulnerables actualmente expuestos en Internet y le costaría tan solo un céntimo de dólar en plataformas de hiperescala modernas.
Las CVE
El 26 de septiembre de 2024, el investigador de seguridad evilsocket reveló vulnerabilidades de ejecución remota de código (RCE) en el sistema de impresión común de Unix (CUPS). En resumen, un atacante podría manipular las URL del protocolo de impresión de Internet (IPP) de forma remota para ejecutar comandos maliciosos. Para lograrlo, deben encadenarse cuatro vulnerabilidades diferentes.
CVE-2024-47176 en cups-browsed, que convierte una solicitud en una dirección controlada por el atacante
CVE-2024-47076 en libcupsfilters, que no valida ni sanea los datos devueltos desde el servidor del atacante y los pasa al resto del sistema CUPS
CVE-2024-47175 en libppdque, una vez más, no sanea los datos entrantes, y los escribe en un archivo temporal
CVE-2024-47177 en cups-filters, que permite la ejecución de un comando arbitrario
Información adicional sobre el caso de CUPS
Al revisar el informe técnico sobre las vulnerabilidades, descubrimos que no se había hablado de otro vector de ataque: DDoS. Los ataques DDoS siguen siendo un vector de ataque viable que se utiliza para acosar y molestar a las víctimas en Internet, desde los principales sectores y gobiernos hasta pequeños creadores de contenido, tiendas online y jugadores. Aunque el análisis original se centró en la vulnerabilidad de RCE, que podría tener un resultado más grave, en este caso también podría explotarse fácilmente la amplificación de DDoS.
El problema surge cuando el atacante envía un paquete especialmente diseñado en el que se especifica la dirección de un objetivo como impresora que se quiere agregar. Por cada paquete enviado, el servidor CUPS vulnerable generará una solicitud IPP/HTTP más grande y parcialmente controlada por el atacante dirigida al objetivo especificado. Como resultado, no solo se ve afectado el objetivo, sino que el host del servidor CUPS también se convierte en víctima, ya que el ataque consume el ancho de banda de la red y los recursos de la CPU.
Explotación
Basta una sencilla secuencia de comandos para enviar el paquete UDP malicioso a una instancia vulnerable de CUPS. La carga especialmente diseñada indica a CUPS que envíe una solicitud IPP/HTTP al objetivo y al puerto especificados por el atacante. La vulnerabilidad aparece cuando cups-browsed intenta obtener el URI especificado para descargar el archivo de atributos IPP.
Este URI de archivo PPD es algo arbitrario y el atacante puede modificarlo. Durante las pruebas, descubrimos que esta carga de URI se puede rellenar hasta un tamaño máximo de 989 bytes. Este relleno se incluirá dos veces en la solicitud IPP/HTTP: una en los encabezados HTTP y otra en los datos POST que se dirigirán al sistema objetivo.
Mediante esta técnica de relleno, los atacantes podrían agravar aún más el impacto de los ataques DDoS compatibles con CUPS al consumir ancho de banda y recursos adicionales en las redes y los sistemas objetivo. En la figura 1 puede ver una representación virtual de este proceso.
Fig. 1: Network diagram of attack flow
Sistema de ataque
Uno de los aspectos más preocupantes de esta amenaza es la cantidad tan reducida de recursos que necesita el atacante para ejecutarla. Las figuras 2 y 3 muestran cómo el sistema atacante solo necesita enviar un paquete a un servicio CUPS vulnerable y expuesto con conexión a Internet para que el sistema que ejecuta CUPS inicie el ataque.
./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
Fig. 2: puesta en escena de la explotación
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
Fig. 3: paquete UDP saliente (modificado para que sea una carga útil no funcional)
Sistema objetivo
El resultado es un servicio de CUPS que intenta recuperar lo que cree que es un archivo de atributos IPP, pero que, en realidad, contiene las especificaciones del atacante. El objetivo especificado en el paquete UDP comenzará a recibir conexiones TCP entrantes del sistema que ejecuta CUPS (Figura 4).
Fig. 4: CUPS service establishing a connection to the target
Si observamos más de cerca los dos paquetes recibidos que contenían los datos de la solicitud real, podemos ver la solicitud IPP sin procesar y los datos POST adjuntos, parcialmente controlados por el atacante, procedentes del servicio CUPS (Figura 5).
Fig. 5: IPP/HTTP request received by the target
En los registros del daemon cups-browsed, podemos ver que los intentos de obtener los atributos IPP son, en última instancia, lo que genera estas solicitudes dirigidas al host de destino (Figura 6).
Fig. 6: Cups-browsed logs
Impacto y exposición
Para garantizar un análisis completo, hemos probado y observado diferentes patrones de máquinas, tanto en un laboratorio controlado como en Internet. Estos patrones afectan en gran medida a las situaciones de ataque y a los factores de amplificación.
El SIRT de Akamai exploró y analizó Internet en busca de dispositivos vulnerables a este defecto y accesibles a través de una conexión pública a Internet (más de 198 000), en función de los datos que proporcionó evilsocket. Basándonos en esos datos, descubrimos que aproximadamente el 34 % de esos dispositivos (más de 58 000) eran vulnerables a este ataque.
Además, nuestras pruebas revelaron que algunos de estos servidores CUPS activos volverán a emitir señales repetidamente después de recibir las solicitudes iniciales, y algunos parecerán hacerlo sin fin ante las respuestas HTTP/404. Cientos de estos sistemas establecieron individualmente miles de solicitudes y las enviaron a nuestros sistemas de pruebas.
Esto demuestra que la amplificación potencial de esta vulnerabilidad es bastante grande y podría causar problemas importantes para las organizaciones que ejecutan los servidores afectados. Nuestras pruebas también confirmaron que algunos de los servidores CUPS vulnerables pudieron completar los protocolos de seguridad de la capa de transporte (TLS) de nuestros intentos de sondeo en sitios web HTTPS protegidos válidos. El hecho de que estos ataques puedan afectar el protocolo TLS añade más leña al fuego, ya que crea una mayor presión sobre el hardware del servidor y la sobrecarga de consumo de recursos debido al protocolo de enlace y al procesamiento de cifrado/descifrado.
La tecnología obsoleta vuelve al ataque
Es importante tener en cuenta que muchas de las máquinas identificadas se ejecutaban en versiones muy antiguas de CUPS, como la versión 1.3, que se lanzó inicialmente en 2007. No es nada raro que algunas organizaciones dejen máquinas funcionando con hardware y software extremadamente anticuados, y es poco probable que dichos dispositivos se actualicen pronto. Esto ofrece a los atacantes malintencionados una gran oportunidad, ya que pueden aprovechar el hardware antiguo para la amplificación de DDoS o, dada la RCE de este caso, construir botnets con diferentes fines, como lanzar ataques DDoS.
Estimaciones de amplificación
Las tasas de amplificación pueden variar significativamente, por lo que hemos cubierto tanto una situación media como la peor situación posible para ayudar a los lectores a evaluar la amenaza potencial.
Aunque la directiva de destino dicta el tamaño de la carga en última instancia, para los cálculos base utilizaremos un tamaño de paquete UDP mínimo viable de 30 bytes y un paquete UDP de 1028 bytes con relleno máximo para el peor de los casos. Este paquete utiliza la directiva IPP URI y la llena con 989 bytes (el máximo encontrado durante la prueba), que se duplica y se incluye en el tráfico de ataque resultante.
En la peor situación posible, observamos lo que parecía ser un flujo interminable de intentos de conexión y solicitudes como resultado de un único sondeo. Estos flujos parecen no tener fin, y continuarán hasta que se detenga o reinicie el daemon. En esta situación, podríamos hablar de amplificación infinita. Durante la prueba de los más de 58 000 transmisores, varios centenares presentaban este patrón.
Alrededor del 62 % (más de 35 900) de los sistemas enviaron al menos 10 solicitudes TCP/IPP/HTTP a nuestro sistema de destino en respuesta a nuestro paquete UDP. En general, la tasa media de respuesta entre los más de 58 000 transmisores (incluidos los transmisores infinitos con alcance temporal) fue de 45 respuestas, que es lo que utilizaremos para calcular las tasas de amplificación potencial.
En la situación de sondeo viable mínimo (30 bytes), observamos que la máquina de destino recibió una conexión TCP completa y dos paquetes con cargas. El primer paquete contiene la solicitud HTTP y los encabezados; el segundo contiene los datos POST de la solicitud (Figura 7).
Fig. 7: Minimal viable amplification flow
Estos paquetes (226 bytes y 174 bytes) suman un total de 400 bytes. Si damos por hecho que obtendremos estas conexiones y solicitudes 45 veces por reflector CUPS, esto equivale a 18 000 bytes de tráfico resultante por cada sonda de 30 bytes, o aproximadamente un factor de amplificación 600 veces mayor en un intento medio .
Una menor amplificación no significa un menor impacto
El peor de los casos ofrece resultados diferentes fuera del tamaño del paquete. Si realizamos este mismo ejercicio con cargas UDP con relleno máximo de 1028 bytes (Figura 8), se observan flujos mucho más grandes dirigidos al objetivo, pero una amplificación menor.
Fig. 8: Maximally padded attack payloads arriving at the target
En esta situación, sigue llegando nuestra carga de dos paquetes, pero el tamaño es ahora de 1217 bytes y 1 164 bytes respectivamente, lo que equivale a un total de 2381 bytes. Suponiendo que sigue produciéndose una media de 45 respuestas por reflector, obtenemos un total de 107 000 bytes de tráfico por sonda de 1028 bytes, y la tasa de amplificación se reduce a 104 veces mayor.
Aunque la velocidad de amplificación ha disminuido, el ancho de banda consumido en la red de destino es casi 6 veces superior a la carga mínima viable. Esta situación obligaría al servidor HTTP objetivo a asignar recursos para gestionar y procesar las solicitudes. Por lo tanto, aunque no mejora las tasas de amplificación, esta situación presenta un ataque más problemático (y realista) para los defensores.
Ampliar las posibilidades
Si se utilizasen los más de 58 000 hosts de CUPS identificados en la misma campaña, podría producirse una avalancha de 1 GB de tráfico de ataque entrante por paquete UDP en el ejemplo con relleno mínimo. En el ejemplo con relleno máximo, podría alcanzarse un enorme volumen de tráfico de 6 GB. Aunque estas cifras de ancho de banda no son demoledoras, seguirían obligando al destino a gestionar aproximadamente 2,6 millones de conexiones TCP y solicitudes HTTP en cualquiera de los dos ejemplos.
Opciones de DDoS en CUPS
Los ataques de esta naturaleza forman parte de la preocupante reducción de la barrera técnica necesaria para que los atacantes puedan enviar flujos continuos de tráfico a las víctimas a través de sistemas vulnerables en Internet. Y lo que es todavía peor, es posible lograrlo mediante el envío de un solo paquete a los servicios CUPS expuestos a Internet. un atacante tardaría tan solo unos segundos en adueñarse de todos los servicios de CUPS vulnerables actualmente expuestos en Internet y le costaría tan solo un céntimo de dólar en plataformas de hiperescala modernas.
Como señaló la investigación de evilsocket, se han encontrado más de 198 000 dispositivos en Internet que responden a las sondas UDP. Además, de acuerdo con la investigación del equipo de SIRT, aproximadamente el 34 % (más de 58 000) de estos dispositivos reaccionó a una sonda UDP de una forma que podría explotarse para realizar ataques DDoS.
Un atacante remoto que utilice una carga útil especialmente diseñada podría aprovechar esta vulnerabilidad para hacer que el daemon cups-browsed realice conexiones TCP salientes a un tercero. Si este destino ejecuta un servidor HTTPS en el puerto objetivo, el servidor tendrá que dedicar ciclos y recursos a analizar y gestionar estas solicitudes y datos, lo que podría hacer que el ataque tuviera un impacto aún mayor. En el caso de las CDN y el almacenamiento en caché, es poco probable que existan las URL especificadas en la solicitud POST, lo que da lugar a un error 404 que omite los aciertos de caché y reenvía las cargas a los servidores de origen.
Según la investigación realizada por evilsocket, se han visto afectadas muchas distribuciones y versiones de CUPS. En última instancia, la vulnerabilidad reside en "cups-browsed" empaquetado con "cups-filters" cuando se recibe una solicitud para añadir una impresora a través de UDP. Parece que existen mitigaciones para varias distribuciones de Linux que vinculan cups-browsed a localhost o desactivan cups-browsed para que no escuche nada en absoluto.
Mitigación de las vulnerabilidades de CUPS
La decisión de actualizar a la última versión de CUPS o de eliminarla depende completamente de las necesidades específicas del sistema. Si su sistema depende de la funcionalidad de impresión, actualizar a la versión más reciente de CUPS garantiza una seguridad, un rendimiento y una compatibilidad mejorados para los dispositivos modernos. No obstante, si la impresión no es necesaria para la configuración, eliminar CUPS podría simplificar el sistema, reducir las posibles vulnerabilidades y ahorrar recursos.
En última instancia, la decisión debe basarse en lo esenciales que son las capacidades de impresión para su entorno y en la importancia de mantener un sistema actualizado y seguro. Como mínimo, si no es viable eliminar o actualizar el software de CUPS, los defensores deben proteger los puertos de servicio (UDP/631) con un firewall, especialmente si puede accederse a ellos desde Internet.
Los atacantes suelen aprovechar rápidamente las vulnerabilidades recién anunciadas, y muchas de las nuevas versiones se explotan en los siete días posteriores a la divulgación inicial. La aplicación de parches lleva tiempo, por lo que los hackers desean aprovechar ese periodo de transición vulnerable. Además, muchas organizaciones no suelen actualizan parte de su software antiguo, por lo que aprovechar las nuevas vulnerabilidades resulta especialmente lucrativo para los hackers.
Mitigación de DDoS para las víctimas
Para las víctimas de un ataque DDoS lanzado desde sistemas vulnerables de CUPS, existen varias características del tráfico que ayudan a alertar, confirmar y descartar el tráfico de ataques en la red o en el firewall de aplicaciones web (WAF).
Todas las solicitudes procedentes del servicio CUPS comienzan por POST /printers/ o POST /classes/ y, aunque la carga que aparece después de /printers/ la puede controlar el atacante, no sucede lo mismo con la parte inicial de la carga. Además, las cadenas User-Agent de CUPS son muy informativas y utilizan el formato CUPS/[VERSIÓN], así como una referencia a IPP. Estas son cadenas muy particulares en UA y no se observan normalmente en el tráfico orgánico.
También hay elementos estáticos en los encabezados HTTP y en los datos POST. El encabezado Content-Type de application/ipp y la carga de printer-uri en los datos POST son valores estáticos que identificamos durante la prueba (Figura 9).
Fig. 9: Highlighted values in observed traffic that could aid in detection and blocking
Para ayudar a los defensores, también hemos incluido una regla Snort que debería ayudar a identificar estos flujos que entran en la red a través de sockets de texto sin formato (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;)
Fig. 10: regla de Snort para tráfico de ataque CUPS
Como ya hemos mencionado, hemos encontrado sistemas que completarían los protocolos HTTPS antes de distribuir sus cargas HTTP, por lo que los defensores que utilizan HTTPS deberían plantearse implementar estas reglas de coincidencia en sus configuraciones de firewall de aplicaciones web (WAF) en lugar de en sus sistemas de supervisión de red.
Conclusión
A veces, algunos atacantes oportunistas poco cualificados identifican nuevos vectores de ataque DDoS y, con frecuencia, abusan rápidamente de ellos. Esta vulnerabilidad en CUPS y la gran cantidad de dispositivos que podrían ser explotados de esta manera nos hacen pensar que es muy probable que los defensores lleguen a encontrarse con ataques basados en CUPS.
Hasta que las estrategias de comunicación y limpieza se hagan efectivos para reducir el número de dispositivos vulnerables y expuestos en Internet (actualmente más de 58 000), sospechamos que este vector sufrirá ataques en su estado actual. Esperamos que los defensores, los operadores de red y los administradores de sistemas reciban el mensaje y, por el bien de todos, gestionen sus exposiciones rápidamente o, al menos, estén preparados para identificar y defenderse de los atacantes que puedan aprovechar las exposiciones en el futuro.
También queremos dar las gracias a evilsocket (Simone Margaritelli) por su valiosa ayuda y aportación. ♥️