Log4Shell es uno de los que aparecerán en las filtraciones de datos durante la próxima década

Este último mes del año 2023 marco el segundo aniversario del descubrimiento de la vulnerabilidad Log4j/Log4Shell, la cual es una vulnerabilidad que al día de hoy continua afectado a muchos proyectos y supone un riesgo de seguridad.

Y es que Log4j sigue siendo un blanco principal para los ciberataques, según el informe anual «Year in Review» de Cloudflare y también los resultados de un estudio sobre la relevancia de las vulnerabilidades críticas en la biblioteca Java Log4j que dieron a conocer investigadores de seguridad de Veracode.

Los investigadores de Veracode mencionan que después de estudiar 38.278 aplicaciones utilizadas por 3.866 organizaciones, descubrieron que dos de cada cinco aplicaciones aún utilizan versiones vulnerables de la biblioteca Apache Log4j, dos años después de que se hiciera pública una vulnerabilidad crítica.

El informe destaca que cerca de un tercio de las aplicaciones ejecutan Log4j2 1.2.x (que alcanzó el final de su vida útil en agosto de 2015 y ya no recibe actualizaciones de parches) lo que representa un 38%. La razón principal para continuar usando código heredado es la integración de bibliotecas antiguas en proyectos o la laboriosidad de migrar de ramas no compatibles a nuevas ramas que son compatibles con versiones anteriores. Además, un 2.8% de las aplicaciones aún utilizan versiones vulnerables a la conocida vulnerabilidad Log4Shell.

Además de ello, se menciona que existen tres categorías principales de aplicaciones que aún utilizan versiones vulnerables de Log4j, según el informe de Veracode:

1. Vulnerabilidad Log4Shell (CVE-2021-44228):
   El 2.8% de las aplicaciones persisten a seguir utilizando versiones de Log4j desde la 2.0-beta9 hasta la 2.15.0, las cuales contienen la vulnerabilidad conocida.
2. Vulnerabilidad de Ejecución Remota de Código (RCE) (CVE-2021-44832):
   Un 3.8% de las aplicaciones emplean la versión Log4j2 2.17.0, que aborda la vulnerabilidad Log4Shell, pero no resuelve la vulnerabilidad de ejecución remota de código (RCE) identificada como CVE-2021-44832.
3. Rama Log4j2 1.2.x (Soporte Finalizado en 2015):
   Un 32% de las aplicaciones aún utilizan la rama Log4j2 1.2.x, cuyo soporte finalizó en 2015. Esta rama se ha visto afectada por vulnerabilidades críticas, como CVE-2022-23307, CVE-2022-23305 y CVE-2022-23302, identificadas en 2022, siete años después de finalizado el mantenimiento.

Estos datos resaltan la diversidad de situaciones en las que las aplicaciones continúan utilizando versiones desactualizadas y vulnerables de Log4j, lo que genera una gran preocupación por parte de los investigadores.

Y es que un dato preocupante es que el 3.8% de las aplicaciones utilizan Log4j2 2.17.0, que fue parcheado contra Log4Shell, pero contiene CVE-2021-44832, otra vulnerabilidad de ejecución remota de código de alta gravedad.

El informe subraya que, a pesar de los esfuerzos realizados en los últimos años para mejorar las prácticas de seguridad en el desarrollo de software y el uso de código abierto, queda trabajo por hacer.

Chris Eng, director de investigación de Veracode, destaca que:

Los desarrolladores tienen una responsabilidad crucial y que hay margen de mejora en cuanto a la seguridad del software de código abierto.

Aunque muchos desarrolladores inicialmente respondieron adecuadamente a la crisis de Log4j instalando la versión 2.17.0, el informe sugiere que algunos volvieron a patrones anteriores al no aplicar parches más allá del lanzamiento de 2.17.1.

La Apache Software Foundation (ASF) ha estado activamente notificando a los proyectos downstream sobre la urgencia de actualizar, pero los hallazgos del informe indican que aún hay aplicaciones que no han implementado las correcciones necesarias.

El informe de Veracode se basó en datos de escaneos de software de más de 38,000 aplicaciones durante un período de 90 días, entre el 15 de agosto y el 15 de noviembre. Las aplicaciones ejecutaban versiones de Log4j desde la 1.1 hasta la 3.0.0 alfa 1 en 3,866 organizaciones diferentes.

Nuestra investigación también encontró que una vez que los desarrolladores son alertados sobre una biblioteca vulnerable a través de un análisis, las solucionan relativamente rápido: el 50 por ciento de las vulnerabilidades se solucionan en 89 días en general, en 65 días para las vulnerabilidades de gravedad alta y en 107 días para las vulnerabilidades de gravedad media.

Estos resultados concuerdan con las advertencias previas, como el informe de la Junta Federal de Revisión de Seguridad Cibernética de 2022, que indicó que la crisis de Log4j tomaría años en resolverse por completo.

Finalmente si estás interesado en poder conocer más al respecto, te invito a que visites el artículo original del blog de veracode. El enlace es este.