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 usar libremente. En lugar de escribir sus propios registradores, los desarrolladores pueden conectar 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 (identificador de vulnerabilidad y exposición común (CVE), CVE-2021-44228) es una vulnerabilidad de ejecución remota de código (RCE) presente en algunas versiones de Log4J. La falla afecta a Apache Log4J 2, versiones 2.14.1 y anteriores. Log4J 2.15 y posteriores, y todas las versiones de Apache Log4J 1, no se ven afectadas.

Log4Shell surge de la forma en que las versiones anteriores de Log4J 2 manejan búsquedas de denominación Java e interfaz de directorio (JNDI). JNDI es una interfaz de programación de aplicaciones (API) que las aplicaciones Java utilizan 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 una pieza de datos 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 los mensajes de registro. Hacerlo es sencillo. Por ejemplo, en versiones anteriores de Minecraft Java Edition, que utilizan Log4J para grabar mensajes de usuario, un usuario puede escribir la búsqueda JNDI en la ventana de chat público.

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 Lightweight Directory Access Protocol (LDAP) para evitar llamar la atención. A continuación, almacenan una carga útil maliciosa en ese servidor, como un archivo malware. Finalmente, envían una búsqueda JNDI a un programa, diciéndole que vaya al servidor LDAP del atacante, descargue la carga útil y ejecute el código.

Los investigadores de seguridad del gigante tecnológico Alibaba descubrieron Log4Shell el 24 de noviembre de 2021. Obtuvo inmediatamente la puntuación más alta posible del Sistema de puntuación de vulnerabilidad común (CVSS): 10 de 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 podrían explotar Log4Shell mientras Apache estaba trabajando en una solución.
  
  
• Log4J es también 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 (el enlace reside fuera de 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 una dependencia indirecta, lo que significa que los activos de la compañía podrían no usar Log4J, pero dependen de otras aplicaciones y servicios que sí lo hacen.
  
  
• Finalmente, Log4Shell es muy fácil de explotar. Los hackers no necesitan permisos especiales ni autenticación. Pueden causar estragos escribiendo 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 en el mismo sistema, los hackers pueden usar Log4J para pasar cargas útiles a otras partes del sistema.

Para el 9 de diciembre de 2021, el código de prueba de concepto sobre cómo explotar Log4Shell se publicó en GitHub, y los piratas informáticos estaban montando ataques. Se expusieron importantes empresas y servicios como Minecraft, Twitter y Cisco. En el pico de la actividad Log4Shell, Check Point observó más de 100 ataques cada minuto, lo que afectó a más del 40 % de todas las redes de negocio a nivel mundial (el enlace reside fuera de ibm.com).

Los primeros ataques difunden malware de botnet y criptominado. Algunos hackers utilizaron la falla para lanzar ataques sin archivos, enviando scripts maliciosos a computadoras Windows y Linux para que divulguen contraseñas y otra información confidencial.

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

Incluso los actores del estado-nación se unieron. Se observó que los hackers asociados con China, Irán, Corea del Norte y Turkiye aprovechaban la vulnerabilidad.

Apache implementó el primer parche (Log4J versión 2.15.0) el 10 de diciembre de 2021. Sin embargo, ese parche dejó a la vista otra vulnerabilidad, CVE-2021-45046, que permitía a los piratas informáticos enviar comandos maliciosos a registros con ciertas configuraciones no predeterminadas.

Apache lanzó 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, solucionó la falla DoS pero dejó una última vulnerabilidad (CVE-2021-44832) que permitió a los piratas informáticos tomar el control de un componente de Log4J llamado "appender" para ejecutar código remoto. Apache abordó esto con un cuarto y último parche, Log4J versión 2.17.1. 

Si bien Log4J 2.17.1 cerró Log4Shell y todas sus vulnerabilidades relacionadas por parte de Apache, las ciberamenazas aún utilizan la falla. En mayo de 2023, Log4Shell seguía siendo una de las vulnerabilidades más explotadas (el enlace reside fuera de ibm.com).

Log4Shell persiste por varias razones.

La primera es que Log4J está enterrado profundamente en las cadenas 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 conveniente, pero también significa que las organizaciones tienen visibilidad limitada de todos los componentes que componen 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 reportado (el enlace reside fuera de ibm.com) que el 29% de los activos aún vulnerables a Log4Shell eran "repeticiones". Fueron parcheados en el pasado, pero la falla reapareció. Este escenario ocurre porque cuando las personas construyen o actualizan aplicaciones, a veces usan accidentalmente bibliotecas de software que aún contienen versiones sin parches de Log4J.

Por último, los hackers desarrollaron una forma de cubrir sus huellas. Según CISA (enlace fuera de ibm.com), algunos hackers utilizan Log4Shell para irrumpir 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.

Actualizar Log4J puede ser un proceso lento, ya que las empresas a menudo necesitan profundizar en sus activos para encontrarlo. Mientras tanto, los equipos de seguridad pueden utilizar herramientas continuas de análisis de vulnerabilidades y detección de amenazas, como gestión de superficies de ataque (ASM) y plataformas de detección y respuesta de endpoints (EDR) para monitorear los activos orientados a Internet. Los expertos recomiendan que los equipos de respuesta ante incidentes investiguen a fondo cualquier pista 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) agregaron reglas para detectar la explotación de Log4Shell. Estas herramientas pueden ayudar a los equipos de seguridad a detectar y bloquear el tráfico de los servidores controlados por el atacante. 

• 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 a partir de 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: investigadores de seguridad de Alibaba encuentran evidencia de que Log4Shell se está discutiendo de manera natural y se publica un código de explotación de prueba de concepto en GitHub.

• 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 evidencia 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 lanza un parche final. A partir de la versión 2.17.1 de Log4J, Log4Shell está totalmente remediado.

• 4 de enero de 2022: La Comisión Federal de Comercio de EE. UU. (FTC) (el enlace se encuentra fuera de ibm.com) anuncia que tiene la intención de perseguir a cualquier empresa que exponga datos de consumidores a piratas informáticos porque no abordaron Log4Shell.

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