La vulnerabilidad de Log4Shell: la maldición de 2021

Steve Povolny y Douglas McKee · 19 de enero de 2022

Descripción

El 9 de diciembre, se publicó en Twitter una vulnerabilidad (CVE-2021-44228) y en GitHub una prueba de concepto para la biblioteca de registro Log4j de Apache. El error ya se lo había comunicado a Apache Chen Zhaojun, del equipo de seguridad de Alibaba Cloud, el 24 de noviembre.

El impacto de esta vulnerabilidad puede ser masivo por su efecto en cualquier producto que tenga integrada la biblioteca Log4j en sus aplicaciones, incluidos los productos de almacenamiento de gigantes de Internet como Apple iCloud, Steam, Samsung Cloud y miles de productos y servicios adicionales. Este es solo el principio, ya que Java se utiliza intensivamente en aplicaciones que abarcan casi todos los sectores, pero hay precauciones y estrategias que las empresas pueden adoptar, como la protección proactiva para crear resiliencia y protegerse de estas amenazas modernas y prevalentes.

¿Qué es?

La vulnerabilidad existe debido al modo en que resuelve las variables la función JNDI (Java Naming and Directory Interface). Cuando se escribe una referencia JNDI en un registro, JNDI reúne todos los requisitos para resolver la variable. Para efectuar este proceso, descarga y ejecuta todas las clases remotas necesarias. Esto es así para las aplicaciones tanto servidor como cliente, ya que los principales requisitos para aprovechar la vulnerabilidad son un campo de entrada controlado por el agresor y la transmisión de esta entrada al registro.

Para organizar este ataque, el ciberdelincuente puede utilizar varias búsquedas JNDI diferentes. La búsqueda más frecuente observada en la actualidad tanto en las pruebas de concepto como en la explotación activa es el uso de LDAP; sin embargo, también son vectores posibles de ataque otras búsquedas, como RMI y DNS. Cabe señalar que los vectores de ataque LDAP/RMI simples solo funcionan con versiones más antiguas de JDK. Hay publicaciones que han probado métodos para sortear esta limitación y conseguir ejecutar código, aunque añaden complejidad al ataque.

Las vulnerabilidades de deserialización de objetos Java no son una nueva generación de vulnerabilidades o ataques. A esta vulnerabilidad pueden aplicársele anteriores investigaciones sobre estas ofensivas que simplifican la ejecución de código, como "marshalsec".

Evolución y medidas adoptadas

• El 14 de diciembre, se confirmó que la versión 1.2 de Log4j es vulnerable a ataques de este tipo a través del componente JMSAppender y se publicó CVE-2021-4104. Es importante señalar que no es tan fácilmente explotable como las versiones de la 2.0-alpha1 a la 2.16.0. Para poder aprovecharla, JMSAppender debe estar activado y la configuración de TopicBindingName o TopicConnectionFactoryBindingName debe permitir que JMSAppender realice solicitudes JNDI. Esta no es la configuración predeterminada.

Tras la confirmación, Apache publicó una nueva versión de Log4j, la 2.16.0. Esta actualización desactivaba JDNI de forma predeterminada, lo que requería que el usuario activara explícitamente la función JNDI, y eliminaba completamente la compatibilidad con búsquedas de mensajes.

• Después, el 18 de diciembre, se descubrió una nueva vulnerabilidad de denegación de servicio (DoS), CVE-2021-45105, que afectaba a las versiones desde la 2.0-alpha1 hasta la 2.16.0 de Log4j. Para mitigar la vulnerabilidad original de Log4j, Apache desactivó completamente las búsquedas JNDI en la versión 2.16.0, aunque en configuraciones no predeterminadas seguía siendo posible realizar búsquedas autorreferenciadas. Cuando una variable anidada se sustituye por la clase StrSubstitutor, esta llama recursivamente a la clase substitute(). Cuando esta variable anidada hace referencia recursivamente a la variable sustituida, conduce a una recursividad infinita y a una denegación de servicio en el servidor. Los estudios actuales muestran que esto no da lugar a la ejecución de código, como las vulnerabilidades anteriores.

A continuación, Apache lanzó una nueva versión de Log4j, la 2.17.0, para resolver la última vulnerabilidad DoS. A partir de StrSubstitutor se crearon dos clases adicionales para gestionar el análisis de las cadenas que pudieran contener entradas del usuario. Estas clases no permiten la evaluación recursiva. Dado que la explotación de esta vulnerabilidad provoca una denegación de servicio, se considera menos crítica que las vulnerabilidades de Log4j denunciadas previamente que sí pueden dar lugar a la ejecución remota de código.

Es importante resaltar que, para que la explotación tenga éxito, deben cumplirse varias condiciones no estándar. Teniendo en cuenta que la situación de Log4j sigue evolucionando, recomendamos actualizar a la versión 2.17.1 en la medida de lo posible y aprovechar el momento para revisar en general las estrategias de seguridad ahora que nos adentramos en este nuevo año.

Una mirada positiva al futuro

Hay mucha información sobre las diferentes formas de mitigar esta vulnerabilidad, con la posibilidad de que tanto personas como máquinas aprendamos a adaptarnos juntos a una estrategia de acción permanente. Las amenazas son cada vez más dinámicas y, para asegurar la optimización y la protección de empresas y operaciones, también deben serlo las estrategias y los procesos. Log4j representa una oportunidad viable para que las empresas dejen de considerar las amenazas un perjuicio inevitable y piensen en ellas como una oportunidad de crecimiento, aprendizaje y adaptación que genera resiliencia y supone una ventaja empresarial para avanzar.

Hemos seguido de cerca esta vulnerabilidad desde que se dio a conocer, ya que entendemos la importancia de que la seguridad sea un organismo vivo para estar a la altura de amenazas siempre cambiantes como Log4j. Nuestro objetivo inicial era determinar la facilidad de explotación de esta vulnerabilidad usando la prueba de concepto pública, que hemos reproducido y confirmado. Esto se llevó a cabo usando el contenedor Docker público y una arquitectura cliente-servidor que usa tanto LDAP como RMI, junto con la herramienta marshalsec, para explotar la versión 2.14.1 de Log4j .

En el futuro tenemos previsto probar variaciones del exploit distribuido utilizando servicios adicionales, como DNS. Mientras tanto, hemos publicado KB95088, una firma de red para clientes que utilizan NSP (Network Security Platform). La firma detecta los intentos de explotación de la vulnerabilidad CVE-2021-44228 a través de LDAP y puede ampliarse para incluir otros protocolos o servicios. Pueden publicarse otras firmas para complementar la cobertura.

¿Busca más recursos?

Encontrará información completa sobre esta vulnerabilidad en nuestro boletín de seguridad aquí y una lista creciente de pruebas de concepto y herramientas aquí:

• https://github.com/pedrohavay/exploit-CVE-2021-44228
• https://github.com/christophetd/log4shell-vulnerable-app
• https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22
• https://rules.emergingthreatspro.com/open/
• https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
• https://github.com/corretto/hotpatch-for-apache-log4j2
• https://github.com/nccgroup/log4j-jndi-be-gone