¿Necesita Cloud Computing? Empiece ahora

RCE crítico de Linux en CUPS: lo que sabemos y cómo prepararnos

Onda azul de Akamai

escrito por

Akamai Security Intelligence Group

September 27, 2024

El 26 de septiembre de 2024 se dio a conocer una cadena crítica de vulnerabilidades de ejecución remota de código que podría afectar a muchos hosts de tipo Unix.
El 26 de septiembre de 2024 se dio a conocer una cadena crítica de vulnerabilidades de ejecución remota de código que podría afectar a muchos hosts de tipo Unix.

Resumen ejecutivo

  • Una cadena crítica de vulnerabilidades de ejecución remota de código (RCE) que podría afectar a muchos hosts de tipo Unix se reveló el 26 de septiembre de 2024.

  • El componente vulnerable es el sistema de impresión común de Unix (CUPS), en concreto cups-browsed.

  • La explotación satisfactoria de este componente requiere una cadena de cuatro vulnerabilidades: CVE-2024-47176, CVE-2024-47076, CVE-2024-47175 y CVE-2024-47177.

  • En esta entrada del blog, Akamai comparte detalles sobre la vulnerabilidad, analiza la divulgación técnica y ofrece recomendaciones sobre lo que se puede hacer para prepararse y mitigar de forma eficaz los riesgos mientras se publica el parche.

Introducción

El 23 de septiembre de 2024, el investigador de seguridad Simone Margaritelli compartió detalles en las redes sociales sobre una próxima divulgación de vulnerabilidades. En su publicación, Margaritelli describió una vulnerabilidad crítica que ya había comunicado a los desarrolladores tres semanas antes: una vulnerabilidad de RCE no autenticada que podría afectar potencialmente a todas las máquinas GNU/Linux.

El 26 de septiembre de 2024, se publicó una divulgación técnica completa. Hay un total de cuatro vulnerabilidades:

  1. CVE-2024-47176 en cups-browsed, que convierte una solicitud en una dirección controlada por el atacante

  2. 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

  3. CVE-2024-47175 en libppdque, una vez más, no sanea los datos entrantes, y los escribe en un archivo temporal

  4. CVE-2024-47177 en cups-filters, que permite la ejecución de un comando arbitrario

Con esta entrada del blog, nuestro objetivo es ayudar a las organizaciones a prepararse para que el proceso de corrección sea lo más fluido posible. Para ello, ofrecemos un resumen técnico de la cadena de explotación y algunos pasos de mitigación (en forma de recomendaciones de segmentación) que los administradores de red pueden emplear mientras se publica el parche.

¿Cómo puede prepararse?

Para que un atacante pueda aprovechar una vulnerabilidad de RCE, son necesarias dos cosas: un software con una parte vulnerable y, por supuesto, acceso remoto. Como sabemos que el componente vulnerable es CUPS, podemos implementar un parche (cuando esté disponible) o poner en marcha algunos pasos de mitigación específicos para ese componente. Por nuestra parte, creemos que la mejor forma de actuar es aprovechar esta oportunidad para abordar el acceso remoto de forma más amplia.

No obstante, vamos a empezar por el asunto más urgente.

Exposiciones de CUPS y explotaciones potenciales

El componente vulnerable del que vamos a hablar es CUPS, que es un servicio que permite a un equipo informático actuar como servidor de impresión. Es muy popular y se encuentra en una amplia variedad de máquinas tipo Unix.

Este servicio es muy común y, sin duda, es un objetivo de gran valor para su vulneración, ya que, por naturaleza, suele estar expuesto a otras máquinas y, potencialmente, a Internet. Las vulnerabilidades anteriores en los servicios de impresión, como CVE-2021-34527 (PrintNightmare) o incluso CVE-2010-2729, han demostrado el impacto potencial de este vector de ataque.

Incluso antes de la revelación "oficial", teorizamos que CUPS era el componente vulnerable. Al inspeccionar la cuenta de GitHub de Margaritelli, encontramos un detalle interesante: una bifurcación del repositorio de Apple CUPS del 17 de septiembre de 2024, unos días antes de su primera publicación (Figura 1).

Al inspeccionar la cuenta de GitHub de Margaritelli, encontramos un detalle interesante: una bifurcación del repositorio de Apple CUPS del 17 de septiembre de 2024, unos días antes de su primera publicación (Figura 1). Fig. 1: Una bifurcación del repositorio de Apple CUPS, realizada por Margaritelli una semana antes de su publicación sobre la vulnerabilidad

También hay un problema en el cups-browsed de GitHub que cita a Margaritelli (@evilsocket) sobre lo que probablemente sea un efecto secundario de la vulnerabilidad principal. (Encontrará comentarios de todo tipo, así que no se olvide las palomitas )

Análisis de la explotación

El ataque no es especialmente complejo, pero sí requiere varios pasos para que se pueda explotar correctamente. La figura 2 muestra un resumen del proceso, aunque nos gustaría invitarle a leer el blog de divulgación completo para obtener una explicación más detallada.

El ataque no es especialmente complejo, pero sí requiere varios pasos para que se pueda explotar correctamente. La figura 2 muestra un resumen del proceso, aunque nos gustaría invitarle a leer el blog de divulgación completo para obtener una explicación más detallada. Fig. 2: Cadena de ataques satisfactoria

Paso 1: en primer lugar, el daemon cups-browsed escucha las conexiones UDP entrantes a través del puerto 631. Su objetivo es añadir las impresoras detectadas al sistema. El atacante que se comunique con el daemon puede forzar a la máquina objetivo a registrar una dirección maliciosa como impresora legítima, es decir, CVE-2024-47176.

Paso 2: el siguiente paso se da cuando se registra la "impresora" maliciosa. Como parte del proceso de registro, libcupsfilters enviará una solicitud saliente al atacante para pedirle los atributos de la impresora a través del protocolo de impresión por Internet (IPP). Como parte de esos atributos, las impresoras pueden definir archivos de descripción de impresora PostScript (PPD) específicos que, cuando se utilizan legítimamente, definen las capacidades de la impresora. A continuación, se escriben en un archivo .ppd, sin saneamiento ni restricciones. Es decir, CVE-2024-47076 y CVE-2024-47175.

Ya tenemos un archivo .ppd malicioso. Pero, ¿cómo lo usamos para ejecutar los comandos?

Paso 3: introduzca la directiva cupsFilter2 en el PPD, que ejecuta varios filtros (archivos ejecutables) cada vez que se crea un nuevo trabajo de impresión. Utilizamos esta directiva para ejecutar el filtro foomatic-rip , que es vulnerable a una inyección de comandos arbitraria. Esto es CVE-2024-47177.

Un análisis más detallado

Con Shodan, pudimos ver que aproximadamente 75 000 máquinas en todo el mundo exponen CUPS a Internet, en la mayoría de los casos mediante el puerto 631 predeterminado (Figura 3).

Con Shodan, pudimos ver que aproximadamente 75 000 máquinas de todo el mundo exponen CUPS a Internet, en la mayoría de los casos mediante el puerto 631 predeterminado (Figura 3). Fig. 3: Aproximadamente 75 000 máquinas en todo el mundo exponen CUPS a Internet

Puede usarse el siguiente filtro para buscar servidores CUPS expuestos en Shodan:

  product:"CUPS (IPP)"

Información adicional

Gracias a la información exclusiva de Akamai sobre los datos de tráfico, observamos que el servicio CUPS se ejecutaba en una amplia gama de plataformas, como Ubuntu, macOS, CentOS, Debian, Fedora, OpenShift, Oracle Linux Server, Red Hat, Rocky Linux, SUSE, openSUSE, AlmaLinux o Amazon Linux, entre otras.

El 10,1 % de las máquinas Linux del ecosistema de Akamai tienen el puerto 631 (el puerto CUPS) abierto. No obstante, solo el 3 % de ellas recibe regularmente tráfico externo en este puerto.

Aunque estas cifras parecen indicar que el servicio no suele estar expuesto externamente, es importante que las organizaciones evalúen su propia exposición y revisen sus políticas de seguridad en consecuencia.

Análisis de la exposición a Internet

Uno de los métodos más comunes que emplean los atacantes para vulnerar las organizaciones es el uso de servicios expuestos a Internet. CUPS es solo un ejemplo de este tipo de servicio, pero el problema no termina aquí. Gracias una vez más a la información de Akamai sobre los datos de tráfico, evaluamos el estado de exposición de diferentes servicios en miles de organizaciones.

Según los datos de Akamai, aproximadamente el 5,4 % de las máquinas Linux están expuestas a Internet y reciben tráfico entrante de fuentes externas (figura 4).

Exposición a Internet de máquinas Linux Fig. 4: Exposición a Internet de máquinas Linux

Al analizar las políticas de red que afectan a este tipo de tráfico, observamos que el 19,3 % de estas máquinas permiten el tráfico entrante de Internet de forma predeterminada , lo que significa que no existen políticas de red específicas para restringir o controlar el flujo de tráfico entrante.

Puesto que los servicios expuestos pueden convertirse fácilmente en un vector de ataque, es fundamental que las organizaciones revisen y refuercen sus controles de acceso.

Recomendaciones

Como la vulnerabilidad todavía no es pública y no hay ninguna línea de tiempo para la publicación de un parche, la mejor manera de prepararse para su divulgación es identificar todos los puntos de "fricción" de la red, ya sea una lista con todas las máquinas Linux, su exposición a Internet o incluso el uso de CUPS, y las políticas de segmentación relacionadas con ellas.

Después, le recomendamos aplicar políticas de segmentación para limitar la propagación de cualquier ataque potencial. El uso de este tipo de políticas es una buena idea independientemente de la situación actual, ya que el movimiento lateral de Linux no se limita únicamente a SSH o RCE.

Identifique el uso de CUPS en su organización

Para identificar los CUPS que se ejecuten en sus máquinas, puede buscar los nombres de los servicios y los procesos. Basándonos en nuestras observaciones, que abarcan diferentes sistemas y distribuciones Unix, los siguientes procesos podrían indicar el uso de CUPS:

  • cups-browsed (el proceso afectado).

  • cupsd

  • cancel.cups

  • lpq.cups

  • cupsfilter

  • lpc.cups

  • lp.cups

  • cupsaccept

  • cups-lpd

  • lpstat.cups

  • lpr.cups

  • cupsctl

Las organizaciones que implementan osquery pueden utilizar las siguientes consultas para identificar el uso potencial de CUPS en sus sistemas (los clientes de Akamai Guardicore Segmentation pueden ejecutar estas consultas mediante la función Insight).

Detectar equipos que escuchan en el puerto 631:

  SELECT pid, port, protocol, family, address, path 
  FROM listening_ports
  WHERE port = 631

Detectar procesos en ejecución que podrían estar relacionados con CUPS:

  SELECT name, parent, cwd, cmdline, pid, start_time, path
  FROM processes
  WHERE path LIKE '%cups%'

Identifique la exposición a Internet

Puede utilizar servicios de análisis de exposición, como Shodan, para identificar los servicios expuestos a Internet, incluido CUPS.

Los clientes de Akamai Guardicore Segmentation pueden utilizar el filtro Conexión a Internet de la pestaña Mostrar para visualizar todos los servicios y máquinas que reciben tráfico de Internet (Figura 5).

Los clientes de Akamai Guardicore Segmentation pueden utilizar el filtro Conexión a Internet de la pestaña Mostrar para visualizar todos los servicios y máquinas que reciben tráfico de Internet (Figura 5). Fig. 5: El filtro Conexión a Internet muestra todos los servicios y máquinas que reciben tráfico de Internet

Utilice la segmentación para limitar el alcance potencial

Imagine la siguiente situación: se da a conocer la vulnerabilidad y no es lo que esperaba ni para lo que se había preparado, alguien crea una vulneración que funcione y un atacante malintencionado la utiliza para acceder a su red.

¿Qué sucede después? ¿Puede acceder al controlador de dominio, infectar toda la red, instalar su botnet/malware de criptominería/ransomware/troyano y salir sin que se le detecte? ¿O tendrá que esforzarse más, realizar análisis de reconocimiento complejos, dar varios saltos de movimiento lateral y ser más proactivo en general, lo que le ofrecería a usted el tiempo suficiente para detectar la vulnerabilidad y reaccionar?

Las vulneraciones están a la orden del día y, por eso, la segmentación es tan importante. Si no es un RCE hoy, será un ataque de día cero mañana. Las redes planas son objetivos fáciles. Por eso, si se lo ponemos difícil al atacante, podemos lograr que desista (y busque otro objetivo) u obligarle a dedicar el tiempo y esfuerzo suficientes para que cometa un error y pueda ser detectado.

Mejore su estrategia de seguridad en 2 pasos

Puede mejorar su estrategia de seguridad en gran medida con dos pasos relativamente sencillos: implementar una DMZ y segmentar los servidores de aplicaciones.

  1. Implementar una DMZ. Los servidores abiertos a Internet están inherentemente expuestos a un mayor riesgo; por lo tanto, no deberían tener acceso completo al resto de la red. Implementar una DMZ perimetral que garantice que los servidores no puedan acceder a las partes más sensibles de la red le hace la vida mucho más difícil a cualquier atacante.

  2. Segmentar los servidores de aplicaciones. En general, es posible segmentar servidores de aplicaciones similares entre sí y, en función de su lógica de aplicación, puede restringir fácilmente el tráfico entrante y saliente.

Utilicemos el servidor CUPS a modo de ejemplo: conocemos su puerto (UDP 631), su proceso (cupsd) y que, técnicamente, solo necesita generar tráfico hacia las propias impresoras. Con esta información, podemos crear un segmento de aplicación para esos servidores CUPS que permita la entrada de tráfico específico e impida la entrada del resto.

De esta forma, cualquier atacante que aproveche CUPS para vulnerar el servidor solo podrá conectarse a la impresora, y un trabajo de impresión falso no es tan aterrador.

Más información

Existen también otras soluciones rápidas que pueden aplicar las organizaciones a través de la segmentación para mejorar su estrategia de seguridad. Puede obtener más información en nuestra entrada del blog sobre segmentación práctica.



Onda azul de Akamai

escrito por

Akamai Security Intelligence Group

September 27, 2024