Log4J y la memoria que sabía demasiado

Trellix · 19 de enero de 2022

Guilherme Venere, Ismael Valenzuela, Carlos Díaz, César Vargas, Leandro Costantino, Juan Olle, José Luis Sánchez Martínez, equipo AC3

Colaboradores: Steve Povolny, Douglas McKee, Mark Bereza, Frederick House, Dileep Kumar Jallepalli

En el sector de la ciberseguridad no hay tiempo para aburrirse y nunca ha habido un mejor momento para aceptar esta idea como una ventaja y un catalizador de la actividad empresarial.

Actualmente, profesionales de todo el mundo siguen combatiendo la última amenaza que se cierne sobre todas las empresas y de la que no se salva ningún sector vertical. Los análisis y los parches para la vulnerabilidad Log4Shell de la plataforma de registro Log4j de Apache basada en Java se han incrementado por una buena razón: Log4j es una de las aplicaciones de registro más utilizadas, si no la más empleada, entre los desarrolladores. Pero las empresas deben pensar más allá de la aplicación de parches, ya que Log4Shell está modificando lo que consideramos una superficie de ataque.

El potencial de daño a gran escala y proliferación de esta vulnerabilidad es elevado, así que su impacto debe tomarse en serio ahora para planificar y protegernos mejor frente al siguiente fallo importante.

Aunque la aplicación de parches es fundamental, para garantizar la seguridad de la infraestructura no debe tratarse de una corrección estática o puntual, sino de una estrategia permanente que combine amplia supervisión, análisis, evaluación y análisis forense para proporcionar la agilidad necesaria para enfrentarse a las amenazas más modernas de la actualidad.

En concreto, en este artículo demostramos cómo una solución para endpoints con funciones potentes de análisis de memoria puede detectar eficazmente escenarios de explotación activa y complementar las funciones de seguridad de red de su empresa para crear un nuevo tipo de resiliencia en su organización.

Contexto

Como bien es sabido en el sector de la seguridad, justo a tiempo para las fiestas navideñas de 2021 se publicó otra nueva vulnerabilidad, que en esta ocasión afectaba a una biblioteca de uso generalizado. CVE-2021-44228 denunciaba una vulnerabilidad de la biblioteca Log4j basada en Java que afectaba a aplicaciones y sitios web donde se utiliza esta biblioteca para la gestión de registros.

La vulnerabilidad permitía que un ciberdelincuente obligara al sitio o la aplicación vulnerable a cargar y ejecutar código Java malicioso desde una ubicación remota no fiable. Los vectores de ataque son variados, pero el que más utilizan los agresores suele ser el envío al equipo de destino de cadenas diseñadas como parte de un protocolo de red, por ejemplo, un encabezado HTTP modificado en una solicitud POST.

Este es el motivo de que muchos equipos de seguridad centren ahora sus esfuerzos en detectar las cadenas maliciosas en el tráfico de la red y reconozcan que la proactividad es crucial para obtener buenos resultados. Sin embargo, es posible pasar por alto firmas de red y algunos informes confirman que los ciberdelincuentes están adaptando sus ataques con diversas formas de ofuscación para eludir el análisis de la red. La imagen siguiente muestra algunas de las técnicas de ofuscación actuales observadas o denunciadas en relación con este ataque.

Fuente: https://github.com/mcb2Eexe/Log4j2-Obfucation

Ahora bien, esto no significa que las soluciones de protección de redes no sean útiles contra este ataque. De hecho, Log4j demuestra la importancia de que los equipos de seguridad sean tan adaptables como los agresores y entren en una nueva era de seguridad evolutiva adoptando una mentalidad y un enfoque más dinámicos. Las plataformas de seguridad de redes proporcionan una primera capa de defensa y deben utilizarse como parte de una arquitectura de seguridad incorporada (estrategia de tratamiento de riesgos para la seguridad), mejorada con capas adicionales de protección, detección, visibilidad y respuesta.

Las soluciones modernas para endpoints disfrutan de una posición única para complementar las funciones de red con una visibilidad profunda basada en el host de los procesos del sistema, como el análisis de la memoria y la organización de una respuesta rápida. Esta combinación genera una sólida defensa contra amenazas como Log4Shell y permite a las empresas recuperar la confianza con una seguridad integral.

"Te veo": análisis de memoria hasta la victoria

El análisis de memoria puede añadir valor y ayudar a las plataformas de seguridad de la red cuando una conexión llega al endpoint tras burlar las capas de ofuscación. El diagrama siguiente muestra el flujo de ejecución de un típico ataque a Log4j basado en la web.

Veamos lo que ocurre:

• Etapa n.º 1: un ciberdelincuente envía una cadena diseñada específicamente al servidor web que aloja la aplicación vulnerable. Como podemos ver, esta cadena puede enmascararse para eludir las firmas de red.
• Etapa n.º 2: la aplicación desenmascara esta cadena para cargarla en memoria. Una vez cargada en memoria, la aplicación inicia una conexión LDAP para solicitar la dirección de la ubicación del archivo de clase maliciosa.
• Etapa n.º 3: el servidor LDAP controlado por el ciberdelincuente responde con la ubicación del archivo de clase maliciosa indicando la dirección URL HTTP donde está alojado.
• Etapa n.º 4: la aplicación vulnerable inicia la descarga del archivo de clase maliciosa.
• Etapa n.º 5: la aplicación vulnerable carga y ejecuta el archivo de clase maliciosa de la etapa n.º 4. En este momento, el ciberdelincuente logra ejecutar el código en el destino y deja pistas que pueden permitir al equipo de seguridad identificar esta actividad, por ejemplo, puede generar procesos adicionales o tocar archivos y claves del Registro después de una explotación.

¿Se imagina si pudiéramos burlar las tácticas de ofuscación? Desde luego, es posible —y obligado— para adelantarse amenazas como la vulnerabilidad de Log4j. Con este fin es preciso activar un análisis de memoria en algún punto de este flujo de ejecución que detecte la presencia del archivo de código malicioso. En ese momento tendríamos grandes probabilidades de encontrar la cadena desofuscada utilizada en la memoria de proceso. Si la memoria se analiza después de la descarga del archivo de clase maliciosa, ese contenido también estaría disponible para analizarlo en su forma desofuscada.

Estas posibilidades confieren potencia y eficacia a la firma de memoria, ya que el momento de detección depende principalmente del activador utilizado para iniciar el análisis de memoria.

Reglas de experto de Endpoint Security combinadas con análisis de memoria

Nuestra solución permite a las empresas hacer precisamente eso: disponer de la posibilidad de activar un análisis de memoria a partir de una regla de experto.

Las reglas de experto son reglas personalizables de control de acceso que el usuario final utiliza para detectar actividades sospechosas que no suelen ver otros analizadores. También proporcionamos reglas de experto de la comunidad vinculadas al marco MITRE ATT&CK a través de nuestro GitHub público.

Estas funciones nos permiten localizar las aplicaciones vulnerables a Log4j e identificar el momento en que son objeto de ataque. Considere la regla siguiente:

Aquí vemos una sección que define ACTORS (en la sección Process {…}) y TARGETS (en la sección Target {…}). ACTORS es cualquier proceso que pueda ser vulnerable al exploit Log4j. En este caso, tenemos JAVA.EXE para aplicaciones Java independientes y TOMCAT?.EXE para aplicaciones web Apache. Cualquiera de estos procesos debe cargar tanto JAVA.DLL como JVM.DLL para asegurarse de que el tiempo de ejecución de Java está activo.

La sección TARGET incluye cualquier carga útil potencial del ataque. Como las reglas de experto no se centran en el tráfico de la red, debemos concentrarnos en el último paso del flujo de ejecución, que es cuando se ejecuta la carga útil. A medida que se dispone de más información sobre las vulnerabilidades, es posible agregar activadores adicionales, como archivos o claves del Registro accedidas. También podemos incluir exclusiones de comportamientos válidos, como muestra el ejemplo anterior al utilizar "Exclude" como parámetro de la línea de comandos. Esta exclusión es algo que los clientes pueden adaptar a su entorno para evitar falsos positivos y así combatir las amenazas con mayor eficacia.

Esta regla de experto se activará cuando un proceso ACTOR genere cualquiera de las cargas útiles TARGET. Es importante observar que los resultados y los falsos positivos pueden verse afectados por algunos matices. Fijémonos en esta línea del principio de la regla:

Esta instrucción inicia un análisis de memoria en el proceso ACTOR que ha provocado la activación de la regla de experto. Ahora tenemos un activador fiable para que el análisis de memoria sea válido, lo que evita los problemas de rendimiento que podría ocasionar un análisis ciego. Una ventaja es que el análisis se realiza en un momento muy próximo al intento de explotación inicial, lo que garantiza que la cadena desofuscada estará en la memoria.

A continuación, analizamos la memoria del proceso que ha activado la regla de experto, ejecutada por el motor DAT del antivirus. Una vez hallada esta cadena, se produce la detección en el proceso afectado y se aplica la acción configurada en la línea REACTION de la regla de experto. Recomendamos utilizar inicialmente la acción REPORT hasta haber averiguado qué procesos hay que supervisar.

El primer evento resaltado aquí es la activación de la regla de experto por un proceso sospechoso derivado de JAVA.EXE, mientras que el segundo muestra la detección del DAT del antivirus, que indica que la memoria de ese proceso tenía firmas del exploit.

Nota:

Si solo estuviera presente la detección de la regla de experto pero NO el evento Java Naming and Directory Interface (JNDI)/Log4j-Exploit, indicaría que un programa ha ejecutado procesos secundarios sospechosos, por lo que se recomienda a los clientes revisar el evento y mejorar la regla de experto como corresponda.

Sin embargo, si se activan tanto el evento de la regla de experto como JNDI/Log4j-Exploit con el mismo programa, podemos tener la certeza de haber detectado la presencia del proceso que se está explotando.

Proporcionamos más información sobre nuestra cobertura actual de la vulnerabilidad de Log4j en KB95901, donde se explica la protección para la ejecución remota de código CVE-2021-44228 en Log4j de Apache. Este artículo contiene enlaces para descargar la regla de experto y un archivo EXTRA.DAT adicional actualizado, así como detalles sobre cómo configurar ePO para utilizarlos en su entorno.

Si desea implementar esta solución, le animamos a revisar las instrucciones en la base de conocimientos y en la documentación asociada. Es muy recomendable revisar la regla de experto y ajustarla a su entorno para que no solo neutralice o responda a riesgos activos, sino que también se adapte dinámicamente para protegerle frente a las amenazas cambiantes.

Conclusión

Para proteger un entorno frente a ataques como Log4j, una estrategia multicapa incorporada compuesta por seguridad de red y análisis selectivos de la memoria de los endpoints permite a los equipos de seguridad detectar y prevenir eficazmente el flujo de ejecución del ataque contra los sistemas vulnerables expuestos mediante vectores de red. Los análisis personalizados y las reglas de experto de nuestra solución ENS están diseñados para permitirle aplicar contramedidas precisas frente a estas amenazas emergentes, así como para asumir el control y adquirir más confianza para mantener su negocio y hacerlo crecer.