Informe de errores - Enero de 2022

Kevin McGrath · 2 de febrero de 2022

Ciberseguridad con sentido del humor

¿Por qué estoy aquí?

Ómicron es la 15.ª letra del alfabeto griego, que Donald Knuth utilizó para designar la notación O grande, representaba el cero en el Almagesto de Ptolomeo y tenía el valor 70 en la práctica de la isopsefía. Pero la mayoría de nosotros solo la relacionamos con una pandemia IN- TER- MI- NABLE. Un momento, ¿no le interesan nuestras divagaciones filosóficas sobre la palabra más mencionada en enero de 2022? ¿De verdad que ha venido hasta aquí para obtener información sobre vulnerabilidades? Bueno... no importa. ¡Le damos la bienvenida a la edición de enero del Informe de errores!

• CVE-2022-0185: los desarrolladores de Java no son los únicos que se olvidan de validar entradas.
• CVE-2021-42392: ¿de verdad creía que Log4shell iba a desaparecer así sin más?
• CVE-2022-21907: no te habíamos olvidado, gusanito lindo.
• CVE-2021-4034: PwnKit entra en escena cuando decide que con sudo no es suficiente.

CVE-2022-21907: vulnerabilidad tipo gusano en HTTP.sys.

¿Qué es?

El "martes de parches" (Patch Tuesday) de enero de 2022, Microsoft nos felicitó el nuevo año con una vulnerabilidad de tipo gusano en el controlador de kernel HTTP.sys. Se trata de la segunda de este tipo que se detecta en HTTP.sys en siete meses. Sorprende bastante teniendo en cuenta la madurez del código de este controlador. La vulnerabilidad CVE-2021-31166 no hizo que Internet saltara por los aires; ¡esperemos que ocurra lo mismo con la vulnerabilidad CVE-2022-21907! Esta aprovecha la corrección incompleta de la vulnerabilidad CVE-2021-31166, que aprovecha a su vez el soporte del encabezado HTTP Trailer (metadatos al final de un mensaje fragmentado). No queda claro si este exploit se basa en la presencia de un encabezado Trailer en el segmento final (RFC indica que es opcional). Para los redactores de firmas de productos de red, no poder confiar en el encabezado Trailer puede suponer un problema.

¿Sabía que...? Hay pruebas de concepto disponibles en GitHub al respecto.

Otro dato importante: ¡empezamos a ver explotaciones de esta vulnerabilidad en entornos reales. Si quiere estar al tanto de las amenazas actuales, considere seriamente recurrir a McAfee Insights.

Aunque podría parecer lógico que únicamente IIS utilice HTTP.sys, la realidad es bien distinta. HTTP.sys es el controlador de kernel que proporciona el código de gestión principal de HTTP. Hay otros subsistemas que usan este código:

• ADFS
• WinRM
• Intel Support Assistant

Puede consultar con qué servicios se está usando el controlador:

PS > netsh http show servicestate

Obtendrá una lista de las colas de solicitudes y las URL asociadas que se ejecutan en el sistema actual.

Por suerte, aquellos que no se han molestado en actualizar desde Windows Server 2019 o Windows 10 1809 están a salvo... a menos que hayan habilitado el soporte para trailers en el Registro.

¿A quién afecta?

A 2,4 millones de usuarios de Twitter. A cualquiera que ejecute IIS en su entorno. Todas aquellas personas que utilicen DocuSign (y no son pocas, porque pensemos en el número de documentos legales autentificados por DocuSign, especialmente desde el principio de la pandemia). Según un reciente informe de mercado, en torno a un 7 % de los sitios de Internet usan IIS. Ni siquiera Microsoft tiene tantos sistemas conectados a Internet, lo que significa que hay muchos otros sitios además de los de Microsoft que usan IIS. También afecta a todas las personas que utilicen versiones de Windows vulnerables por defecto:

• Windows 10 2004 y versiones posteriores (ARM y x64)
• Windows Server 20H2 y versiones posteriores

¿Qué puedo hacer?

¡Aplicar parches! Microsoft publicó un parche para esta vulnerabilidad junto con el anuncio. Si no puede aplicarlo, lo mejor sería retirar esos sistemas de roles conectados a Internet. Lamentablemente, no hay ninguna función de prevención basada en host disponible para las versiones actuales de Windows.

Si ejecuta Windows Server 1909 o Windows 10 1809, su sistema no es vulnerable por defecto. Para determinar el estado de vulnerabilidad, ejecute el comando:

PS > Get-ItemProperty "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" | Select-Object EnableTrailerSupport

Si se devuelve un valor que no es cero, el sistema es vulnerable. Para limitar los riesgos, ejecute el comando:

PS > Set-ItemProperty "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" -name EnableTrailerSupport -Value 0

O borre directamente esa clave del Registro.

La referencia

La parte positiva es que hay un parche disponible. ¡Asegúrese de aplicarlo! Si no puede aplicarlo, no se preocupe. Trellix le protege de esta vulnerabilidad con las firmas de NSP (Network Security Platform). Luego asegúrese de actualizar su base de datos de firmas.

CVE-2021-42392: una vulnerabilidad similar a Log4Shell afecta a H2

¿Qué es?

Esta vulnerabilidad es similar a Log4Shell en la gestión de la carga de clases remotas de JNDI. Aunque no se aprovecha del error en Log4j (ni siquiera hace falta), emplea la misma tecnología subyacente (JNDI). Cualquier URL controlada por un ciberdelincuente que consiga acceder a la base de datos puede lograr ejecutar código de forma remota en el contexto del componente RDBMS de H2. Por supuesto, usted no tiene nada que temer, ya que ha limpiado, parametrizado y almacenado todas las consultas en la base de datos. Lógicamente.

¿A quién afecta?

Se calcula que H2 se usa en casi 7000 proyectos, incluido Log4J. Le hace a uno preguntarse si el problema es realmente Log4jJ. En caso contrario, tal vez haya que rebautizar Log4Shell y que no preocupe solamente a los usuarios de Log4j. La naturaleza siempre se abre camino…

¿Qué puedo hacer?

Afecta a las versiones de la 1.1.100 a la 2.0.204 de las bases de datos de H2. La versión 2.0.206, que se lanzó el 5 de enero de 2022, corrige esta vulnerabilidad. Lo ideal sería actualizar al menos a la versión 2.0.206.

Podría cambiar los motores de las bases de datos, pero no parece que haya que ir tan lejos. Como en medicina, en TI tampoco se recomienda matar al huésped para curar la enfermedad.

También podría dejar de usar Java. Aunque parezca tan drástica como la medida anterior, en este caso está justificada. De hecho, es sin duda la mejor solución. Dejemos Java para el ámbito del café, no el de los servidores.

La referencia

Si no se pueden aplicar parches, desechar todo el código Java y cambiar a otro lenguaje o cambiar los motores de las bases de datos, puede contar con Trellix porque los propios exploits serán muy similares a los de Log4Shell.

Los clientes de Trellix están protegidos en distintos frentes (para obtener más información, lea este artículo de la base de datos de conocimientos):

• Las reglas de experto de la solución ENS (Endpoint Security) pueden identificar patrones peligrosos en la memoria, como se describe en este artículo de blog.
• Endpoint Security (ENS), VirusScan Enterprise (VSE) y Web Gateway (MWG) pueden proporcionar detección genérica con el nombre Exploit-CVE-2021-44228.C mediante la "detección de software potencialmente no deseado". Esta detección también se complementa con una lista de hashes de muestras relacionadas con campañas activas que explotan esta vulnerabilidad.
• Network Security Platform (NSP) también puede detectar el ataque mediante una firma definida por el usuario (incluida en el anterior artículo de la base de datos de conocimientos).
• Las soluciones MVISION Endpoint Detection and Response (EDR) y McAfee Active Response (MAR) también pueden utilizarse para buscar sistemas vulnerables mediante consultas de búsqueda en tiempo real (RTS, Real-Time-Search).
• Hay una actualización de la solución SIEM (Exploit Content Pack versión 4.1.0) que alertará de posibles intentos de explotación.

CVE-2022-0185: desbordamiento del espacio de nombres del kernel de Linux.

¿Qué es?

A simple vista, la vulnerabilidad CVE-2022-0185 es sencillamente un desbordamiento de enteros en una ruta de código heredada. Afortunadamente, para cualquiera que use contenedores, esa ruta está en la función Filesystem Context. Aunque se había sustituido por la API de Filesystem Context, se conservaron algunas de las funciones para admitir la retrocompatibilidad, incluida la ruta vulnerable. El desbordamiento de enteros permite a un ciberdelincuente escribir sin límites en el contexto del propio proceso del contenedor. Un agresor que tenga acceso a un contenedor puede explotar este fallo para atacar el host subyacente y así conseguir acceder al resto de contenedores que se ejecuten en este nodo. Dado el grado de popularidad que han alcanzado herramientas como Kubernetes (k8s), puede resultar preocupante en el caso de quien utilice contenedores para aislar procesos en presencia de usuarios que no sean de confianza. Este problema solo afecta a los contenedores que usan espacios de nombres sin privilegios, a los contenedores que permiten ejecutar el comando unshare o a los contenedores con el privilegio CAP_SYS_ADMIN (deshabilitado por defecto). El filtro seccomp bloquea de forma predeterminada el comando unshare en los contenedores Docker. No obstante, el filtro seccomp no está habilitado por defecto para los usuarios de k8s, lo que significa que cualquier clúster de Kubernetes está en peligro.

El pasado es un freno al progreso. O dicho de otro modo, la retrocompatibilidad raramente es un criterio que permita mejorar las cosas.

¿A quién afecta?

Todas las personas que ejecutan tecnología de contenedores. Incluso a los administradores que no los ejecutan, pero permiten que los usuarios lo hagan. Or even using a container to store leftovers in – ok, that may be taking it too far. Cualquier persona que ejecute un contenedor en un servidor compartido debería estar como mínimo muy preocupada, y debería eliminar preventivamente de ese servidor todo lo que sea de importancia crítica hasta que tenga la seguridad de que se ha actualizado el kernel subyacente.

Los autores han escrito un blog detallado y han publicado el código de prueba de concepto (PoC) para esta vulnerabilidad. Llegados a este punto, a todos debería preocuparnos, ya que es solo cuestión de tiempo que los ciberdelincuentes la exploten.

¿Qué puedo hacer?

Si es usted quien controla el host, debe actualizar el kernel. Si no hay forma de hacerlo (o el propietario se niega), ejecute el comando:

# sysctl -w kernel.unprivileged_userns_clone = 0

Esto limitará esta vulnerabilidad a los contenedores con el privilegio CAP_SYS_ADMIN. La eliminación de ese privilegio de sus contenedores también permitirá mitigar esta vulnerabilidad (está deshabilitado de forma predeterminada).

La recomendación de Red Hat para los sistemas que no ejecutan contenedores es directamente deshabilitar del todo los espacios de nombres:

# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf # sysctl -p /etc/sysctl.d/userns.conf

De esta forma también se anula la capacidad del host para ejecutar contenedores, lo cual, si no los usa, seguramente sea la mejor idea.

La referencia

En este punto, las mejores opciones son aplicar parches o tomar medidas de prevención. Dado que los contenedores se utilizan como mecanismo de aislamiento, es poco probable que un proceso externo tenga visibilidad de un contenedor en ejecución. Pero recuerde ejecutarlo en un host con parche o habilitar el filtro seccomp en k8s.

CVE-2021-4034: PwnKit

¿Qué es?

La vulnerabilidad CVE-2021-4034, apodada PwnKit, se aprovecha de un error lógico en PolKit (antes conocido como PolicyKit). PolKit es un kit de administración de directivas para todo el sistema que da a los procesos sin privilegios acceso seguro (o eso se creía) a los procesos con privilegios. El error se encuentra concretamente en la herramienta pkexec (porque por algún motivo con sudo no bastaba y necesitábamos otro programa setuid... para que hiciera exactamente lo mismo que sudo); se supone que la variable argc era superior o igual a 1. Es algo obvio que se da en la invocación típica de un programa. Toda explotación anormal debería identificarse como indicador de peligro y rechazarse en el tiempo de ejecución, pero desafortunadamente no es así.

En general, al usar pkexec normalmente aparece una ventana emergente en la que se solicitan las credenciales. Esta vulnerabilidad elude esa comprobación de credenciales y permite la ejecución como usuario root. ¡No parece que la mejor manera de proteger sea permitir el acceso total a quien aproveche el fallo!

Esta es la segunda vulnerabilidad de PolKit en seis meses. La vulnerabilidad CVE-2021-3560 también eludió la comprobación de credenciales mediante el mecanismo dbus para invocar PolKit. Parece que ambas aprovecharon el mismo error. Y al hilo de esto, la causa principal se señaló por primera vez en 2013, pero el autor no había identificado el riesgo de explotación. Así fue como el parche quedó abandonado y cayó en el olvido. Han pasado nueve años y por fin han llegado sus días de gloria. ¡Disfruta de tu momento, pequeño parche!

¿A quién afecta?

Sería difícil negar que este es el mayor error de escalación de privilegios locales del año pasado. Esta vulnerabilidad está presente en la mayoría de las grandes distribuciones de Linux en las que se ejecutan binarios de PolKit obsoletos, por lo que cualquier persona que ejecute Linux y que no haya aplicado el parche desde el 25 de enero es vulnerable. Los números de versiones de PolKit no son muy precisos, habida cuenta que Debian gestiona su propio fork, pero si ejecuta

• una versión inferior a 0.105-26ubuntu1.2 en Ubuntu 20.04 (LTS),
• inferior a 0.105-31ubuntu0.1 en Ubuntu 21.10,
• inferior a 0.105-31+deb11u1 en Debian Bullseye, o
• inferior a polkit-0.115-11.el8_4.2 en RedHat Enterprise Linux (RHEL) 8.4 EUS,

entonces es vulnerable. Insistimos: igualmente es vulnerable si no ha aplicado el parche desde el 25 de enero. También hay disponible código de prueba de concepto, por lo que es solo cuestión de tiempo antes de que se explote de forma activa.

¿Cómo dice? ¿Confía en todos sus usuarios? In that case, you have nothing to worry about. Compromised accounts are readily available. Confiar en los usuarios es una cosa, pero confiar en las cuentas de los usuarios es bien distinto, ya que pueden estar en peligro por phishing, descifrado de contraseñas, reutilización de contraseñas de otras cuentas u otros métodos de ataque.

Aunque este error se descubrió en Linux, hay otras distribuciones de UNIX que utilizan PolKit, incluidas las licencias BSD. Al menos OpenBSD ha contado siempre con recursos de prevención. Concretamente, rechaza la ejecución de programas con una variable argc de 0. Solaris también utiliza PolKit, pero Oracle mantiene tanto secretismo en torno a Solaris que incluso es necesario pagar para acceder a los boletines de seguridad. ¡No hay mejor manera de retener a tus clientes!

¿Qué puedo hacer?

¡Actualizar! No hay excusa alguna para no aplicar los parches pues se pueden conseguir a través de los principales proveedores de Linux. Y además se puede hacer sin necesidad de reiniciar. Si decide no aplicar el parche, puede eliminar el bit setuid de pkexec:

# chmod 0755 /usr/bin/pkexec

Desafortunadamente, también impedirá que pkexec cumpla su función principal. Pero, siempre es mejor eso que un ataque, ¿no?

Red Hat ha elaborado una guía de prevención específica para RHEL en su boletín de seguridad.

La referencia

Se trata de un lanzamiento coordinado de todas las distribuciones de Linux, por lo que debería aplicarse sin dudarlo. Conviene señalar que cualquier punto de origen de conexiones anómalas se debe registrar, marcar y quizá bloquear si carece de alguna otra forma de autenticación. Utiliza la autenticación multifactor, ¿verdad? La autenticación multifactor impide a las amenazas externas explotar esta vulnerabilidad, ya que bloquean su acceso al sistema. En cuanto a las amenazas internas... de este problema hablaremos en otra ocasión.