El 28 de diciembre de 2021, Apache reveló una nueva vulnerabilidad (CVE-2021-44832). Se trata de una vulnerabilidad de gravedad media (puntuación CVSS: 6,6) que permite la ejecución remota de código (RCE) en las versiones de Apache Log4j2 de la 2.0-beta7 a la 2.17.0, excluyendo las versiones de corrección de seguridad 2.3.2 y 2.12.4. Apache ha publicado las versiones 2.17.1, 2.12.4 y 2.3.2 de Log4j2 para parchear la vulnerabilidad y resolver el problema.
Para obtener la información más actualizada sobre cómo actualizar sus productos Forescout, consulte el artículo KB #12049 en su portal.
Para más información: Apache CVE: CVE-2021-44832
El 9 de diciembre de 2021, Apache publicó una vulnerabilidad de día cero (CVE-2021-44228) para Apache Log4j denominada Log4Shell. Esta vulnerabilidad ha sido clasificada como crítica con una puntuación CVSS de 10, permitiendo la Ejecución Remota de Código con privilegios a nivel de sistema o la fuga de información sensible.
Cuando se utiliza, esta vulnerabilidad permite a un atacante ejecutar un código arbitrario en el dispositivo, dándole el control total al atacante. Cualquier dispositivo que se haya atacado debe considerarse potencialmente comprometido, junto con cualquier dispositivo que confíe en el dispositivo comprometido.
La vulnerabilidad ha sido aprovechada activamente en los entornos desde al menos una semana antes de la divulgación pública. Hay informes de exploits de entidades maliciosas que despliegan web shells, crypto miners y otro malware en las víctimas.
También parece haber pruebas de que se desarrollará un gusano para esta acción, entre las 24 y las 48 horas siguientes. Por lo tanto, se recomienda una respuesta urgente para detectar y corregir las aplicaciones vulnerables, así como para vigilar los intentos de explotación en curso.
Forescout ha identificado los componentes afectados y está en proceso de actualizar sus sistemas y productos. El equipo de seguridad de Forescout comenzó inmediatamente una investigación en sus redes y no ha encontrado evidencia de compromiso en este momento y ha actualizado las reglas y firmas de las soluciones de seguridad de Forescout para detectar y bloquear cualquier intento de explotar nuestras plataformas y mantener a nuestras barreras de defensa en alerta máxima.
La vulnerabilidad y por qué es un reto
Log4j es una biblioteca de registro presente en muchas aplicaciones Java y la vulnerabilidad es una consecuencia de cómo Log4j procesa los mensajes de registro.
Permite el uso de funciones de búsqueda, en las que el usuario que proporciona los datos a registrar puede especificar de dónde procede el contenido de los datos. En lugar de una simple cadena, por ejemplo, puede ser una llamada a un servidor remoto. Eso permite a los atacantes inyectar llamadas a servidores maliciosos que alojan malware o una instrucción para filtrar información sensible (como tokens de acceso) a servidores controlados por el atacante.
Estas llamadas remotas están habilitadas por una característica de Java llamada Java Naming and Directory Interface (JNDI), que soporta protocolos como el Lightweight Directory Access Protocol (LDAP), Domain Name System (DNS), Remote Method Invocation (RMI) y Common Object Request Broker Architecture (CORBA). Técnicamente, un exploit es una cadena de la forma ${jndi::} que debe ser inyectada por un atacante en una instancia vulnerable de log4j.
Muchos dispositivos expuestos en Internet, como los servidores web, aceptan entradas de usuario que son registradas por un backend que ejecuta Log4j sin sanearlas. Esto sucede a menudo incluso si el propio servidor web no ejecuta Log4j, pero alguna aplicación de negocio utiliza la información procedente del usuario a través del servidor web. Esto permite a los atacantes inyectar las cadenas maliciosas a través de peticiones HTTP, por ejemplo, que es la mayor superficie de ataque observada hasta ahora.
Hay dos factores que complican esta vulnerabilidad:
- En primer lugar, Log4j no es una única aplicación vulnerable, sino un componente ampliamente utilizado, presente en productos que van desde bases de datos hasta sistemas de conferencias web. Por lo tanto, identificar los activos vulnerables en una red es un reto.
- En segundo lugar, los atacantes han encontrado rápidamente muchas formas de ofuscar los exploits, de modo que no es fácil entender si su organización es o fue atacada y cómo lo fue. Por ejemplo, un exploit válido es ${{::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://}, que no es fácil de relacionar inmediatamente con la plantilla ${jndi::} que mencionamos anteriormente.
En el resto de esta entrada del blog, nos centramos en resolver estos dos desafíos.
Protección de su red – Mitigación
Identificar los dispositivos vulnerables
Los programas/dispositivos vulnerables pueden ser identificados por:
- Revisar los inventarios de activos con los avisos de los proveedores.
- Analizar los informes de la lista de materiales de software (SBOM) -que todavía son muy raros- o las notas de dependencias de la cadena de desarrollo de software, que son comunes en entornos como Maven, para identificar el uso del componente vulnerable.
- Buscar en el sistema de archivos de las máquinas para identificar los archivos de tipo class, especialmente el JndiLookup.class que se utiliza para acceder a los servicios remotos.
- Analizar los archivos de registro para identificar las entradas procedentes de log4j y asignarlas a las aplicaciones.
Parcheo o cambio de configuración
Una vez identificados los dispositivos vulnerables, Forescout recomienda aplicar las últimas actualizaciones de seguridad de Apache.
- Apache CVE: CVE-2021-44228
- Aviso de seguridad de Apache: Vulnerabilidades de seguridad de Apache Log4j
Las siguientes soluciones son recomendadas por Apache, pero no deben considerarse una solución completa:
- En caso de que el componente vulnerable de Log4j 2 no pueda actualizarse, las versiones 2.10 a 2.14.1 de Log4J 2 admiten que el parámetro log4j2.formatMsgNoLookups se establezca en ‘true’, para desactivar la función vulnerable. Asegúrese de que este parámetro está configurado en los scripts de inicio de la máquina virtual de Java: -Dlog4j2.formatMsgNoLookups=true.
- Como alternativa, los clientes que utilicen Log4j 2.10 a 2.14.1 pueden establecer la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS=»true» para forzar este cambio.
- Los usuarios desde Log4j 2.7 pueden especificar %m{nolookups} en la configuración de PatternLayout para evitar las búsquedas en los mensajes de eventos de registro.
- Para las versiones desde la 2.0-beta9 hasta la 2.10.0, la solución es eliminar la clase JndiLookup del classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Mitigar el riesgo en la red
Si se identifican dispositivos sensibles que no pueden ser parcheados inmediatamente (por ejemplo, un parche no está disponible), Forescout recomienda mitigar el riesgo de la siguiente manera.
- Utilice el etiquetado de aplicaciones para identificar aquellas aplicaciones que no ha validado como parcheadas y aplíqueles políticas estrictas.
- Configure un firewall para permitir el tráfico saliente a una lista blanca de direcciones y protocolos de confianza, evitando así que los atacantes se comuniquen fuera de la red.
- Supervisar cuidadosamente los inicios de sesión fallidos y las anomalías en los tokens.
- Detecte los intentos de ataque inspeccionando los archivos de registro en busca de los patrones de URL característicos. Como se ha mencionado anteriormente, los atacantes utilizan actualmente técnicas de ofuscación para evitar la detección. Una lista no exhaustiva de patrones de explotación que podrían ayudar a la detección incluye:
- ${jndi:ldap://}
- ${jndi:ldaps://}
- ${jndi:rmi://}
- ${${::-j}ndi:rmi://}
- ${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://}
- ${${lower:jndi}:${lower:rmi}://}
- ${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://}
- ${jndi:dns://}
Investigar los dispositivos finales
Si un dispositivo ha sido el objetivo de un exploit encontrado mediante la monitorización de la red como se ha descrito anteriormente, se puede seguir investigando el incidente comprobando los registros en busca de cadenas que empiecen por «${jndi» o cualquiera de los patrones de exploit mencionados anteriormente (hay expresiones regulares grep que ayudan a ello).
Una vez que haya determinado que el dispositivo ha sido realmente comprometido, se deben tomar los procesos adecuados de contención, erradicación y recuperación, que incluyen la desconexión del dispositivo, la eliminación del malware o de las herramientas maliciosas que se hayan caído y la determinación de cuándo puede volver el sistema a la producción.
Cómo Forescout puede ayudar a neutralizar Log4shell
Los equipos de I+D de Forescout han desarrollado los siguientes artefactos para ayudar a mitigar Log4Shell.
Evalúe su riesgo: encuentre los dispositivos vulnerables
Los clientes de eyeSight pueden instalar el plugin Security Policy Templates (SPT) versión 21.0.11. El SPT permite escanear hosts de Windows y Linux para identificar cuáles de ellos ejecutan aplicaciones que utilizan la biblioteca vulnerable Log4j.
El SPT enumera todos los archivos Java Archive (JAR) -aplicaciones y bibliotecas Java empaquetadas- en un host escaneado y busca la clase JndiLookup en los archivos JAR encontrados. Cuando se encuentra la clase, busca la información de la versión disponible en los manifiestos de construcción (por ejemplo, Maven properties.pom), los nombres de los archivos (por ejemplo, log4j-core-2.1.10), los hashes de los archivos o incluso las marcas de tiempo para intentar determinar si la aplicación es vulnerable o no.
Los hosts escaneados se agrupan en Vulnerables, Potencialmente Vulnerables, No Afectados y Desconocidos.
También tenemos la intención de que las futuras versiones del SPT ayuden aún más con las capacidades forenses mediante el escaneo de archivos de registro conocidos para los patrones de explotación. Tenga en cuenta que esto no formará parte de la primera versión del SPT.
Es primordial identificar hosts vulnerables y violados. Los clientes de eyeInspect pueden aprovechar la riqueza de los datos recogidos y las capacidades analíticas de la herramienta para investigar los comportamientos de la red. Se debe prestar especial atención al tráfico de salida relacionado con protocolos como LDAP, DNS y RMI. Es posible crear fácilmente múltiples cuadros de mando analíticos para evaluar el tráfico y los comportamientos de los dispositivos.
Estas potentes capacidades de registro y análisis son útiles también para identificar los exploits ocurridos mientras no se detectan las amenazas: con eyeInspect es fácil identificar los hosts que comenzaron a utilizar protocolos poco comunes o con comportamientos sospechosos, por ejemplo, un nodo que comenzó a comunicarse ayer a través de LDAP con un servidor desconocido en Internet.
Identificar los ataques: Detección de explotaciones en curso
Los clientes de eyeInspect pueden actualizar su Threat Detection Add-Ons script a la versión v.1.6 que contiene una estrategia de detección para los intentos de explotación CVE-2021-44228 en HTTP. Esto es compatible a partir de eyeInspect 4.2.0.
La figura 1 muestra un ejemplo de alerta emitida cuando se detecta un exploit.
También hay una flash update de OT Vulnerability & IoC Database para ayudar a la detección de IoCs relacionados con CVE-2021-44228. Algunos callbacks de Log4Shell se reportan como ejecutados a través de Tor; eyeInspect tiene una gran lista de direcciones IP de nodos de salida de Tor (6700, actualizadas muy recientemente). Esta actualización añade direcciones IP adicionales reportadas como maliciosas en varias fuentes y esta lista podría tener actualizaciones en los próximos días.
Tenga en cuenta que si bien esta información puede ser efímera, también le resultará muy útil. eyeInspect puede escanear automáticamente los registros de red históricos para buscar IOCs de Log4Shell utilizando la función Forensic Time Machine. Esto se recomienda, ya que mirar los registros pasados puede identificar la actividad de escaneo, compromiso o postcompromiso de un atacante.
Figura 1: Ejemplo de alertas en caso de intentos de explotación.
Figura 1: Ejemplo de alertas en caso de intentos de explotación.
Proteja su organización: Segmentación de la red
Los clientes de eyeSegment pueden configurar sus sistemas para poner en una lista blanca el tráfico LDAP, DNS y RMI, que está siendo utilizado en el entorno, sólo para servidores legítimos.
eyeSight también puede ayudar a aislar los dispositivos que se sabe que son vulnerables pero que no pueden ser parcheados, colocándolos en VLAN específicas.
Aunque no es posible bloquear las redes de OT en general, los clientes pueden establecer reglas en el motor de detección de anomalías de eyeInspect para que emitan alertas si se utilizan LDAP, RMI u otros protocolos sensibles contra destinos no incluidos en la lista blanca.
