Vulnerabilidad crítica en Apache Log4j (Log4Shell)

Se ha corregido una vulnerabilidad de severidad crítica que afecta a Log4j que podría permitir la ejecución remota de código. Log4j es una utilidad de registro de código abierto basada en Java, ampliamente utilizada por aplicaciones empresariales y servicios en la nube.
Log4j (Apache)
Apache es uno de los programas más utilizados por los servidores de Internet. Cuando visitamos cualquier página web es muy probable que estemos conectado con una máquina que tenga instalado el servidor de HTTP Apache. Y dentro de Apache tenemos un software que se encarga de la gestión y control de los archivos de registro o LOGs. Un software que se llama Log4j.

Log4j es una biblioteca de código abierto desarrollada en Java por la Apache Software Foundation que permite a los desarrolladores de software escribir mensajes de registro, cuyo propósito es dejar constancia de una determinada transacción en tiempo de ejecución. Log4j permite filtrar los mensajes en función de su importancia. La configuración de salida y granularidad de los mensajes es realizada en tiempo de ejecución mediante el uso de archivos de configuración externos.

El 24 de noviembre del pasado 2021, investigadores independientes de seguridad informática informaron a Apache sobre una vulnerabilidad tipo ataque de día cero que permitía la ejecución de código arbitrario en Log4j, denominada Log4Shell que fue publicada a través de un tuit el 9 de diciembre de 2021. Los servicios afectados incluyeron Cloudflare, iCloud, Minecraft (Java Edition), Steam, Tencent QQ, y Twitter. La Apache Software Foundation asignó a la vulnerabilidad el nivel máximo de 10, por la posibilidad de que millones de servidores fueran potencialmente vulnerables a ciberataques.

La severidad crítica que afecta a Log4j podría permitir la ejecución remota de código. El procesador Log4j gestiona los mensajes de registro. Si un ciberdelincuente envía un mensaje especialmente diseñado, podría ejecutar código de forma remota. Esta vulnerabilidad podría estar ejecutándose de forma activa.

La vulnerabilidad apareció en las versiones de la 2.0-alpha1 hasta 2.16.0, y fue mitigada con la versión 2.17.0. Los usuarios y desarrolladores de los programas que usen la biblioteca deben actualizarla para obtener las actualizaciones de seguridad. El riesgo de esta vulnerabilidad es que es relativamente fácil explotarla, por lo que para las organizaciones es importante revisar si están expuestas a este riesgo, existen diferentes pruebas de concepto que muestran la vulnerabilidad que pueden servir de base para evaluar el riesgo.

En Log4J los mensajes son enviados a una (o varias) salida de destino, lo que se denomina un appender. Existen varios appenders disponibles y configurados, aunque también podemos crear y configurar nuestros propios appenders. Típicamente la salida de los mensajes es redirigida a un fichero de texto .log, a un servidor remoto donde almacenar registros, a una dirección de correo electrónico, e incluso en una base de datos. Casi nunca es utilizado en un entorno de producción la salida a la consola, ya que perdería gran parte de la utilidad de Log4J.

Por defecto Log4J tiene seis niveles de prioridad para los mensajes: trace, debug, info, warn, error y fatal. Además existen otros dos niveles extras, all y off. Estos son los niveles de prioridad (de menor a mayor):

  • OFF: Este es el nivel de mínimo detalle, deshabilita todos los logs.
  • FATAL: Se utiliza para mensajes críticos del sistema, generalmente después de guardar el mensaje el programa abortará.
  • ERROR: Se utiliza en mensajes de error de la aplicación que se desea guardar, estos eventos afectan al programa pero lo dejan seguir funcionando, como por ejemplo que algún parámetro de configuración no es correcto y se carga el parámetro por defecto.
  • WARN: Se utiliza para mensajes de alerta sobre eventos que se desea mantener constancia, pero que no afectan al correcto funcionamiento del programa.
  • INFO: Se utiliza para mensajes similares al modo «verbose» en otras aplicaciones.
  • DEBUG: se utiliza para escribir mensajes de depuración. Este nivel no debe estar activado cuando la aplicación se encuentre en producción.
  • TRACE: Se utiliza para mostrar mensajes con un mayor nivel de detalle que debug.
  • ALL: Sste es el nivel de máximo detalle, habilita todos los logs (en general equivale a TRACE).

Este proyecto de la Apache Software Foundation es uno de los varios Java Logging Frameworks existentes. Ademas, hay que destacar que el autor ha comenzado los proyectos SLF4J y Logback, con la intención de ofrecer un sucesor a Log4j.

Fuentes: Incibe y Wikipedia.