Log4j es un marco de registro desarrollado por Apache Software Foundation. Como su nombre indica, Log4J es un registrador. Registra información importante como mensajes de error y entradas de usuario en un programa.

Log4J es una biblioteca de software de código abierto, un paquete de código preescrito que los desarrolladores pueden utilizar libremente.En lugar de escribir sus propios registradores, los desarrolladores pueden incorporar la biblioteca Log4J a sus aplicaciones.Esta comodidad es la razón por la que Log4J está tan extendido, integrado en productos de grandes organizaciones como Microsoft y Amazon, por nombrar algunas.

Log4Shell (Common Vulnerability and Exposure Identifier CVE-2021-44228) es una vulnerabilidad de ejecución remota de código (RCE) presente en algunas versiones de Log4j.El fallo afecta a Apache Log4J 2, versiones 2.14.1 y anteriores.Log4J 2.15 y versiones posteriores, así como todas las versiones de Apache Log4J 1, no se ven afectadas.

Log4Shell se basa en la forma en que las versiones anteriores de Log4J 2 gestionaban las búsquedas JNDI (Java Naming and Directory Interface).JNDI es una interfaz de programación de aplicaciones (API) que utilizan las aplicaciones Java para acceder a los recursos alojados en servidores externos. Una búsqueda JNDI es un comando que indica a la aplicación que vaya a un servidor y descargue un objeto específico, como un dato o un script. Las versiones anteriores de Log4J 2 ejecutan automáticamente cualquier código descargado de esta manera. 

Los usuarios pueden enviar búsquedas JNDI a versiones vulnerables de Log4J incluyéndolas en mensajes de registro.Es un proceso muy sencillo. Por ejemplo, en versiones anteriores de Minecraft Java Edition, que utilizan Log4J para registrar los mensajes de usuario, un usuario puede escribir la búsqueda JNDI en la ventana de chat pública.

Los hackers pueden usar esta funcionalidad JNDI para ejecutar código malicioso y arbitrario de forma remota. En primer lugar, el hacker configura un servidor utilizando un protocolo común, como el Protocolo Ligero de Acceso a Directorios (LDAP) para evitar llamar la atención.A continuación, almacena una carga maliciosa en ese servidor, como un archivo malware. Por último, envía una búsqueda JNDI a un programa, indicándole que vaya al servidor LDAP del atacante, descargue la carga útil y ejecute el código.

Investigadores de seguridad del gigante tecnológico Alibaba descubrieron Log4Shell el 24 de noviembre de 2021.Inmediatamente recibió la máxima puntuación posible de Common Vulnerability Scoring System (CVSS): 10 sobre 10.Algunos factores contribuyeron a esta calificación.

• Log4Shell fue una vulnerabilidad de día cero, lo que significa que no había ningún parche disponible cuando se descubrió.Los actores de amenazas podían aprovecharse de Log4Shell mientras Apache trabajaba en una solución.
  
  
• Log4J también es una de las bibliotecas de registro más utilizadas, integrada en puntos finales de consumo, aplicaciones web y servicios empresariales en la nube. Según Wiz y EY, el 93 % de todos los entornos de nube estaban en riesgo (enlace externo a ibm.com) cuando se descubrió Log4Shell.
  
  
• Las empresas no siempre pueden decir de inmediato si son vulnerables. Log4j suele estar presente en las redes como dependencia indirecta, lo que significa que los activos de la empresa no utilizan necesariamente Log4j, pero pueden depender de otras aplicaciones y servicios que sí lo hacen.
  
  
• Por último, Log4Shell es muy fácil de explotar. Los hackers no necesitan permisos especiales ni autenticación. Pueden causar estragos tecleando comandos maliciosos en formularios públicos como cuadros de chat y páginas de inicio de sesión.Y como Log4J puede comunicarse con otros servicios del mismo sistema, los hackers pueden utilizar Log4J para pasar cargas útiles a otras partes del sistema.

El 9 de diciembre de 2021, se publicó en GitHub un código de prueba de concepto sobre cómo explotar Log4Shell, y los piratas informáticos estaban montando ataques.Importantes empresas y servicios como Minecraft, Twitter y Cisco quedaron expuestos.En el punto álgido de la actividad de Log4Shell, Check Point observó más de 100 ataques cada minuto, afectando a más del 40% de todas las redes empresariales del mundo (enlace externo a ibm.com).

Los primeros ataques propagaron botnet y malware de minería de criptomonedas.Algunos hackers utilizaron el fallo para lanzar ataques sin archivos, enviando scripts maliciosos a ordenadores con Windows y Linux para obligarles a divulgar contraseñas y otra información sensible.

Múltiples bandas de ransomware se apoderaron de Log4Shell. En particular, los hackers propagaron la cepa de ransomware Khonsari a través de Minecraft. El ransomware Night Sky se dirigió a sistemas que ejecutan VMware Horizon.

Incluso los Estados-nación se han unido al movimiento. Se ha visto a hackers asociados con China, Irán, Corea del Norte y Turquía aprovecharse de la vulnerabilidad.

Apache lanzó el primer parche (Log4J versión 2.15.0) el 10 de diciembre de 2021.Sin embargo, ese parche dejaba expuesta otra vulnerabilidad (CVE-2021-45046) que permitía a los hackers enviar comandos maliciosos a registros con determinadas configuraciones no predeterminadas.

Apache publicó un segundo parche (Log4J versión 2.16.0) el 14 de diciembre de 2021. También tenía un fallo (CVE-2021-45105) que permitía a los hackers lanzar ataques de denegación de servicio (DoS).

El tercer parche, Log4J versión 2.17, corregía el fallo DoS pero dejaba una última vulnerabilidad (CVE-2021-44832) que permitía a los hackers hacerse con el control de un componente de Log4J llamado "appender" para ejecutar código remoto.Apache solucionó este problema con un cuarto y último parche, Log4J versión 2.17.1. 

Aunque Log4J 2.17.1 cerró Log4Shell y todas sus vulnerabilidades relacionadas por parte de Apache, las ciberamenazas siguen utilizando el fallo.Hasta mayo de 2023, Log4Shell continuó siendo una de las vulnerabilidades explotadas con más frecuencia (enlace externo a ibm.com).

Log4Shell persiste por varias razones.

La primera es que Log4J está enterrada en lo más profundo de la cadena de suministro de software de muchas empresas.Hoy en día, muchas aplicaciones se crean ensamblando bibliotecas de software de código abierto preexistentes.Este proceso es práctico, pero también significa que las organizaciones tienen una visibilidad limitada de todos los componentes que conforman sus aplicaciones.Es fácil pasar por alto las versiones antiguas de Log4J.

Cuando se parchea una versión vulnerable de Log4J, no siempre permanece parcheada.En noviembre de 2022, Tenable informó (enlace externo a ibm.com) que el 29% de los activos aún vulnerables a Log4Shell eran "recurrentes". Fueron parcheados en el pasado, pero el defecto reapareció. Esta situación se produce porque cuando la gente crea o actualiza aplicaciones, a veces utiliza accidentalmente bibliotecas de software que todavía contienen versiones sin parchear de Log4J.

Finalmente, los hackers desarrollaron una forma inteligente de cubrir sus huellas. Según CISA (enlace externo a ibm.com), algunos hackers utilizan Log4Shell para entrar en una red, y luego parchean el activo. La empresa cree que es seguro, pero los hackers ya están "dentro".

Las últimas versiones de Log4J están libres de Log4Shell. Los expertos en ciberseguridad recomiendan que los equipos de seguridad se centren en garantizar que todas las instancias de Log4J en sus sistemas estén actualizadas.

La actualización de Log4J puede ser un proceso lento, ya que las empresas a menudo tienen que profundizar en sus activos para encontrarlo.Mientras tanto, los equipos de seguridad pueden utilizar la exploración continua de vulnerabilidades y herramientas de detección de amenazas, como la gestión de la superficie de ataque (ASM) y las plataformas de detección y respuesta de puntos finales (EDR), para supervisar los activos que se dirigen a Internet. Los expertos recomiendan que los equipos de respuesta an incidentes investiguen a fondo cualquier indicio de actividad de Log4Shell.

Después de que Log4Shell se hiciera público, muchos cortafuegos, sistemas de detección de intrusiones (IDS) y sistemas de prevención de intrusiones (IPS) añadieron reglas para detectar la explotación de Log4Shell. Estas herramientas pueden ayudar a los equipos de seguridad a detectar y bloquear el tráfico procedente de servidores controlados por atacantes. 

• 18 de julio de 2013: Apache lanza Log4J 2.0-beta9, la primera versión compatible con el complemento JNDI. Aunque la vulnerabilidad no se descubrirá hasta años después, Log4Shell está presente desde este momento.

• 24 de noviembre de 2021: los investigadores de seguridad de Alibaba descubren Log4Shell y lo informan a Apache. Apache comienza a trabajar en un parche, pero no publica un aviso de seguridad pública.

• 9 de diciembre de 2021: Los investigadores de seguridad de Alibaba encuentran pruebas de que se está hablando de Log4Shell y se publica en GitHub un código de prueba de concepto.

• 10 de diciembre de 2021: Apache emite el primer parche y los desarrolladores de Minecraft descubren Log4Shell en Minecraft Java Edition. La comunidad de ciberseguridad se da cuenta rápidamente de la gravedad de la situación, y las organizaciones comienzan a bloquear sus sistemas.

• 11 de diciembre de 2021: Cloudflare encuentra pruebas de que los actores de amenazas comenzaron a explotar Log4Shell antes de lo que se pensaba, ya el 1 de diciembre.

• 14 de diciembre de 2021: se descubre CVE-2021-45046 y Apache lanza un parche para solucionarlo.

• 17 de diciembre de 2021: se descubre CVE-2021-45105 y Apache lanza un parche para solucionarlo.

• 28 de diciembre de 2021: se descubre CVE-2021-44832 y Apache publica un parche final. Desde Log4J versión 2.17.1 en adelante, Log4Shell se ha corregido completamente.

• 4 de enero de 2022: La Comisión Federal de Comercio de EE. UU. (FTC) (enlace externo a ibm.com) anuncia su intención de perseguir a las empresas que expongan los datos de los consumidores a los hackers por no haber solucionado el problema de Log4Shell.

• Mayo de 2023: Check Point descubre que Log4Shell sigue siendo la segunda vulnerabilidad más explotada.