Agrandar / No es así como funciona la vulnerabilidad OMIGOD, por supuesto, pero los relámpagos son mucho más fotogénicos que XML creado con fines malintencionados.

Wiz, proveedor de seguridad en la nube, que recientemente fue noticia al descubrir una enorme vulnerabilidad 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 subproducto de habilitar cualquiera de las varias opciones de administración y / o informes de registro en la interfaz de usuario de Azure.

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

OMIGOD

Al optar por cualquiera de los varios servicios atractivos de infraestructura de Azure (como el registro distribuido), se instala automáticamente un servicio poco conocido. dentro 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 un ID de usuario específico (UID), pero desafortunadamente, un error provocó que las solicitudes mal formadas que omiten la estrofa de autenticación por completo sean aceptadas como si fueran dadas por el root el propio usuario.

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

Como investigador senior 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 se apodera de 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. Organizaciones que adoptan Microsoft System Center (que se anuncia en cada nueva instalación de Windows Server 2019 y versiones posteriores) y administra los hosts de Linux dentro o fuera de las instalaciones y también termina con la versión con errores de OMI implementada en esos hosts administrados.

Mientras Nir y yo hablamos sobre el alcance de la vulnerabilidad, señalé la probabilidad de que algunos clientes de Azure habiliten el inicio de sesión en la interfaz de usuario y agreguen una regla de «permiso predeterminado» al firewall de Azure de una máquina virtual 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 eso es exactamente lo que llamaron la vulnerabilidad: OMIGOD.

Una recompensa difícil de recolectar

A pesar de la gravedad obvia de OMIGOD, que incluye cuatro errores separados pero relacionados que descubrió Wiz, la compañía tuvo dificultades para lograr que Microsoft le pagara una recompensa por su descubrimiento y divulgación responsable. En una serie de correos electrónicos que revisó Ars, los representantes de Microsoft inicialmente descartaron las vulnerabilidades como «fuera del alcance» de Azure. Según Wiz, los representantes de Microsoft en una llamada telefónica caracterizaron ademá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 donado a The Open Group en 2012. Desde entonces, la gran mayoría de los compromisos con OMI han continuado proviniendo de Redmond, empleados de Microsoft contribuyentes—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; a los administradores no se les pide que presionen la línea de comandos 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, hay poca notificación obvia para el administrador que lo habilitó. Descubrimos que la mayoría de los administradores de Azure parecen solo descubrir que OMI existe si su partición / var se llena con sus volcados de núcleo.

Finalmente, 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 polvoriento rincón de la cadena de suministro

«OMI es como una implementación de Linux de Windows Infraestructura de gestión«, 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 máquinas con Windows y Linux «.

La inclusión de OMI en Azure Management, y en Microsoft System Center, que se anuncia directamente en cada nueva instalación de Windows Server, significa que se instala como un componente de bajo nivel en una asombrosa cantidad 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 extremadamente 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 autenticado» se descubriera rápidamente. Desafortunadamente, este no es el caso: OMI tiene un inquietantemente bajo total de 24 contribuyentes, 90 bifurcaciones y 225 «estrellas» (una medida de interés relativamente casual para los desarrolladores) durante los nueve años que ha tenido un hogar en Github.

Por el contrario, mi propio proyecto de gestión de ZFS, Sanoid, que no escucha en ningún puerto y ha sido descrito con precisión, aunque sin cariño, como «un par de miles de líneas de script Perl», tiene más del doble de contribuyentes y bifurcaciones y casi 10 veces las estrellas.

Según cualquier estándar razonable, un componente de infraestructura de importancia crítica como OMI debería recibir mucha más atención, lo que plantea interrogantes sobre cuántos otro Los rincones polvorientos de la cadena de suministro de software están igualmente deficientemente inspeccionados y mal mantenidos.

Una ruta de actualización poco clara

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

«Microsoft no ha compartido su plan de mitigación con nosotros», dijo Ami Luttwak, CTO de Wiz, a Ars, «pero según la telemetría de nuestro cliente, 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 sido obsoleto. Es posible que los clientes que sigan usando System Center con Linux habilitado para OMI necesiten actualizar manualmente el agente OMI.

Mitigación para usuarios afectados

Si es un administrador de sistemas 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 Unix pero no los puertos, seguirá siendo vulnerable hasta que Microsoft implemente un parche, pero el alcance se limita únicamente a la escalada de privilegios locales.

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

En particular, los administradores conscientes de la seguridad deben limitar cuidadosamente el acceso a este y cualquier otro servicio de red a solo 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 especificidad allow reglas vigentes solo para máquinas que necesitar para acceder a un servicio determinado.

Cuando 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 para acceder a OMI para que Azure Management funcione correctamente, simplemente negar el acceso desde otras VM 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, se puede encontrar la propia publicación de blog de Wiz que detalla sus hallazgos. aquí.

Author

Write A Comment