Log4j

CRONOLOGÍA

El pasado mes de diciembre, fue noticia mundial, la publicación de un zero day, una de las vulnerabilidades más peligrosas de los últimos años llamada CVE: 2021-44228 «Log4Shell» que afectaba al paquete de registro o librería de Java Log4j.

¿Por qué ha sido tan notable su repercusión? Básicamente porque este paquete o librería se encuentra en la gran mayoría de aplicaciones en Java y proveedores de servicios de software que lo usan con una gran dependencia en su propio código. Es decir, que, aunque tú hayas podido corregir esta brecha, necesitas que tus proveedores de cloud (ejemplo Apache) y otros, corrijan también su código para evitar que en cuanto se produzca la petición a su server, este no pueda ser vulnerado.

Esta brecha de seguridad fue comunicada de forma privada por el equipo de Alibaba Cloud a la fundación de software de Apache que mantiene Log4j el 24 de noviembre de 2021, sin embargo, no fue hasta el 9 de diciembre aproximadamente cuando se hacen públicos a nivel mundial los detalles.

Interesante es el análisis que Cloudflare realizó en sus registros de logs donde concluyó que había indicios de que esta vulnerabilidad ya estaba siendo usada por hackers desde el 1 de diciembre de 2021.

QUÉ ES LOG4J

Log4j es una librería basada en Java que registra la actividad de logs o eventos que corre en una gran cantidad de aplicaciones, dispositivos y servidores, y que ha sido categorizada como crítica por su gran extensión.

El servidor más conocido y la librería más afectada es «Apache Logging Services» (Apache Log4j desarrollada por Apache Software Foundation en Java) donde gran cantidad de empresas lo usan para sus diferentes servicios donde se registran las interacciones y se graban en sus logs.

CÓMO FUNCIONA LOG4J

Básicamente esta vulnerabilidad lo que permitía era poder inyectar código a través de una plantilla de variables sobre el registro de logs hacia cualquier dispositivo o aplicación (ej. apps móviles, ordenadores, smartphone, smartwatchs, etc.) que usen esta librería Log4j a través de la vulnerabilidad original RCE (Remote Code Execution) o ejecución remota de comandos en código.

A nivel comandos, mediante el sistema JNDI (Java Naming and Directory Interface) y combinado con el servicio LDAP (Lightweight Directory Access Protocol) ,por ejemplo, se añade y ejecuta este payload a cualquier sistema que use Log4j, y mediante un servidor malicioso en escucha por ldap, puede recibir los datos que el servidor vulnerable le va a enviar por esa consulta.

En un principio el parche para Log4j en su versión 2.16.0 resolvía y corregía esta vulnerabilidad deshabilitando por completo la opción de inyección mediante JNDI, etc, sin embargo se detectó que no era así en su totalidad ya que por ejemplo se permitía aplicar denegación de servicios DoS, por lo que el 20/12/2021 el equipo de Log4j publicó una nueva versión 2.17 que ya solucionó esta brecha. Para las versiones anteriores a la 2.10, puede mitigarse estableciendo la propiedad del sistema log4j2.formatMsgNoLookups = true

En este gráfico se explica perfectamente cómo es un escenario normal de una conexión por Log4J vs un escenario de ataque, donde a través del user agent y mediante las propiedades jndi y ldap se pueden inyectar esa consulta maliciosa para que el servidor la devuelva:

Fuente: «How the Log4J exploits works» por Sophoslabs

Y QUÉ RELACIÓN TIENE CON EL SEO

A raíz de todo este ruido generado por la vulnerabilidad, muchos sitios web tuvieron que corregir sus líneas de código para protegerse de esa brecha y «parar» su actividad online. Este parón online (temporal), puede llevar a los buscadores, a tener problemas a la hora de indexar y posicionar su contenido.

Es por ello, que muchos webmasters y SEOs, preocupados ante la situación de ver cómo esto les podría afectar a su tráfico orgánico, consultaron a los principales representantes del buscador como John Mueller, y les ofrecieron una alternativa genérica.

Esta solución pasa por establecer una serie de puntos de configuración, que dependerán de cada sitio web y cómo estén definidos a nivel servidor, etc. que son las mismas recomendaciones que se les dan a aquellos sitios web que deciden temporalmente, dejar su sitio sin servicio:

  • Ofrecer una versión html de tu sitio web para poder servir en caso de «cierre» temporal y que Google pueda seguir indexando y rastreando aquellos elementos clave como CSS, html (negritas, enlaces, etc.), imágenes, etc.
    • Una buena opción podría ser sólo crear la versión básica en html de tus urls más importantes o con mayor tráfico en buscadores, y subirlas a mano a la plataforma archive.org para poder recuperarlas más adelante, etc.
  • Si la anterior opción no es posible, y no puedes dar un servicio estable de tu sitio, se recomienda devolver en cabecera http un estado 503 que indique que el servidor responde con un error ya que no está preparado para manejar la petición del navegador, y en su lugar, ofrecer al usuario una página «de escape» que le permita poder al menos estar informado de qué ocurre y una fecha estimada de resolución sobre la que podría volver en un futuro.

Documentación de referencia sobre la que apoyo este post y que os recomiendo consultar para más detalle:

¿Qué es Log4j y por qué esta vulnerabilidad amenaza a TODO INTERNET? – Platzi [Vídeo]

Vulnerabilidad Log4j – Qué es y por qué es tan peligrosa!!! – David Pereira [Vídeo]

Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package – LunaSec

Critical RCE Vulnerability: log4j – CVE-2021-44228 – Huntress

¿Afecta la vulnerabilidad Log4j a WordPress? – AyudaWP

How to mitigate the imminent risk of log4j – TryHackMe Blog

Vulnerabilidad crítica en Apache Log4j – INCIBE