2021 fue un año muy intenso para las vulnerabilidades de día cero que tuvieron su coronación con Log4Shell, un fallo crítico encontrado en la biblioteca de inicio de sesión con base en Java, Apache Log4j, ampliamente utilizada. Oficialmente identificada como CVE-2021-44228, el Common Vulnerability Scoring System (CVSS) le otorga una puntuación de gravedad de 10 en una escala de 10 (CVSS v3.1).
A pesar de que la cantidad de ataques divulgados públicamente, un año después Log4j continúa presentando una gran amenaza para las organizaciones empresariales porque un alto porcentaje de sistemas aún permanecen sin parches contra el fallo. Además, y según un estudio de Tenable, las organizaciones enfrentan desafíos para encontrar y remediar el problema y evitar que el fallo se vuelva a introducir en el entorno.
Según los datos del informe de Tenable, el 70% de las organizaciones siguen siendo vulnerables a Log4Shell.
Los comienzos
En un primer momento la vulnerabilidad se comunicó de forma privada a Apache, concretamente el 24 de noviembre de 2021. Poco después, el 9 de diciembre de 2021, Log4Shell se divulgó públicamente y se lanzó un parche inicial con la versión 2.15.0 de Apache Log4j. Enseguida se detectó que los ciberdelincuentes estaban explotando la vulnerabilidad lo que llevó a que multitud de agencias de ciberseguridad emitieran alertas.
A raíz de la publicación de la vulnerabilidad, Apache lanza una actualización que corrige el fallo. Sin embargo, se descubren otras vulnerabilidades asociadas a diferentes versiones de Log4j. En total, son cuatro las vulnerabilidades relacionadas con este suceso.
En España, INCIBE publicaba un artículo en el que se analizaba el problema. Entre otras cosas, explica el Instituto de Ciberseguridad que, para explotar esta vulnerabilidad con éxito se realiza una petición HTTP al servidor víctima con datos que contengan valores especialmente diseñados. El servidor víctima debe estar usando la librería de Java Log4j para la gestión de los logs. Aunque se esté explotando activamente a través de servidores web un servidor es vulnerable siempre que reciba unos datos controlados por el usuario y los pase por la librería Log4j.
La vulnerabilidad Log4j (CVE-2021-44228), más conocida como Log4Shell, existe en la función Java Naming and Directory Interface (JNDI) de Log4j para almacenamiento y recuperación de datos. El fallo permite a los atacantes remotos tomar el control de los sistemas vulnerables; que Log4J se utilice en prácticamente todos los entornos de aplicaciones Java convierte a esta vulnerabilidad en una de las más importantes de los últimos años debido a su prevalencia y la relativa facilidad con la que los atacantes pueden explotarla.
Persistencia
Un gran porcentaje de organizaciones siguen siendo tan vulnerables a la amenaza como lo eran hace un año. Así lo pone de manifiesto un análisis de telemetría relacionado con la vulnerabilidad y llevado a cabo por Tenable que reflejó que el 72% de las organizaciones eran vulnerables a Log4j.
Según datos de la compañía, el 28% de las organizaciones en todo el mundo habían parcheado sus sistemas, a pesar de lo cual a menudo se encontraban con Log4j una y otra vez a medida que agregaban nuevos activos a sus entornos.
De hecho, el 29% los servidores, aplicaciones web, contenedores y otros activos se volvieron vulnerables a Log4j poco después de la reparación inicial.
Explican desde Tenable que las versiones vulnerables de Log4j siguen siendo muy difíciles de encontrar en muchas organizaciones debido a cómo lo utilizan las aplicaciones. Algunas aplicaciones pueden usar el componente de registro de código abierto como una dependencia directa en sus aplicaciones y, en otros casos, una aplicación puede usar Log4j como una dependencia transitiva, o una dependencia de otra dependencia.
Por otra parte, el estudio también recoge que algunas industrias están en mejor forma que otras: ingeniería (45%), servicios legales (38%), servicios financieros (35%), organizaciones sin fines de lucro (33%) y gobierno (30%) están a la cabeza con la mayoría de las organizaciones totalmente remediado. Aproximadamente el 28% de las organizaciones de infraestructura crítica definidas por CISA se han remediado por completo.
Por poner un punto positivo a esta situación, los investigadores aseguran que el fallo ha mejorado la atención que las empresas han prestado a prácticas como el análisis de composición de software y el SBOM, o software bill of materials. Los desafíos que las organizaciones han enfrentado al determinar si son vulnerables o dónde podría existir la vulnerabilidad en su entorno han fomentado una mejor comprensión de la necesidad de visibilidad de todos los componentes en su base de código, especialmente aquellos de código abierto y fuentes de terceros.
