¡OMIGOD, una laguna explotable en el código fuente abierto de Microsoft! – Pura seguridad

Las actualizaciones del martes de parches de septiembre de 2021 de Microsoft salieron esta semana.

La solución que todos esperaban con gran expectación era el parche en el CVE-2021-40444, un error de ejecución de código remoto de día cero en MSHTML que fue anunciado por Microsoft pocos días antes del martes de parches:

Los errores removibles en MSHTML, el renderizador web usado por Internet Explorer (IE), son siempre un gran problema, especialmente cuando los delincuentes los encuentran antes que los buenos.

Con tan poco tiempo hasta el martes de parches, la gran pregunta de Microsoft era: «¿Lo lograrán?» … y afortunadamente la respuesta fue «Sí»:

Por supuesto, la mayoría de las actualizaciones de Patch Tuesday solucionan más de un solo agujero de seguridad, y algunas de las otras a menudo no reciben mucha publicidad, ya sea porque fueron encontradas por primera vez por los Good Guys, lo que hace que el parche sea proactivo, o porque no lo hacen. No se preocupan todos los equipos de la red.

Dios mío, también hay un error basado en Linux

Este mes, CVE-2021-38647 resulta ser un agujero de seguridad, interesante e importante, pero aparentemente no muy emocionante.

Este error no afecta a Windows directamente en absoluto, ya que es un error en la herramienta Open Management Infrastructure (OMI) de código abierto de Microsoft, que fue diseñada para Linux en general y para servidores Linux alojados por Azure en particular.

Lo leíste bien: uno de los informes de errores del martes de parches de este mes fue un error en un producto dirigido a administradores de sistemas Linux que Microsoft está distribuyendo en 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, es decir, hace más de un mes.

Entonces, en la superficie, esta vulnerabilidad parecía ser una de las que realmente no valía la pena rebotar hacia arriba y hacia abajo, y probablemente ya estaba parcheada en muchos o la mayoría de los servidores porque su código fuente público se había actualizado durante mucho tiempo.

Fuente, mago, la startup de nombre extraño que descubrió e informó este error y, por lo tanto, fue responsable de iniciar el proceso para solucionarlo, cree que vale la pena entusiasmarse.

De hecho, están tan emocionados que lo bautizaron. OMIGODy lo anotó en el blog de su empresa.

Incluso le dieron un logo que usamos en la imagen de arriba en el artículo.

Es fácil ser cínico cuando se anuncia un nuevo BWAIN, nuestro alegre acrónimo de Error con un nombre formidable – pero si tiene servidores Linux, debería saber lo que Wiz tiene que decir.

El error en breve

OMI es, en términos simplistas, la respuesta de Microsoft basada en Linux a WMI, el Interfaz de administración de Windows que utilizan los administradores de sistemas para vigilar 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 de sistemas puedan consultar y controlar procesos como: B. Enumere procesos, inicie utilidades y verifique los parámetros de configuración del sistema.

Desafortunadamente, los delincuentes cibernéticos, especialmente los delincuentes de ransomware, aman WMI tanto como los administradores de sistemas.

Esto se debe a que WMI ayuda a los atacantes a planificar y ejecutar sus ataques destructivos en toda la empresa una vez que tienen una cabeza de puente a nivel de administrador en cualquier lugar de la red.

Desafortunadamente, OMIGOD es un error de OMI que teóricamente les da a los criminales el mismo poder distribuido sobre sus servidores Linux …

… excepto que no necesita esta cabeza de puente a nivel de administrador primero, porque CVE-2021-38647 básicamente ofrece su propia cabeza de puente con la que puede entrar, convertirse en root y hacerse cargo en un solo paso.

No se requiere contraseña

Sorprendentemente, el error parece limitarse a un truco ridículamente simple.

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

Dado que los parches de código apropiados se lanzaron hace más de un mes, no menos que el código fuente, por supuesto se podría suponer que los administradores de sistemas Linux que son usuarios de OMI han tenido mucho tiempo para parchear.

También puede asumir que cualquiera que confíe en su distribución de Linux para proporcionar paquetes binarios actualizados (evitando la necesidad de reconstruir manualmente el código desde la fuente) también está por delante de la competencia.

Sin embargo, como Wiz señala de manera bastante intencionada en su publicación de blog, es posible que muchos usuarios de Linux en Azure no sepan que tienen OMI y, por lo tanto, ni siquiera saben si se está utilizando para tener cuidado con los 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 desean usar.

Wiz afirma que:

Como tiene que admitir la empresa, «esta es solo una lista parcial», ya que está limitada a aquellos que la conocen, por lo que bien puede haber otras.

Si mantiene servidores Linux, especialmente si están alojados en Azure, le recomendamos que compruebe que tiene OMI y, de ser así, asegúrese de tener la última versión.

¿Qué tengo que hacer?

• 1. Cuando sepa que tiene OMI en sus servidores, asegúrese de que esté actualizado. Según Microsoft, puede utilizar el omicli ei (Enumerar instancia) para comprobar qué versión está instalada en cada servidor. Buscar versión 1.6.8-1 o después.
• 2. Si no está seguro de tener OMI instalado, búsquelo. Puede buscar en su sistema de archivos archivos con nombre. buscar omilci.conf, omigen.conf y omiserver.conf, así como archivos llamados .omiclirc y .omigenrc en el directorio de inicio de una cuenta o use el administrador de paquetes de su distribución de Linux para buscar paquetes con nombres que comiencen omi*. Si encuentra OMI donde no lo esperaba, diríjase a GOTO 1.
• 3. Busque servicios de red que puedan hacer que OMI esté disponible 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 buscar sockets de escucha en un servidor utilizando netstat Mando. (Consulte a continuación). Desactive el acceso remoto a menos que realmente lo desee o lo necesite.
• 4. Lea el Aviso de seguridad de Microsoft para CVE-2021-38647. Tenga en cuenta que hay otras tres vulnerabilidades ligeramente menos graves en OMI que Wiz encontró al mismo tiempo, así que asegúrese de verificarlas también: CVE-2021-38645, CVE-2021-38648 y CVE-2021-38649.

Cómo utilizar el netstat mando

Para mostrar todos los sockets de escucha (requiere root):

# netstat -l[...]

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

# netstat -lp [...]

Limite la salida a los sockets TCP de escucha aunque OMI use 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 de la siguiente manera …

$ nc -n -l -v -p 8888 listening on [any] 8888 ...

… y luego usarlo en otra ventana de terminal netstat para buscar la toma de escucha en el puerto 8888:

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

Observe que en el ejemplo anterior [0.0.0.0]:8888 significa que el proceso nc escucha en el puerto 8888 en todas las interfaces de red, lo que significa que se puede acceder al puerto de forma local o remota.