Múltiples vulnerabilidades críticas muy fáciles de explotar en OMI afectan innumerables clientes Microsoft Azure. En especial la vulnerabilidad  CVE-2021-38647  con una gravedad CVSS 9.8 sobre 10. La vulnerabilidad ya está siendo explotada por botnets como Mirai.

 

OMIGOD: Open Management Infrastruture (OMI) de código abierto de Microsoft

 

Esta falla no afecta directamente a Windows en absoluto, porque es un error en la herramienta Open Management Infrastruture (OMI) de código abierto de Microsoft que está diseñada para Linux en general y para servidores Linux alojados en Azure en particular.


Muy simplificado, OMI es la respuesta basada en Linux de Microsoft para WMI, la interfaz de administración de Windows que los administradores de sistemas utilizan para controlar sus redes de Windows.

Al igual que WMI, el código OMI se ejecuta como un proceso privilegiado en sus servidores para que los administradores de sistemas y el software de administración del sistema puedan consultar y controlar lo que está sucediendo, como enumerar procesos, iniciar programas de utilidad y verificar los ajustes de configuración del sistema.

Desafortunadamente, los ciberdelincuentes, especialmente los criminales de ransomware, aman WMI tanto como a los administradores de sistemas.

Esto se debe a que WMI ayuda a los atacantes a planificar y ejecutar sus ataques destructivos en toda una organización, una vez que tienen una cabeza de playa a nivel de administrador en algún lugar de la red.

Lamentablemente, OMIGOD es un error de OMI que, en teoría, ofrece a los delincuentes el mismo tipo de poder distribuido en sus servidores Linux ..

No se requiere contraseña

En lugar de adivinar un token de autenticación válido para insertarlo en una solicitud web OMI fraudulenta, simplemente omite toda mención del token de autenticación por completo, ¡y ya está!

Por supuesto, con los parches de código relevantes publicados hace más de un mes, en forma de código fuente nada menos, puede suponer que los administradores de sistemas de Linux que son usuarios de OMI ya han tenido mucho tiempo para parchear.

También puede suponer que cualquiera que confíe en su distribución de Linux para proporcionar paquetes binarios actualizados (evitando así la necesidad de reconstruir el código manualmente desde la fuente) también estaría por delante del juego.

Sin embargo, como Wiz señala de manera bastante intencionada en su publicación de blog, muchos usuarios de Linux en Azure pueden no saber que tienen OMI y, por lo tanto, ni siquiera saben que deben buscar problemas de seguridad con él.

Esto se debe a que es posible que el software OMI se haya instalado automáticamente, junto con varios servicios de Azure que eligieron usar.

Wiz afirma que:

    Los clientes de Azure en máquinas Linux, que representan más de la mitad de todas las instancias de Azure según Microsoft, están en riesgo si utilizan cualquiera de los siguientes servicios / herramientas: Azure Automation, Azure Automatic Update, Azure Operations Management Suite (OMS), Azure Log Analytics, Azure Configuration Management, Azure Diagnostics [y] Azure Container Insights,

Si se ocupa de los servidores Linux y, en particular, si están alojados en Azure, le sugerimos que compruebe si tiene OMI y, de ser así, se asegure de tener la última versión.

Mitigaciones y consejos

    1. Si sabes que tiene OMI en sus servidores, asegúrese de que esté actualizado. Según Microsoft, puede usar el comando omicli ei (enumerar instancia) para verificar qué versión está instalada en cada servidor. Busque la versión 1.6.8-1 o posterior.

    For Debian systems (e.g., Ubuntu): 

dpkg -l omi

    For Redhat based system (e.g., Fedora, CentOS, RHEL): 

rpm -qa omi

    2. Si no estás seguro de tener OMI instalado, búsquelo. Puede buscar en su sistema de archivos archivos llamados omilci.conf, omigen.conf y omiserver.conf, así como archivos llamados .omiclirc y .omigenrc en el directorio de inicio de cualquier cuenta, o usar el administrador de paquetes de su distribución de Linux para buscar paquetes con nombres que comiencen omi *.

    3. Comprueba si hay servicios de red de escucha que puedan exponer a OMI de forma remota. Según Wiz, el número de puerto predeterminado es 5986 y el acceso remoto no está habilitado de forma predeterminada. Puede comprobar si hay sockets de escucha en un servidor mediante el comando netstat. (Consulte a continuación). Desactive el acceso remoto a menos que realmente lo desee o lo necesite.

Puertos abiertos:

• 5985
• 5986
• 1270

    4. Lea los consejos de seguridad de Microsoft para CVE-2021-38647. Tenga en cuenta que hay otras tres vulnerabilidades algo menos graves en OMI que Wiz encontró al mismo tiempo, por lo que es posible que desee leerlas también: CVE-2021-38645, CVE-2021-38648 y CVE-2021-38649.

• https://msrc-blog.microsoft.com/2021/09/16/additional-guidance-regarding-omi-vulnerabilities-within-azure-vm-management-extensions/

Cómo utilizar el comando netstat

Para ver todos los sockets de escucha (se necesita root):

# netstat -l
[...]

Para mostrar todos los sockets de escucha con ID de proceso y nombres:

# netstat -lp
[...]

Restrinja la salida a los sockets TCP de escucha, a pesar de que OMI usa HTTPS sobre TCP:

# netstat -lp | grep tcp
[...]

Para practicar el uso de este comando, inicie un socket TCP de escucha en una ventana de terminal, así ...

$ nc -n -l -v -p 8888
escuchando en [cualquier] 8888 ...

... y luego, en otra ventana de terminal, use netstat para buscar el socket de escucha en el puerto 8888:

# netstat -lp | grep tcp
tcp 0 0 [0.0.0.0]: 8888 0.0.0.0:* ESCUCHAR {PROCESSNO] / nc

Tenga en cuenta que en el ejemplo aove, [0.0.0.0]: 8888 indica que el proceso nc está escuchando en el puerto 8888 en todas las interfaces de red, lo que significa que se puede acceder al puerto de forma local o remota.

 

Fuentes:

https://www.wiz.io/blog/secret-agent-exposes-azure-customers-to-unauthorized-code-execution

https://nakedsecurity.sophos.com/2021/09/16/omigod-an-exploitable-hole-in-microsoft-open-source-code/