Los investigadores de seguridad de Wiz descubren otra importante vulnerabilidad de Azure

El proveedor de seguridad en la nube Wiz, que recientemente fue noticia al descubrir una vulnerabilidad masiva en el servicio de base de datos administrado por CosmosDB de Microsoft Azure, ha encontrado otro agujero en Azure.

La nueva vulnerabilidad afecta a las máquinas virtuales Linux en Azure. Terminan con un servicio poco conocido llamado OMI instalado como un subproducto de la habilitación de varias opciones de administración o informes de registro en la interfaz de usuario de Azure.

En el peor de los casos, la vulnerabilidad en OMI podría aprovecharse en la ejecución remota de código raíz, aunque afortunadamente, el firewall fuera de la máquina virtual de Azure, activado por defecto, lo limitará solo a las redes internas de la mayoría de los clientes.

Dios mío

Al optar por cualquiera de varios atractivos servicios de infraestructura de Azure (como el registro distribuido) se instala automáticamente un servicio poco conocido en el interior la máquina virtual de Azure en cuestión. Ese servicio, OMI, abreviatura de Open Management Interface, está diseñado para funcionar de manera muy similar al servicio WMI de Microsoft Windows, lo que permite la recopilación de registros y métricas, así como cierta administración remota.

Parte de la especificación OMI requiere autenticación para vincular comandos y solicitudes a una identificación de usuario (UID) específica, pero desafortunadamente, un error provocó que las solicitudes con formato incorrecto que omiten la estrofa de autenticación por completo se aceptaran como si fueran proporcionadas por el root usuario mismo.

Cuando se configura para administración remota, OMI ejecuta un servidor HTTPS en el puerto 5986, al que se puede conectar con un cliente HTTPS estándar como curl y dados comandos razonablemente legibles por humanos en el protocolo SOAP derivado de XML. En otras configuraciones, OMI solo se ejecuta en un socket Unix local en /var/opt/omi/run/omiserver.sockque limita su explotación únicamente a usuarios locales.

Como investigador principal de seguridad de Wiz nir ohfeld me guió a través de una demostración de la vulnerabilidad, la describió principalmente en términos de escalada de privilegios: un atacante que obtiene cualquier punto de apoyo en una máquina virtual afectada puede emitir cualquier comando arbitrario como root usando la sintaxis OMI.

En entornos más grandes donde OMI escucha en un puerto de red, no solo en un socket Unix local, también es una excelente manera de pivotar lateralmente: un atacante que obtiene un shell en una VM en la red local de Azure de un cliente generalmente puede usar el OMI con errores para obtener control de cualquier otra máquina virtual en el mismo segmento de red.

Resulta que Azure no es el único lugar donde encontrará OMI. Las organizaciones que adoptan Microsoft System Center (que se anuncia en cada nueva instalación de Windows Server 2023 y versiones posteriores) y administran hosts Linux dentro o fuera de las instalaciones también terminan con la versión con errores de OMI implementada en esos hosts administrados.

Mientras Nir y yo hablábamos sobre el alcance de la vulnerabilidad, señalé la probabilidad de que algunos clientes de Azure habilitaran el inicio de sesión en la interfaz de usuario y agregaran una regla de «permiso predeterminado» al firewall de Azure de una máquina virtual de Linux; claro, es una práctica incorrecta, pero sucede. «Oh, Dios mío», exclamé, y el equipo de Wiz se echó a reír. Resulta que así es exactamente como llamaron a la vulnerabilidad: OMIGOD.

Una recompensa difícil de cobrar

A pesar de la gravedad obvia de OMIGOD, que incluye cuatro errores separados pero relacionados que descubrió Wiz, la empresa tuvo dificultades para lograr que Microsoft pagara una recompensa por su descubrimiento y divulgación responsable. En una serie de correos electrónicos que revisó Ars, los representantes de Microsoft descartaron inicialmente las vulnerabilidades como «fuera del alcance» de Azure. Según Wiz, los representantes de Microsoft en una llamada telefónica caracterizaron aún más los errores en OMI como un problema de «código abierto».

Esta afirmación se complica por el hecho de que Microsoft fue el autor de OMI en primer lugar, que donó a The Open Group en 2012. Desde entonces, la gran mayoría de los compromisos con OMI han seguido viniendo de colaboradores empleados por Microsoft con sede en Redmond: código abierto o no, este es claramente un proyecto de Microsoft.

Además de Microsoft de facto propiedad del proyecto, el propio sistema de administración de Azure implementa automáticamente OMI; no se les pide a los administradores que presionen la línea de comando e instalen el paquete por sí mismos. En su lugar, se implementa automáticamente dentro de la máquina virtual cada vez que se hace clic en una opción dependiente de OMI en la GUI de Azure.

Incluso cuando la administración de Azure implementa OMI, el administrador que lo habilitó no notifica mucho. Descubrimos que la mayoría de los administradores de Azure solo parecen descubrir que OMI existe si su partición /var se llena con sus volcados de núcleo.

Eventualmente, Microsoft cedió en su negativa a pagar una recompensa por errores de Azure Management por OMIGOD y otorgó a Wiz un total de $ 70,000 por los cuatro errores que lo componen.

Un rincón polvoriento de la cadena de suministro

«OMI es como una implementación de Linux de la infraestructura de administración de Windows», dijo Ohfeld a Ars. «Nuestra suposición es que cuando se trasladaron a la nube y tuvieron que admitir máquinas Linux, querían cerrar la brecha, tener la misma interfaz disponible para las máquinas Windows y Linux».

La inclusión de OMI en Azure Management, y en Microsoft System Center, anunciado directamente en cada nueva instalación de Windows Server, significa que se instala como un componente de bajo nivel en una cantidad asombrosa de máquinas Linux de importancia crítica, virtuales y de otro tipo. El hecho de que escuche comandos en un puerto de red abierto en algunas configuraciones, utilizando protocolos muy conocidos (SOAP sobre HTTPS), lo convierte en un objetivo muy atractivo para los atacantes.

Con el alcance de la implementación y la vulnerabilidad potencial, uno podría esperar razonablemente que muchos ojos estuvieran en OMI, lo suficiente como para que una vulnerabilidad resumida como «olvidó asegurarse de que el usuario se autenticó» se descubriría rápidamente. Desafortunadamente, este no es el caso: OMI tiene un total inquietantemente bajo de 24 colaboradores, 90 bifurcaciones y 225 «estrellas» (una medida del interés de los desarrolladores relativamente casual) durante los nueve años que ha tenido un hogar en Github.

Por el contrario, mi propio proyecto de administración de ZFS, Sanoid, que no escucha puertos y ha sido descrito con precisión, aunque sin caridad, como «un par de miles de líneas de script Perl», tiene más del doble de colaboradores y bifurcaciones y casi 10 veces las estrellas.

Bajo cualquier estándar razonable, un componente de infraestructura tan críticamente importante como OMI debería recibir mucha más atención, lo que plantea dudas sobre cuántos otro Los rincones polvorientos de la cadena de suministro de software están siendo igualmente poco inspeccionados y mantenidos.

Una ruta de actualización poco clara

El empleado de Microsoft, Deepak Jain, comprometió las correcciones necesarias en el repositorio GitHub de OMI el 11 de agosto, pero como Ars confirmó directamente, esas correcciones aún no se habían implementado en Azure a partir del 13 de septiembre. Microsoft le dijo a Wiz que anunciaría un CVE el martes de parches, pero Los investigadores de Wiz expresaron su incertidumbre sobre cómo o cuándo podrían implementarse universalmente esas correcciones.

«Microsoft no ha compartido su plan de mitigación con nosotros», dijo Ami Luttwak, CTO de Wiz, a Ars, «pero según nuestra propia telemetría de clientes, esto podría ser complicado de parchear correctamente. OMI está integrado en varios servicios de Azure y cada uno puede requerir un ruta de actualización diferente».

Para sistemas Linux arbitrarios administrados de forma remota desde Microsoft System Center, la ruta de actualización puede ser aún más complicada, porque los agentes de Linux para System Center han quedado obsoletos. Los clientes que todavía usan System Center con Linux habilitado para OMI pueden necesitar actualizar manualmente el agente OMI.

Mitigación para los usuarios afectados

Si es un administrador del sistema Linux y le preocupa que pueda estar ejecutando OMI, puede detectarlo fácilmente buscando puertos de escucha en TCP 5985 y 5986 (TCP 1270, para agentes OMI implementados por Microsoft System Center en lugar de Azure) o un Unix. enchufe ubicado debajo /var/opt/omi.

Si tiene el socket de Unix pero no los puertos, aún es vulnerable hasta que Microsoft implemente un parche, pero el alcance se limita solo a la escalada de privilegios locales.

En los casos en que OMI escucha en los puertos TCP, se vincula a todas las interfaces, incluidas las públicas. Recomendamos enfáticamente limitar el acceso a estos puertos a través del firewall de Linux, ya sea que su instancia OMI esté reparada o no.

En particular, los administradores conscientes de la seguridad deben limitar cuidadosamente el acceso a este y a cualquier otro servicio de red solo a aquellos segmentos de red que realmente necesitar acceso. Las máquinas que ejecutan Microsoft System Center obviamente necesitan acceso a OMI en los sistemas cliente, al igual que la propia infraestructura de Azure, pero los propios clientes no necesitan acceso OMI de uno a otro.

La mejor práctica para reducir la superficie de ataque de la red, con este y cualquier otro servicio potencialmente vulnerable, es un firewall global. deny regla, con allow reglas vigentes sólo para las máquinas que necesitar para acceder a un determinado servicio.

Donde eso no sea práctico, por ejemplo, en un entorno de Azure donde el administrador no está seguro de qué segmentos de red de Microsoft necesitan acceder a OMI para que Azure Management funcione correctamente, simplemente denegar el acceso desde otras máquinas virtuales en el mismo segmento de red al menos evitar el movimiento lateral de los atacantes de una máquina a otra.

Para obtener más información técnica, puede encontrar la publicación de blog de Wiz que detalla sus hallazgos aquí.