Crédito: Dreamstime
La Fundación Apache lanzó recientemente una emergencia actualizar para una vulnerabilidad crítica de día cero en Log4j, una herramienta de registro ubicua incluida en casi todas las aplicaciones Java. El problema se llamó Log4Shell y recibió el identificador CVE-2021-44228.
El problema gira en torno a un error en la biblioteca Log4j que podría permitir a un atacante ejecutar código arbitrario en un sistema que usa Log4j para escribir mensajes de registro. Esta vulnerabilidad de seguridad tiene un gran impacto y es algo a lo que cualquier persona con una aplicación que contenga Log4j debe prestar atención de inmediato.
Por qué abordar Log4Shell es un gran desafío
Log4j es una biblioteca utilizada por muchas aplicaciones Java. Es una de las bibliotecas de Java más extendidas hasta la fecha. La mayoría de las aplicaciones de Java registran datos y no hay nada que lo haga más fácil que Log4j.
El desafío aquí es encontrar Log4j debido a la forma en que funciona el empaquetado de Java. Es posible que los usuarios tengan Log4j oculto en algún lugar de su aplicación y ni siquiera lo sepan.
En el ecosistema de Java, las dependencias se distribuyen como archivos de archivo Java (JAR), que son paquetes que se pueden usar como una biblioteca de Java. Las herramientas de uso común, como Maven y Gradle, pueden agregar automáticamente archivos JAR a medida que los usuarios crean aplicaciones Java.
También es posible que un JAR contenga otro JAR para satisfacer una dependencia, lo que significa que una vulnerabilidad se puede ocultar varios niveles hacia abajo en una aplicación. En algunas situaciones, una dependencia atrae a cientos de otras dependencias, lo que hace que sea aún más difícil de encontrar.
Esencialmente, en el mundo de Java, los usuarios pueden tener un JAR anidado dentro de un JAR anidado dentro de un JAR. Esto crea muchas capas que deben investigarse. Es posible que solo mirar los archivos JAR que un proyecto extrae directamente no sea suficiente, ya que Log4j podría estar oculto dentro de otro archivo JAR.
Busque Log4j con herramientas de código abierto
Hay dos herramientas de código abierto lideradas por Ancla que tienen la capacidad de escanear una gran cantidad de formatos de dependencia empaquetados, identificar su existencia e informar si contienen vulnerabilidades. En este caso, lo que queremos es poder escanear archivos JAR, especialmente capas anidadas de archivos JAR.
Syft genera una lista de materiales de software (SBOM) y sujeción es un escáner de vulnerabilidades. Ambas herramientas pueden inspeccionar múltiples capas anidadas de archivos JAR para descubrir e identificar versiones de Log4j.
Syft también puede discernir qué versión de Log4j contiene una aplicación Java. El JAR de Log4j se puede incluir directamente en nuestro proyecto o se puede ocultar en una de las dependencias que hemos incluido. Por ejemplo, el uso de Syft para escanear este proyecto de muestra de Java muestra que incluye Log4j versión 2.14.1, que es vulnerable a Log4Shell.
Independientemente de la versión de Log4j que se incluya, es importante generar y almacenar un SBOM para mantener un registro de todo lo que se incluye en cualquier componente de software o aplicación entregada. Cuando se encuentra una nueva vulnerabilidad, como Log4Shell, es mucho más rápido buscar en un repositorio de SBOM que encontrar y verificar todas las aplicaciones Java.
Grype es un escáner que tiene la capacidad de decirnos qué vulnerabilidades específicas contiene el software. Cuando los usuarios agregan una dependencia a una aplicación, también pueden identificar las vulnerabilidades que contiene la dependencia, y así sucesivamente a través de varios niveles de anidamiento.
Grype puede escanear el software directamente o escanear el SBOM producido por Syft. Esto permite a los usuarios volver a escanear el SBOM en busca de nuevas vulnerabilidades, incluso después de que el software se haya implementado o entregado a los clientes.
Al escanear el mismo proyecto Java de muestra con Grype, se encuentra la vulnerabilidad Log4j y la identifica como una gravedad crítica.
Syft y Grype tienen la capacidad de escanear aplicaciones sin importar dónde se encuentren. Los usuarios pueden escanear un directorio en el disco, escanear una imagen de contenedor localmente o incluso escanear un contenedor en un registro remoto. También pueden escanear el código fuente antes de compilar o la aplicación final después de compilada.
Es importante verificar las aplicaciones durante cada etapa del desarrollo, solo porque una verificación del código fuente esté limpia no significa que la compilación final lo será. Incluso escanear después de la implementación es una buena idea. Es posible que los usuarios no hayan detectado una vulnerabilidad crítica de Log4j la semana pasada, pero pueden hacerlo esta semana.
Etiquetas Log4j
