Fecha de publicación: 10/12/2021 Nivel de peligrosidad: CRÍTICO
El Equipo de Respuesta a Incidentes del Centro Criptológico Nacional, CCN-CERT, alerta de la publicación de una vulnerabilidad que afecta a Apache Log4j 2.
Se ha hecho pública una vulnerabilidad que afecta a la librería de registro de Java Apache Log4j 2, herramienta desarrollada por Apache Foundation que ayuda a los desarrolladores de software a escribir mensajes de registro, cuyo propósito es dejar constancia de una determinada transacción en tiempo de ejecución, además, Log4j permite filtrar los mensajes en función de su importancia.
La vulnerabilidad, a la que se le ha asignado el CVE-2021-44228 y denominada Log4Shell o LogJam, fue reportada el pasado 9 de diciembre por el ingeniero de ciberseguridad p0rz9, quien publicó un repositorio en GitHub anunciando su descubrimiento, así como una publicación en la red social Twitter en la que dio a conocer de manera pública la vulnerabilidad.
Imagen 1: Tweet haciendo público el descubrimiento de CVE-2021-44228
Una explotación exitosa de esta vulnerabilidad, que aprovecha una validación de entrada incorrecta al procesar solicitudes LDAP, podría permitir la ejecución remota de código (RCE), haciéndose cargo del servidor, por lo que se compromete por completo la confidencialidad e integridad de los datos, así como la disponibilidad del sistema.
Esta vulnerabilidad cobra relativa importancia puesto que Log4j 2 se usa ampliamente en muchas aplicaciones y está presente, como dependencia, en muchos servicios, incluyendo aplicaciones empresariales y servicios en la nube como Steam o Apple iCloud.
En adición a lo anterior, destacar que la librería Log4j 2 se utiliza con mucha frecuencia en el software empresarial Java. Debido a esta metodología de implementación, el impacto de esta vulnerabilidad es difícil de cuantificar. De manera similar a otras vulnerabilidades de perfil alto, como Heartbleed y Shellshock, se espera que se descubran un número cada vez mayor de productos vulnerables en las próximas semanas. Debido a la facilidad de explotación y la amplitud de la aplicabilidad, no sería de extrañar que los actores de ransomware comenzarán a aprovechar esta vulnerabilidad de inmediato.
La base de datos del NIST ha registrado esta vulnerabilidad, pero por el momento, no se le ha asignado puntuación de acuerdo a la escala CVSSv3. No obstante, ha sido calificada como crítica por su gran impacto en diversos sectores y porque se encuentran disponibles en Internet exploits accesibles para aprovechar esta vulnerabilidad. Además, se ha hecho pública una prueba de concepto disponible en el siguiente enlace:
Por último, el jefe de investigación de Nextron Systems, Florian Roth, ha compartido un conjunto de reglas YARA para detectar intentos de explotación de esta vulnerabilidad:
Recursos afectados:
La vulnerabilidad reportada afecta a las siguientes versiones:
- Apache Log4 desde la versión 2.0 hasta la versión 2.14.1.
Solución a la vulnerabilidad:
Apache ha lanzado la versión Log4j 2.15.0 para abordar esta vulnerabilidad. Para más información sobre cómo instalar las actualizaciones y los distintas extensiones se dispone del siguiente enlace:
Recomendaciones:
Se recomienda encarecidamente a los usuarios y administradores de sistemas que apliquen los parches de seguridad en cuanto se encuentren disponibles, con el fin de evitar la exposición a ataques externos y la toma de control de los sistemas informáticos.
La vulnerabilidad también se puede mitigar en versiones anteriores (sólo versión 2.10 y posteriores) estableciendo la propiedad del sistema "log4j2.formatMsgNoLookups" en "true" o eliminando la clase JndiLookup del classpath.
Si se está utilizando una versión anterior a la 2.10.0 y no se puede actualizar, existen dos opciones de mitigación:
- Modificar el diseño de cada patrón de registro para cambiar %m{nolookups} por %m en los archivos de configuración de registro. En esta publicación se describen más a fondo los pasos a seguir.
- Sustituir una implementación vacía o no vulnerable de la clase apache.logging.log4j.core.lookup.JndiLookup, de manera que su cargador de clases use el reemplazo en lugar de la versión vulnerable de la clase.
Referencias:
Atentamente,
Equipo CCN-CERT
|