Las actualizaciones del martes de parches de septiembre de 2021 de Microsoft salieron hace una semana.
La solución que todos esperábamos con gran expectación era el parche para CVE-2021-40444, un error de ejecución remota de código de día cero en MSHTML que fue anunciado por Microsoft pocos días antes del martes de parches.
Los errores remotos en MSHTML, que es el renderizador web utilizado por Internet Explorer (IE), siempre son un gran problema, especialmente si los ciberdelincuentes los encuentran antes que los buenos.
Con tan poco tiempo para el martes de parches, la gran pregunta era: “¿Lo lograrán?” y, afortunadamente, la respuesta fue “Sí”.
Por supuesto, la mayoría de las actualizaciones del martes de parches cierran más de un agujero de seguridad, y muchos de los otros a menudo no reciben mucha publicidad, ya sea porque los buenos los encontraron primero, lo que hace que el parche sea proactivo, o por no afectar a todos los equipos de tu red.
OMIGOD, también hay un error basado en Linux
Este mes, CVE-2021-38647 resulta ser un agujero de seguridad de ese tipo, interesante e importante, pero aparentemente no muy emocionante.
Esta vulnerabilidad no afecta directamente a Windows, 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.
Lo has leído bien: una de las notificaciones de errores del martes de parches de este mes fue una vulnerabilidad en un producto, dirigido a administradores de sistemas Linux, que Microsoft envía en forma de código fuente a través de su servicio GitHub.
De hecho, las correcciones de errores relevantes estaban disponibles oficialmente en el código fuente de OMI el 12 de agosto de 2021, hace más de un mes.
Entonces, esta vulnerabilidad parecía, a simple vista, ser una de esas que realmente no valía la pena saltar y que probablemente ya estaba parcheada en muchos o la mayoría de los servidores, dado que su código fuente público se había actualizado durante mucho tiempo.
Bueno, Wiz, la startup que descubrió e informó este error y, por lo tanto, fue responsable de poner en marcha el proceso de reparación, cree que vale la pena entusiasmarse.
De hecho, están tan emocionados con él hasta el punto de que lo llamaron OMIGOD y lo describieron en el blog de su empresa.
Incluso le pusieron un logotipo, que usamos en la imagen de la parte superior del artículo.
Es fácil ser escéptico cuando oímos hablar de un nuevo BWAIN, nuestro acrónimo de Bug With An Impressive Name, pero si tienes algún servidor Linux, vale la pena tomar nota de lo que Wiz tiene que decir.
El error
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 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 posición 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 excepto que no necesitan ese posicionamiento de nivel de administrador, porque CVE-2021-38647 básicamente ya lo proporciona, lo que le permite entrar, obtener root y hacerse cargo, todo de una vez.
No se requiere contraseña
Sorprendentemente, el error parece reducirse a un truco ridículamente fácil.
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, puedes suponer que los administradores de sistemas de Linux que son usuarios de OMI ya han tenido mucho tiempo para parchear.
También puedes 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 le afectan sus problemas de seguridad.
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,
Como la empresa se ve obligada a admitir, “esta es solo una lista parcial”, ya que se limita a aquellos que conocen, por lo que bien puede haber otros.
Si te ocupas de servidores Linux y, en particular, si están alojados en Azure, te sugerimos que compruebes si tienes OMI y, de ser así, te asegures de tener la última versión.
¿Qué hacer?
- Si sabes que tienes OMI en tus servidores, asegúrate de que estén actualizados. Según Microsoft, puedes usar el comando omicli ei (enumerar instancia) para verificar qué versión está instalada en cada servidor. Busca la versión 6.8-1 o posterior.
- Si no estás seguro de tener OMI instalado, búscalo. Puedes buscar en tu 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 tu distribución de Linux para buscar paquetes con nombres que comiencen omi*. Si encuentras OMI donde no lo esperabas, ve al paso anterior.
- 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. Puedes comprobar si hay sockets de escucha en un servidor mediante el comando netstat. (Más información a continuación). Desactiva el acceso remoto a menos que realmente lo desees o lo necesites.
- Lee los consejos de seguridad de Microsoft para CVE-2021-38647. Ten en cuenta que hay otras tres vulnerabilidades algo menos graves en OMI que Wiz encontró al mismo tiempo, por lo que es posible que desees leerlas también: CVE-2021-38645, CVE-2021-38648 y CVE-2021-38649.
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 [...]
Restringe 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, inicia un socket TCP de escucha en una ventana de terminal, así:
$ nc -n -l -v -p 8888 listening on [any] 8888
Luego, en otra ventana de terminal, usa 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:* LISTEN {PROCESSNO] / nc
Ten 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.
Dejar un comentario