Alcance

Esta vulnerabilidad es explotable desde un shell de linux ejecutándose en un contenedor de Kubernetes. No es un primer paso en la cadena de exploits, pero hace trivial un escalado de capabilities de kernel una vez en el container, lo cual implica un mayor riesgo en workloads en Kubernetes que tienden a tener software vulnerable (como los plugins de un CRM o CMS populares) permitiendo así continuar una cadena de exploits más peligrosa. Todas las versiones de Kernel desde 5.1-rc1 están afectadas hasta los últimos parches (5.4.173, 5.10.93, 5.15.1), pero las grandes distribuciones ya están publicando parches de mitigación a sus repositorios.

Indicadores de compromiso

Actualmente no se conocen indicadores de compromiso claros de esta vulnerabilidad, pero una posible pista es revisar los procesos ejecutándose en un sistema y ver si alguno tiene más capabilities de kernel de las que debería.

Parches y mitigaciones

Las grandes distribuciones de Linux (Debian, Ubuntu, CentOS) ya están publicando kernel patches que resuelven esta vulnerabilidad y deberían aplicarse a los nodos del cluster a la mayor brevedad posible. Si la distribución de los nodos basada en debian aún no tiene parche disponible, esta vulnerabilidad se puede mitigar desactivando los kernel namespaces no privilegiados:

sysctl -w kernel.unprivileged_userns_clone=0

Des esta manera los contenedores sólo podrán escalar privilegios de kernel si tienen el flag de Privileged (Esto es por diseño, working as intended).

Fuentes

https://www.bleepingcomputer.com/news/security/linux-kernel-bug-can-let-hackers-escape-kubernetes-containers/

https://sysdig.com/blog/cve-2022-0185-container-escape/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0185

Geko Cloud

Geko Cloud Consulting estamos al día de cualquier incidencia o vulnerabilidad. Si quieres tener tus datos seguros, nos necesitas!

La entrada Incidente de seguridad sobre escape de contenedores en Kubernetes usando un kernel bug se publicó primero en Geko Cloud.

Se ha detectado un problema de seguridad grave la herramienta de terminal pkexec que controla escalado de privilegios en terminales linux y que viene pre-instalada en todas las grandes distribuciones de Linux como Debian CentOS o Ubuntu. Esta vulnerabilidad permite a los usuarios con una sesión de terminal de privilegios limitados escalar a privilegios totales en el sistema. Es una vulnerabilidad trivialmente explotable que ya tiene pruebas de concepto funcionales en circulación. Todas las versiones de pkexec desde su lanzamiento en 2009 son vulnerables, pero las distribuciones ya están empezando a distribuir parches en sus repositorios.

Alcance

Esta vulnerabilidad es explotable desde cualquier sesión de usuario en una terminal de Linux. No implica un primer paso en una cadena de explotación de vulnerabilidades, pero hace trivial el paso de escalado de privilegios, con lo cual  puede suponer un mayor riesgo en sistemas expuestos a Internet o con software proclive a tener vulnerabilidades (como por ejemplo algunos CRM/CMS populares) y por tanto aumentar la peligrosidad y alcance de otras vulnerabilidades. Todas las versiones de pkexec desde su lanzamiento en 2009 son vulnerables, pero las distribuciones ya están empezando a distribuir parches en sus repositorios.

Indicadores de compromiso

Un posible indicador de compromiso que se ha detectado son entradas de log con el texto “The value for the SHELL variable was not found the /etc/shells file”. Buscar este texto en los logs de sistema puede ser una traza de que la vulnerabilidad ha sido explotada en el sistema donde se analizan los registros.

Parches y mitigaciones

Todas las versiones de pkexec desde su lanzamiento en 2009 son vulnerables, pero las distribuciones ya están empezando a distribuir parches en sus repositorios. Se puede actualizar este paquete desde el gestor de paquetes de la máquina para parchear la vulnerabilidad. Si la distribución que se usa aún no ha publicado un parche, se puede desactivar el escalado de privilegios del binario desactivando su bit de SUID: chmod 0755 pkexec

Fuentes

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4034

https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt

https://isc.sans.edu/diary/rss/28272

Geko Cloud

En Geko Cloud somos expertos cloud y trabajamos con metodología DevOps, acompañando a nuestros clientes en todo el proceso desde la migración hasta la gestión en el cloud. ¡Contáctanos sin ningún compromiso!

La entrada Incidente de seguridad con la herramienta de escalado de privilegios pkexec se publicó primero en Geko Cloud.

Existe la posibilidad de desactivar la función que permite esta vulnerabilidad (JNDI) con variables de entorno en algunas versiones de la librería, pero la solución permanente a este problema consiste en actualizar a la versión de log4j 2.17.0.

Alcance

Esta vulnerabilidad tiene un alcance muy extendido a través de muchas aplicaciones utilizadas el stack técnico de muchas empresas modernas. Entre ellas podemos contar los productos de Elastic. Si bien varias de sus productos hacen uso de versiones vulnerables de Log4j, de acuerdo al desarrollador algunos de sus ellos, como por ejemplo Elasticsearch, no son vulnerables debido al uso que hacen de Java Security Manager.

La lista completa, en proceso de actualización, puede verse en el github de CISA. Esta lista se irá actualizando según van apareciendo nuevas afectaciones.

Mitigación y threat hunting

Es posible mitigar esta vulnerabilidad desactivando la función de JNDI que hace posible esta vulnerabilidad desactivándola con una variable de entorno para las aplicaciones que la utilizan, o eliminando la librería del archivo de Java que la contiene directamente para que sea imposible de explotar. Estos son parches puntuales, y la solución definitiva en el roadmap debería consistir en actualizar la versión de la librería utilizada a log4j 2.17.0.

Se pueden investigar indicadores de compromiso y comprobar la posible existencia de esta librería sin parchear en el sistema con una herramienta de escaneo que se ha desarrollado que recoge indicadores de compromiso frecuentes, y como último paso escanea la existencia de esta librería de log4j en el sistema donde se lance. También pueden ser de utilidad escaners de rootkits como rkhunder o chkrootkit para intentar determinar si el sistema ha sido comprometido.

En cualquier caso, si hubiera sospecha de que el sistema ha sido comprometido, y dado que una vez un atacante tiene acceso al sistema no es posible comprobar con total seguridad si ha dejado un backdoor, desde Geko Cloud aconsejamos destruir y recrear la máquina afectada.

Actualización 1: 2021-12-14

Se ha descubierto que el fix publicado por Apache en log4j 2.16.0 era incompleto en algunas configuraciones no estándar, y que aún permitía explotar la vulnerabilidad de ejecución de código remota en la librería. Se recomienda actualizar a la versión 2.17.0 a la mayor brevedad posible para evitar esta vulnerabilidad.

La entrada Incidente de seguridad con la librería de logging log4j de Java se publicó primero en Geko Cloud.

Este problema consiste en que los clientes identificarán incorrectamente los certificados válidos correctos como inválidos, porque la CA en la que se basan ahora no es válida y el software del cliente no se actualizó para confiar en la nueva CA, por lo que ahora está dando estos problemas de autenticación. Hemos identificado que esto es un problema con clientes de software más antiguos como curl, o versiones más antiguas de lenguajes de programación como php que no tienen esta CA instalada en ellos y, por lo tanto, no pueden acceder a los clientes con certificados de letsencrypt.

Alcance

Versiones de software afectadas (aunque seguimos detectando nuevos comportamientos anómalos):

– OpenSSL <= 1.0.2
– Windows <XP SP3
– macOS <10.12.1
– iOS <10 (iPhone 5 es el modelo más bajo que puede llegar a iOS 10)
– Android <7.1.1 (pero> = 2.3.6 funcionará si se sirve el signo cruzado de ISRG Root X1)
– Mozilla Firefox <50
– Ubuntu <16.04
– Debian <8
– Java 8 <8u141
– Java 7 <7u151
– NSS <3,26
– CDN como CloudFlare
– Amazon FireOS (navegador Silk)

Este es un efecto que no solo pueden sentir los usuarios o las aplicaciones cliente, sino también la propia aplicación. Por ejemplo, si su aplicación se ejecuta en un sistema que usa una versión inferior a la detallada anteriormente, como un servidor web con openssl 1.0.1, las solicitudes a cualquier servicio respaldado por letsencrypt fallarán.

Remediación

La solución a este problema es actualizar la versión de cliente de la pila de software para que confíe en la nueva CA raíz como una solución completa. También puede parchear el problema modificando su software para que no verifique la validez de la CA, aunque tenga en cuenta que esta debe ser una solución temporal, ya que es una práctica de software insegura y no debe dejarse aplicada en un entorno de producción. más tiempo del necesario.

Aquí hay más información técnica sobre este problema:
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

La entrada Incidente con el certificado CA en Let’sEncrypt se publicó primero en Geko Cloud.