Llegamos a ustedes gracias a:



Reportajes y análisis

Cómo mitigar adecuadamente las vulnerabilidades de Log4j

[16/12/2021] La comunidad de seguridad de TI ha estado trabajando arduamente durante la semana pasada para investigar una vulnerabilidad crítica y fácil de explotar en un componente Java muy popular llamado Log4j, que está presente en millones de aplicaciones y productos. Desde que se reveló la falla por primera vez y los atacantes comenzaron a explotarla, los investigadores de seguridad han descubierto problemas de seguridad adicionales en Log4j y varias formas de eludir algunas de las mitigaciones propuestas, dejando a los equipos de seguridad luchando por encontrar las formas correctas de proteger sus aplicaciones, servidores y redes.

[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]

Actualizar el componente afectado a la última versión, actualmente 2.16.0 para Java 8 y versiones posteriores y 2.12.2 para Java 7 y versiones anteriores (aún por lanzar), es la mejor manera de mitigar las dos fallas identificadas hasta ahora: CVE -2021-44228, también conocido como Log4Shell, que conduce a la ejecución remota de código, y CVE-2021-45046, que puede causar una condición de denegación de servicio.

Desafortunadamente, el parchado inmediato no es viable en todos los escenarios. Los productos empaquetados de proveedores externos pueden contener versiones vulnerables de la popular biblioteca de registro que los usuarios no pueden modificar sin actualizar todo el producto, por lo que dependen de que los proveedores publiquen las actualizaciones.

Es posible que las aplicaciones y los servidores críticos para la empresa no puedan reiniciarse inmediatamente, o que las aplicaciones se ejecuten en contenedores para los que se deben crear nuevas imágenes de contenedor. Como ocurre con la mayoría de las vulnerabilidades, las mitigaciones alternativas son muy útiles para los equipos de seguridad, pero es importante comprender sus limitaciones y la falsa sensación de seguridad que algunas de ellas pueden inducir.

[La vulnerabilidad de Apache Log4j se explota activamente]
[Consejos de mitigación de Log4j]
[La segunda vulnerabilidad de Log4j conlleva una amenaza de denegación de servicio]

Eliminar la clase JndiLookup

Esta vulnerabilidad se debe a la forma en que Log4j utiliza una función de Java llamada JNDI (Java Naming and Directory Interface) que fue diseñada para permitir la carga de objetos Java adicionales durante la ejecución del runtime. JNDI se puede utilizar para cargar dichos objetos desde servicios de naming remotos a través de varios protocolos. El exploit original usaba LDAP (Lightweight Directory Access Protocol), que es el más común, pero también se admiten otros: DNS (Domain Name System), RMI (Remote Method Invocation), NDS (Novell Directory Services), NIS (Network Information) Service) y CORBA (Common Object Request Broker Architecture).

Una forma de corregir la vulnerabilidad es deshabilitar el uso de búsquedas de mensajes JNDI, que es lo que hace Log4j 2.16.0. Sin embargo, esto también se puede lograr esencialmente retirando toda la clase JndiLookup, que implementa esta funcionalidad, del paquete Log4j afectado. Dado que los componentes de Java son en esencia archivos ZIP, los administradores pueden ejecutar el siguiente comando para modificar y parchar una instancia de paquete vulnerable:

zip -q -d log4j-core - *. jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Hotpatching usando un agente de Java

Hotpatching es el proceso de implementar un parche en un proceso en ejecución sin tener que reiniciarlo. Java admite la modificación sobre la marcha del código de bytes que ya se está ejecutando en una máquina virtual Java (JVM) a través de una API de instrumentación y los llamados agentes Java. Un agente Java es esencialmente un archivo JAR (Java Archive) que se puede adjuntar dinámicamente a una JVM durante el runtime.

En respuesta a las vulnerabilidades de Log4j, el equipo de Corretto de Amazon Web Services desarrolló un agente Java que intenta parchar el método lookup() de todas las instancias org.apache.logging.log4j.core.lookup.JndiLookup cargadas para devolver la cadena "Patched JndiLookup::lookup() en lugar de conectarse a un servidor remoto.

El agente está disponible en GitHub, y también se puede implementar como un contenedor efímero a un pod de Kubernetes existente para parchar aplicaciones que ya se están ejecutando en otros contenedores. Los contenedores efímeros son compatibles con Kubernetes v1.16 y versiones posteriores.

Explotar la falla en sí para evitar temporalmente la explotación

Es posible aprovechar la propia vulnerabilidad en los servidores afectados para realizar ciertos cambios en el sistema en vivo y la aplicación que evitarían una mayor explotación. Investigadores de la firma de seguridad Cybereason desarrollaron un exploit de inmunización de este tipo, y los investigadores de LunaSec lo mejoraron aún más y lo alojaron en un servidor en vivo como servicio público.

Un caso de uso para algo como esto son todos aquellos productos de terceros (aplicaciones empaquetadas, dispositivos y dispositivos integrados) que aún no tienen parches disponibles o productos vulnerables que han llegado al final de su vida útil y nunca recibirán una actualización oficial. Usar el exploit contra sí mismo podría ser una solución viable a corto plazo.

Es importante comprender que usar esto tiene algunas advertencias importantes. Primero, la solución es transitoria porque los cambios que realiza el exploit se aplican al proceso de Java en ejecución y se revertirán cuando se reinicie la JVM. Esto significa que la inmunización debe volver a aplicarse si se reinicia el servidor. En segundo lugar, si bien el método ha sido probado en varias configuraciones y sistemas, es posible que no funcione en todos y podría provocar fallas en algunos. Recuperarse de una caída puede implicar el reinicio del servidor, por lo que no es una buena idea ejecutar esto en sistemas críticos donde el tiempo de inactividad no es una opción.

Finalmente, probablemente sea ilegal usar esto contra servidores de los que uno no se es propietario y que no se controlan, ya que está explotando la vulnerabilidad, aunque con fines no maliciosos.

Identificación de sistemas vulnerables

Antes de que se desarrolle cualquier estrategia de respuesta y se pueda utilizar cualquiera de las rutas de mitigación mencionadas anteriormente, las organizaciones deben identificar primero todas las aplicaciones y sistemas que tienen y que podrían ser vulnerables a las vulnerabilidades de Log4j. Eso no es fácil de hacer, considerando que cada aplicación puede empaquetar su propia instancia de Log4j, y también podría cargarla dinámicamente como parte de alguna otra dependencia de terceros.

Varias listas de avisos de proveedores de Log4Shell son mantenidas por la comunidad de seguridad y los CERT, pero es probable que estén incompletas. Desafortunadamente, hasta que los desarrolladores de software adopten de forma generalizada los software bills of materials (SBOM), los equipos de seguridad se enfrentarán a la lenta -y propensa a errores- tarea de identificar los sistemas afectados en sus organizaciones en respuesta a cada nueva vulnerabilidad. Es probable que más investigadores y atacantes comiencen a buscar fallas en otros componentes muy utilizados a raíz de esta vulnerabilidad.

La comunidad de seguridad respondió rápidamente desarrollando herramientas de código abierto para automatizar la búsqueda de servidores e instancias vulnerables del paquete Log4j. La herramienta log4shell de LunaSec puede verificar archivos .jar y .war en un directorio de proyecto e informar si alguno es vulnerable. Se ha agregado soporte para las vulnerabilidades de Log4j a otros escáneres y herramientas de vulnerabilidades comerciales y de código abierto.

Mitigaciones ineficientes de Log4j

Desde que se anunció la primera vulnerabilidad de Log4j, se ha demostrado que varias mitigaciones propuestas son ineficaces y ya no se debe confiar en ellas.

Hacer upgrade de la versión de Java no es suficiente. El exploit inicial no funcionó en versiones de Java posteriores a 6u212, 7u202, 8u192 o 11.0.2 porque la configuración predeterminada en estas versiones evita la carga de clases a través de JNDI (Java Naming and Directory Interface) desde servidores remotos. Sin embargo, los investigadores de seguridad han demostrado desde entonces que los atacantes pueden crear payloads que aprovechan las clases en la propia ruta de clases de la aplicación en lugar de las remotas, por lo que esto no evita todos los ataques.

La marca formatMsgNoLookups no evita todas las vulnerabilidades. El primer consejo de mitigación, incluso de los desarrolladores de Log4j, fue establecer una propiedad llamada formatMsgNoLookups en versiones de Log4j superiores a 2.10 en verdadero, o una variable de entorno llamada LOG4J_FORMAT_MSG_NO_LOOKUPS. Esto se demostró ineficaz por la segunda vulnerabilidad de denegación de servicio, que funciona incluso con esta marca habilitada. "Todavía hay rutas de código en Log4j donde podrían ocurrir búsquedas de mensajes: ejemplos conocidos son aplicaciones que usan Logger.printf (%s"", userInput), o aplicaciones que usan una fábrica de mensajes personalizada, donde los mensajes resultantes no implementan StringBuilderFormattable, afirmaron los desarrolladores.

Deshabilitar las búsquedas de mensajes modificando los formatos de las declaraciones de registro.

Una mitigación propuesta fue modificar todos los formatos de declaración de registro en la aplicación desde %m, %msg o %message a%m{nolookups}, %msg{nolookups} o %message{nolookups} para deshabilitar la función de búsqueda de mensajes. Esto no funciona por las mismas razones que la marca formatMsgNoLookups, pero también es peligroso porque crea una falsa sensación de seguridad. Es muy fácil pasar por alto la actualización de una declaración de registro en una dependencia, o reintroducir una declaración %m vulnerable más tarde sin darse cuenta. Si ya ha utilizado esta mitigación, no debe confiar en ella.

Uso de firewalls de aplicaciones web (WAF) para filtrar solicitudes maliciosas. Si bien es posible bloquear los exploits conocidos con un firewall de aplicaciones web, es muy difícil detectar todas las posibles cadenas de exploits. Desde que se anunció la falla, los investigadores han demostrado muchas formas para crear payloads anidadas y ofuscadas que evitarían las reglas de filtrado WAF propuestas. Dicho esto, los proveedores de WAF e IPS actualizan constantemente sus firmas Log4Shell, por lo que esto puede usarse como una respuesta inmediata y temporal para bloquear exploits conocidos o como una capa de defensa adicional además de otras mitigaciones. Vale la pena señalar que los WAF se utilizan normalmente para activos expuestos públicamente, pero existen rutas de explotación y escenarios internos para esta vulnerabilidad que no pasarían por un WAF para ser bloqueados.

A medida que la comunidad de seguridad continúa investigando esta vulnerabilidad y su impacto, es posible que las estrategias de mitigación existentes se modifiquen o se retiren. Por lo tanto, es mejor verificar constantemente la página de seguridad del proyecto Log4j y los avisos de organizaciones como CISA para cualquier actualización.

Crédito foto: Gerd Altmann / CC0