¿Qué es la vulnerabilidad Log4j?

Los actores maliciosos pueden usar la falla Log4j para ejecutar casi cualquier código que deseen en sistemas vulnerables.

Los investigadores consideran que Log4Shell es una vulnerabilidad de seguridad "catastrófica" porque está muy extendida (Log4J es uno de los programas de código abierto más implementados en el mundo) y es muy fácil de usar. Jen Easterly, director de la Agencia de Ciberseguridad y Seguridad de Infraestructuras (CISA) de EE. UU., la calificó de "una de las más graves que he visto en toda mi carrera, si no la más grave".

Log4Shell alimentó una oleada de ciberataques en diciembre de 2021. El IBM X-Force Threat Intelligence Index anual registró un aumento del 34 % en la explotación de vulnerabilidades entre 2020 y 2021, atribuido principalmente a Log4Shell.

Poco después de este descubrimiento, Log4Shell fue parcheado, pero seguirá siendo un riesgo en los próximos años, ya que Log4j está profundamente integrado en la cadena de suministro de software. El Departamento de Seguridad Nacional de EE. UU. estima que se tarda al menos una década en encontrar y arreglar todos los casos vulnerables.

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 e integrado en productos de grandes organizaciones como Microsoft y Amazon, por nombrar algunas.

Log4Shell, identificador común de vulnerabilidad y exposición (CVE) , 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 utilizar esta funcionalidad JNDI para ejecutar código malicioso y arbitrario de forma remota. En primer lugar, el hacker configura un servidor que utiliza 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 podrían utilizar Log4Shell mientras Apache trabajaba en una solución.
  
  
• Log4J también es una de las bibliotecas de registro más utilizadas, integrada en endpoints de consumo, aplicaciones web y servicios empresariales en la nube. Según Wiz y EY, el 93 % de todos los entornos en nube estaban en peligro 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.
  
  
• En definitiva, Log4Shell es fácil de usar. 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 utilizar Log4Shell y los hackers estaban organizando ataques. Importantes empresas y servicios como Minecraft, Twitter y Cisco quedaron expuestos. En el pico de actividad de Log4Shell, Check Point observó más de 100 ataques por minuto, que afectaban a más del 40 % de todas las redes empresariales a nivel mundial.

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 usar 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 iniciar 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 abordó esto 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 seguía siendo una de las vulnerabilidades más utilizadas.

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. Las versiones antiguas de Log4J pueden pasarse por alto fácilmente.

Cuando se parchea una versión vulnerable de Log4J, no siempre permanece parcheada. En noviembre de 2022, Tenable informó de que el 29 % de los activos que seguían siendo 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.

Por último, los hackers desarrollaron una forma inteligente de cubrir sus huellas. Según la CISA, 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 endpoints (EDR), para supervisar los activos que se dirigen a Internet. Los expertos recomiendan que los equipos de respuesta a incidentes investiguen a fondo cualquier indicio de actividad de Log4Shell.

Después de que Log4Shell se hiciera público, muchos Firewall, 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 (FTC) de EE. UU. anuncia su intención de perseguir a las empresas que expongan los datos de los consumidores a los piratas informáticos por no haber abordado el problema de Log4Shell.

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