- Equipo de investigación de Microsoft 365 Defender
Microsoft ha descubierto varias vulnerabilidades, denominadas colectivamente Nimbuspwn, que podrían permitir a un atacante elevar los privilegios a root en muchos puntos finales de escritorio de Linux. Las vulnerabilidades se pueden encadenar para obtener privilegios de raíz en los sistemas Linux, lo que permite a los atacantes implementar cargas útiles, como una puerta trasera raíz, y realizar otras acciones maliciosas a través de la ejecución arbitraria de código raíz. Además, las vulnerabilidades de Nimbuspwn podrían aprovecharse potencialmente como un vector para el acceso a la raíz por parte de amenazas más sofisticadas, como malware o ransomware, para lograr un mayor impacto en los dispositivos vulnerables.
Descubrimos las vulnerabilidades al escuchar mensajes en System Bus mientras realizamos revisiones de código y análisis dinámicos en servicios que se ejecutan como raíz, notando un patrón extraño en una unidad systemd llamada networkd-dispatcher . La revisión del flujo de código para networkd-dispatcher reveló múltiples problemas de seguridad, incluidos el cruce de directorios, la carrera de enlaces simbólicos y los problemas de condición de carrera de hora de verificación y hora de uso, que podrían aprovecharse para elevar los privilegios e implementar malware o llevar a cabo otras actividades maliciosas. Compartimos estas vulnerabilidades con los mantenedores relevantes a través Divulgación coordinada de vulnerabilidades (CVD) a través de Microsoft Security Vulnerability Research (MSVR). Las correcciones para estas vulnerabilidades, ahora identificadas como CVE-2022-29799 y CVE-2022-29800 , han sido implementadas con éxito por el mantenedor de networkd-dispatcher, Clayton Craft. Deseamos agradecer a Clayton por su profesionalismo y colaboración para resolver estos problemas. Se recomienda a los usuarios de networkd-dispatcher que actualicen sus instancias.
A medida que los entornos organizacionales continúan dependiendo de una amplia gama de dispositivos y sistemas, requieren soluciones integrales que brinden protección multiplataforma y una visión holística de su postura de seguridad para mitigar las amenazas, como Nimbuspwn. El creciente número de vulnerabilidades en los entornos Linux enfatiza la necesidad de una fuerte supervisión del sistema operativo de la plataforma y sus componentes. Microsoft Defender para Endpoint permite a las organizaciones obtener esta visibilidad necesaria y detectar dichas amenazas en dispositivos Linux , lo que les permite detectar, administrar, responder y remediar vulnerabilidades y amenazas en diferentes plataformas, incluidas Windows, Linux, Mac, iOS y Android.
En esta publicación de blog, compartiremos información sobre los componentes afectados y examinaremos las vulnerabilidades que descubrimos. Al detallar cómo nuestra visibilidad entre dominios nos ayuda a descubrir amenazas nuevas y desconocidas para mejorar continuamente la seguridad, también compartimos detalles de nuestra investigación con la comunidad de seguridad en general para subrayar la importancia de proteger las plataformas y los dispositivos.
Antecedentes – D-Bus
D-Bus (abreviatura de “Desktop-Bus”) es un mecanismo de canal de comunicación entre procesos (IPC) desarrollado por el freedesktop.org . D-Bus es un bus de software y permite que los procesos en el mismo punto final se comuniquen transmitiendo mensajes y respondiendo a ellos. D-Bus admite dos formas principales de comunicación:
- Métodos: se utiliza para las comunicaciones de solicitud y respuesta.
- Señales: se utilizan para comunicaciones de publicación/suscripción.
Un ejemplo del uso de D-Bus sería recibir un chat de video de una aplicación de videoconferencia popular: una vez que se establece un video, la aplicación de videoconferencia podría enviar una señal de D-bus publicando que se inició una llamada. Las aplicaciones que escuchan ese mensaje podrían responder adecuadamente: por ejemplo, silenciar su audio.
Hay muchos componentes de D-Bus enviados de forma predeterminada en los entornos de escritorio Linux más populares. Dado que esos componentes se ejecutan con diferentes privilegios y responden a los mensajes, los componentes de D-Bus son un objetivo atractivo para los atacantes. De hecho, ha habido vulnerabilidades interesantes en el pasado relacionadas con los servicios defectuosos de D-Bus, incluidos USBCreator Elevation of Privilege , Blueman Elevation of Privilege by command injection y otros escenarios similares.
D-Bus expone un sistema y un bus de sesión por sesión . Desde la perspectiva de un atacante, el System Bus es más atractivo ya que normalmente tendrá servicios que se ejecutan como root escuchándolo.
Propiedad del nombre D-Bus
Al conectarse al D-Bus, a los componentes se les asigna un identificador único, lo que mitiga los ataques que abusan del reciclaje de PID. El identificador único comienza con dos puntos y tiene números separados por puntos, como “:1.337”. Los componentes pueden usar la API de D-Bus para poseer nombres identificables como “org.freedesktop.Avahi” o “com.ubuntu.SystemService”. Para que D-Bus permita dicha propiedad, el contexto del proceso de solicitud debe estar permitido en los archivos de configuración de D-Bus. Esos archivos de configuración están bien documentados y mantenidos en /usr/local/share/dbus-1/system.conf y /usr/local/share/dbus-1/session.conf (en algunos sistemas en /usr/local/dbus- 1 directamente). Específicamente, el system.conf no permite la propiedad a menos que se especifique lo contrario en otros archivos de configuración incluidos (comúnmente en /etc/dbus-1/system.d ).
Figura 1: Diferentes políticas de propiedad para System Bus y Session Bus
Además, si el nombre solicitado ya existe– la solicitud no será concedida hasta que el proceso propietario libere el nombre.
Caza de vulnerabilidades
Nuestro equipo comenzó a enumerar los servicios que se ejecutan como root y escuchan los mensajes en System Bus, realizando revisiones de código y análisis dinámico. Hemos informado dos problemas de fuga de información como resultado:
- Divulgación de información de directorio en Blueman
- Divulgación de información de directorio en PackageKit (CVE-2022-0987)
Si bien estos son interesantes, su gravedad es baja: un atacante puede enumerar archivos en directorios que requieren altos permisos para enumerar archivos. Luego comenzamos a notar patrones interesantes en una unidad systemd llamada networkd-dispatcher . El objetivo de networkd-dispatcher es enviar cambios de estado de la red y, opcionalmente, ejecutar diferentes secuencias de comandos en función del nuevo estado. Curiosamente, se ejecuta en el arranque como root:
Figura 2: networkd-dispatcher ejecutándose como root
Flujo de código para networkd-dispatcher
de networkd-dispatcher código fuente , notamos un flujo interesante:
- La registro registra un nuevo receptor de señal para el servicio ” org.freedesktop.network1 ” en el System Bus, para el nombre de señal ” PropertiesChanged “.
- El controlador de señales ” _receive_signal ” realizará algunas comprobaciones básicas sobre el tipo de objeto que se envía, concluye la interfaz de red modificada en función de la ruta del objeto que se envía y luego concluye sus nuevos estados, ” OperationalState ” y ” AdministrativeState “, cada uno extraído del datos. Para cualquiera de esos estados, si no están vacíos, se invocará el método ” handle_state “.
- El método “ handle_state ” simplemente invoca “ _handle_one_state ” para cada uno de esos dos estados.
- “ _handle_one_state ” valida que el estado no esté vacío y verifica si es diferente al estado anterior. Si es así, actualizará el nuevo estado e invocará el método “ _run_hooks_for_state ”, que es responsable de descubrir y ejecutar los scripts para el nuevo estado.
- “ _run_hooks_for_state ” implementa la siguiente lógica:
- Descubre la lista de scripts invocando el método ” get_script_list ” (que obtiene el nuevo estado como una cadena). Este método simplemente llama a ” scripts_in_path “, que tiene como objetivo devolver todos los archivos bajo “/etc/networkd-dispatcher/<state>.d” que son propiedad del usuario raíz y del grupo raíz, y son ejecutables.
- Ordena la lista de scripts.
- Ejecuta cada script con subprocess.Popen mientras proporciona variables de entorno personalizadas.
Figura 3: código fuente de _run_hooks_for_state: algunas partes se omiten por brevedad
El paso 5 tiene varios problemas de seguridad:
- directorio ( CVE-2022-29799 ) : ninguna de las funciones en el flujo desinfecta OperationalState o AdministrationState . Dado que los estados se utilizan para crear la ruta del script, es posible que un estado contenga patrones de recorrido de directorios (p. ej., “ ../../ ”) para escapar del directorio base “ /etc/networkd-dispatcher ”.
- Carrera de : tanto el descubrimiento de secuencias de comandos como el subproceso los enlaces simbólicos.
- de tiempo de verificación-tiempo de uso ( TOCTOU ) ( CVE-2022-29800 ) : hay un cierto tiempo entre que se descubren los scripts y se ejecutan. Un atacante puede abusar de esta vulnerabilidad para reemplazar secuencias de comandos que networkd-dispatcher cree que son propiedad de root por otras que no lo son.
Figura 4: Creación de la lista de secuencias de comandos en el método “scripts_in_path”, incluido el código vulnerable con “subdir” envenenado.
Explotación
Supongamos que un adversario tiene un componente D-Bus malicioso que puede enviar una señal arbitraria. Por lo tanto, un atacante puede hacer lo siguiente:
- Prepare un directorio ” /tmp/nimbuspwn ” y plante un enlace simbólico ” /tmp/nimbuspwn/poc.d ” para apuntar a ” /sbin “. El “/sbin” se eligió específicamente porque tiene muchos ejecutables propiedad de root que no se bloquean si se ejecutan sin argumentos adicionales. Esto abusará del problema de carrera que mencionamos anteriormente.
- Para cada nombre de archivo ejecutable bajo “ /sbin ” propiedad de root, plante el mismo nombre de archivo bajo “ /tmp/nimbuspwn ”. Por ejemplo, si “ /sbin/vgs ” es ejecutable y es propiedad de root, plante un archivo ejecutable “ /tmp/nimbuspwn/vgs ” con la carga útil deseada. Esto ayudará al atacante a ganar la condición de carrera impuesta por la TOCTOU .
- Envía una señal con OperationalState “../../../tmp/nimbuspwn/poc” . Esto abusa de la directorios y escapa del directorio del script.
- El controlador de señales networkd-dispatcher se activa y crea la lista de secuencias de comandos desde el directorio “/etc/networkd-dispatcher/../../../tmp/nimbuspwn/poc.d” , que es en realidad el enlace simbólico ( “/ tmp/nimbuspwn/poc.d” ), que apunta a “/sbin” . Por lo tanto, crea una lista compuesta por muchos ejecutables propiedad de root.
- Cambie rápidamente el enlace simbólico ” /tmp/nimbuspwn/poc.d” para que apunte a ” /tmp/nimbuspwn “. Esto abusa de la condición de carrera de TOCTOU : la ruta del script cambia sin que networkd-dispatcher lo sepa.
- El despachador comienza a ejecutar archivos que inicialmente estaban en ” /sbin “, pero en realidad en el directorio ” /tmp/nimbuspwn “. Dado que el despachador “cree” que esos archivos son propiedad de root, los ejecuta a ciegas con subprocess.Popen como root. Por lo tanto, nuestro atacante ha explotado con éxito la vulnerabilidad.
Tenga en cuenta que para ganar la TOCTOU carrera con alta probabilidad, plantamos muchos archivos que potencialmente pueden ejecutarse. Nuestros experimentos muestran que tres intentos fueron suficientes para ganar la TOCTOU carrera .
Figura 5: Diagrama de flujo del ataque en tres etapas
Dado que no deseamos ejecutar el exploit cada vez que queramos ejecutarlo como root, el payload que terminamos implementando deja una puerta trasera de root como tal:
- Copia /bin/sh a /tmp/sh .
- Convierte el nuevo /tmp/sh en un binario Set-UID (SUID) .
- Ejecute /tmp/sh -p . El indicador ” -p ” es necesario ya que los shells modernos eliminan los privilegios por diseño.
Poseer el nombre del autobús
El lector astuto notará que todo el exploit eleva los privilegios asumiendo que nuestro código de exploit puede poseer el nombre de bus ” org.freedesktop.network1 “. Si bien esto no suena trivial, hemos encontrado varios entornos en los que esto sucede. Específicamente:
- En muchos entornos (por ejemplo, Linux Mint), el servicio systemd-networkd que normalmente posee el nombre de bus ” org.freedesktop.network1 ” no se inicia en el arranque de forma predeterminada.
- Al usar la búsqueda avanzada en Microsoft Defender para Endpoint , pudimos detectar varios procesos que se ejecutan como el de systemd-network (que puede poseer el nombre de bus que necesitamos) que ejecutan código arbitrario desde ubicaciones de escritura mundial. Estos incluyen varios gpgv (que se inician cuando apt-get ), así como Erlang Port Mapper Daemon ( epmd ), que permite ejecutar código arbitrario en algunos escenarios.
La consulta que usamos también la pueden ejecutar los clientes de Microsoft Defender para Endpoint:
DispositivoProcesoEventos
| donde Marca de tiempo > ago(5d)
y AccountName == "systemd-network"
y no está vacío (InitiatingProcessAccountName)
y no está vacío (Nombre de archivo)
| proyecto DeviceId, FileName, FolderPath, ProcessCommandLine
Por lo tanto, pudimos explotar estos escenarios e implementar nuestro propio exploit:
Figura 6: Nuestro exploit implementado y ganando la carrera TOCTOU
Si bien es capaz de ejecutar cualquier script arbitrario como root, nuestro exploit copia /bin/sh en el /tmp , establece /tmp/sh como un ejecutable Set-UID (SUID) y luego invoca ” /tmp/sh -p “. Tenga en cuenta que el indicador ” -p ” es necesario para obligar al shell a no perder privilegios.
Fortalecimiento de la estrategia de seguridad y detección de dispositivos
A pesar de que el panorama de amenazas en evolución ofrece regularmente nuevas amenazas, técnicas y capacidades de ataque, los adversarios continúan enfocándose en identificar y aprovechar las vulnerabilidades sin parches y las configuraciones incorrectas como un vector para acceder a sistemas, redes e información confidencial con fines maliciosos. Este bombardeo constante de ataques que abarcan una amplia gama de plataformas, dispositivos y otros dominios enfatiza la necesidad de un enfoque de gestión de vulnerabilidades integral y proactivo que pueda identificar y mitigar aún más los exploits y problemas previamente desconocidos.
de Microsoft de administración de amenazas y vulnerabilidades ayudan a las organizaciones a monitorear su postura de seguridad general, brindando información en tiempo real sobre el riesgo con descubrimiento continuo de vulnerabilidades, priorización inteligente contextualizada y corrección de fallas sin problemas con un solo clic. Aprovechando nuestra investigación sobre las vulnerabilidades de Nimbuspwn para mejorar las soluciones, nuestra gestión de amenazas y vulnerabilidades ya cubre CVE-2022-29799 y CVE-2022-29800 e indica dichos dispositivos vulnerables en el módulo de amenazas y vulnerabilidades en Microsoft Defender para Endpoint .
de puntos finales de Microsoft Defender para detección y respuesta (EDR) detectan el ataque transversal de directorio necesario para aprovechar Nimbuspwn. Además, el equipo de detección de Microsoft Defender for Endpoint tiene una detección genérica para invocaciones sospechosas de procesos Set-UID, que detectaron nuestro exploit sin conocimiento previo.
Figura 7: Microsoft Defender para Endpoint detecta un proceso SUID sospechoso utilizado en nuestro exploit
La defensa contra el panorama de amenazas en evolución requiere la capacidad de proteger y asegurar las experiencias informáticas de los usuarios, ya sea un dispositivo Windows o no Windows. Microsoft enriquece continuamente nuestras tecnologías de protección a través de una sólida investigación que protege a los usuarios y organizaciones en todas las plataformas principales todos los días. Este caso mostró cómo la capacidad de coordinar dicha investigación a través de la colaboración de expertos entre industrias es vital para mitigar los problemas de manera efectiva, independientemente del dispositivo vulnerable o la plataforma en uso. Al compartir nuestra investigación y otras formas de inteligencia de amenazas, podemos continuar colaborando con la comunidad de seguridad más grande y esforzarnos por crear una mejor protección para todos.
