Descubren una vulnerabilidad de alta gravedad en Log4j 2.16 (CVE-2021-45105)

Durante la noche, Apache informó que Log4j versión 2.16 también es vulnerable a un ataque de denegación de servicio que puede provocar el bloqueo total de la aplicación. La gravedad se clasifica como alta (7.5). Actualmente, Snyk no tiene conocimiento de pruebas de concepto completamente desarrolladas ni de exploits en circulación. Se asignó el identificador CVE-2021-45105 y Apache publicó una nueva versión corregida (2.17.1), a la que recomendamos actualizar.

El equipo de investigación de Snyk sigue de cerca la dinámica situación de Log4j y continuará proporcionando detalles sobre las vulnerabilidades en cuanto tengamos información.

¿Debería actualizar a la nueva versión?

Siempre es importante eliminar las vulnerabilidades de tus aplicaciones, pero como ya han aparecido varias en la biblioteca Log4j, conviene poner esta en perspectiva. Esta es una vulnerabilidad de denegación de servicio, no de ejecución de código arbitrario como las dos anteriores, por lo que el riesgo potencial es menos grave. Lo más importante es la posibilidad de explotación. Las dos vulnerabilidades anteriores eran claramente explotables, con ejemplos de exploits maduros y funcionales que lo demostraban. Aunque esta nueva vulnerabilidad de denegación de servicio podría explotarse, con los datos disponibles al momento de escribir esto no está claro qué tan fácil o común sería.

En resumen, si puedes y tienes tiempo para corregir esta vulnerabilidad, deberías actualizar a la versión 2.17.1. Sin embargo, es más importante asegurarte de que todas tus versiones de Log4j sean, como mínimo, la 2.16.0 para mitigar el riesgo de ejecución de código arbitrario, antes de actualizarlas todas a la 2.17.1. Si todavía tienes servicios pendientes de actualización, conviene pasar directamente a la versión más reciente, 2.17.1, para corregir todos los problemas de Log4j que se han divulgado recientemente.

¿Por qué aparecieron tantas vulnerabilidades de Log4j de repente?

Si te preguntas por qué se están divulgando vulnerabilidades y publicando versiones nuevas de esta biblioteca tan rápidamente, es importante entender el contexto completo de lo que está pasando y por qué es lógico que se hayan publicado —y quizá se sigan publicando— nuevas actualizaciones.

1. Mayor exposición ante la comunidad: la divulgación inicial de la vulnerabilidad crítica de ejecución remota de código en Log4j atrajo a toda la comunidad al proyecto. Por eso, muchos errores que quizá habían pasado desapercibidos ahora están saliendo a la luz gracias al trabajo de la comunidad de código abierto de Java. Esta exposición también se ha extendido a otros proyectos similares, a veces con resultados dispares, ya que el afán por ayudar a divulgar posibles vulnerabilidades se adelanta al consenso de la comunidad.

2. Corrección de seguridad inicial apresurada: aunque todavía se están esclareciendo los acontecimientos exactos que llevaron a la divulgación de CVE-2021-44228, parece que no se respetó estrictamente el periodo habitual de divulgación responsable, ya que los detalles de esta vulnerabilidad se filtraron al público antes de que hubiera una corrección completa. El equipo de Apache tuvo que publicar una corrección lo antes posible. Esto llevó a identificar vectores de ataque y problemas adicionales, lo que dio lugar a las versiones posteriores.

3. Compatibilidad con versiones anteriores: Log4j es un componente esencial del ecosistema Java. Toda versión nueva debe mantener la compatibilidad con las anteriores para evitar interrupciones innecesarias que podrían impedir que los usuarios actualicen a una versión nueva y segura. Por desgracia, este enfoque necesario y prudente implica que no se puede modificar por completo la funcionalidad principal. Por lo tanto, podrían existir vectores de ataque adicionales o soluciones alternativas que no se detectaron al publicar la corrección y que podrían salir a la luz a medida que la comunidad siga analizando el panorama de amenazas.

¿Qué puedo hacer para que esto sea más fácil en adelante?

En vista de este contexto, es probable que veamos más vulnerabilidades y versiones nuevas correspondientes en un futuro cercano. Es importante que los usuarios de Log4j (y de otros paquetes de código abierto) estén preparados para esta posibilidad. Estas son algunas prácticas recomendadas para mejorar tu programa de seguridad de aplicaciones y facilitar la gestión de estos incidentes de día cero:

• Analiza el código a diario para encontrar las vulnerabilidades más recientes en código administrado e incluso no administrado

• Crea una SBOM para llevar el control de tu cadena de suministro de software

• Configura pipelines automatizados de CI/CD y DevOps con seguridad de aplicaciones integrada

• Siempre que sea posible, mantén buenas prácticas con el código abierto actualizando a versiones más recientes de los paquetes. Así, será más fácil aplicar las correcciones de seguridad urgentes y se reducirán los problemas de compatibilidad en tu proyecto.

Síguenos en LinkedIn, Twitter o Facebook para estar al tanto de las últimas noticias sobre Log4Shell y otras vulnerabilidades críticas.