España
Reino Unido
Italia
Portugal
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.
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 el resto de esta entrada del blog, nos centramos en resolver estos dos desafíos.
Una vez identificados los dispositivos vulnerables, Forescout recomienda aplicar las últimas actualizaciones de seguridad de Apache.
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.
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.
Los equipos de I+D de Forescout han desarrollado los siguientes artefactos para ayudar a mitigar Log4Shell.
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.
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.
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.