Detectando Log4Shell con Wazuh

Esta vez, aprenderá a detectar Log4Shell con Wazuh

Apache Log4J es una de las bibliotecas de registro más comunes en Java y se utiliza principalmente para mensajes de error. Forma parte de varias aplicaciones de gran valor, como iCloud, Twitter y Minecraft, entre otras.

Recientemente, se detectó una vulnerabilidad de día cero denominada Log4Shell con CVE CVE-2021-44228 en Log4J 2 de Apache que permite a los actores malintencionados lanzar ataques de ejecución remota de código (RCE). Esto significa que un agresor puede enviar comandos de forma remota a un servidor que ejecuta aplicaciones vulnerables.

Las versiones afectadas de Apache Log4j 2 son 2.0-beta9 a 2.15 .

De hecho, la versión 2.15.0 que fue la solución inicial para la vulnerabilidad, se descubrió más tarde que aún era vulnerable. Por lo que se recomienda actualizar a la versión 2.16.0 que deshabilita JNDI y elimina por completo %m{lookups} .

Hay varias formas de defender su sistema contra esta vulnerabilidad y posibles ataques:

• Ejecutar análisis para detectar cuándo existe una versión vulnerable de Apache Log4j 2 en su sistema.
• Parchear la vulnerabilidad actualizando a Apache Log4j 2 versión 2.16.0 o desactivar JNDI.
• Crear reglas de detección que controlen los registros de conexión y acceso web para detectar intentos de explotación.

La clave para combatir la ola actual de ataques es la detección temprana de la vulnerabilidad para parchear inmediatamente y el monitoreo constante de todos los activos para identificar cuándo hay un intento de explotar esta vulnerabilidad.

Veremos cómo Wazuh puede ayudar con el monitoreo y la detección de esta vulnerabilidad en las siguientes secciones.

consulte los pasos de instalación de wazuh aquí "https://unixcop.com/wazuh-the-open-source-security-platform/"

Análisis de versiones vulnerables de Apache Log4j 2

Utilizaremos una política Wazuh SCA (Evaluación de configuración de seguridad) para esto. Las políticas de SCA están escritas en formato YAML y se utilizan para ejecutar comprobaciones del fortalecimiento del sistema; en muchos casos, la detección de software vulnerable también se incluye en esta categoría.

A menos que se indique lo contrario, todas las configuraciones siguientes se realizaron en el lado del servidor de Wazuh. Por lo general, no es necesario editar la configuración local de los agentes que se están monitoreando.

Primero, creamos un nuevo archivo de política en /var/ossec/etc/shared/default/log4j_check.yml :

policy:
  id: "log4j_check"
  file: "log4j_check.yml"
  name: "Log4j dependency check"
  description: "This document provides prescriptive guidance for identifying Log4j RCE vulnerability"
  references:
    - https://nvd.nist.gov/vuln/detail/CVE-2021-44228
    - https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
requirements:
  title: "Check if Java is present on the machine"
  description: "Requirements for running the SCA scan against machines with Java on them."
  condition: all
  rules:
    - 'c:sh -c "ps aux | grep java | grep -v grep" -> r:java'
checks:
  - id: 10000
    title: "Ensure Log4j is not on the system or under 2.16"
    description: "The Log4j library is vulnerable to RCE on versions between 2.10 and 2.15."
    remediation: "Update the log4j library to version 2.16 or set log4j2.formatMsgNoLookups to true if possible."
    condition: none
    rules:
      - 'c:find / -regex ".*log4j.*.jar" -type f -exec sh -c "unzip -p {} META-INF/MANIFEST.MF | grep Implementation-Version" \; -> r: 2.10.| 2.11.| 2.12.| 2.13.| 2.14.| 2.15.'
  - id: 10001
    title: "Ensure Java is not running or is properly configured"
    description: "The Log4j library is vulnerable to RCE on versions between 2.10 and 2.15."
    remediation: "Update the log4j library to version 2.16 or set log4j2.formatMsgNoLookups to true if possible."
    condition: any
    rules:
      - 'c:sh -c "ps aux | grep java | grep -v grep" -> r:java && r:Dlog4j2.formatMsgNoLookups=true'

policy:
  id: "log4j_check"
  file: "log4j_check.yml"
  name: "Log4j dependency check"
  description: "This document provides prescriptive guidance for identifying Log4j RCE vulnerability"
  references:
    - https://nvd.nist.gov/vuln/detail/CVE-2021-44228
    - https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
requirements:
  title: "Check if Java is present on the machine"
  description: "Requirements for running the SCA scan against machines with Java on them."
  condition: all
  rules:
    - 'c:sh -c "ps aux | grep java | grep -v grep" -> r:java'
checks:
  - id: 10000
    title: "Ensure Log4j is not on the system or under 2.16"
    description: "The Log4j library is vulnerable to RCE on versions between 2.10 and 2.15."
    remediation: "Update the log4j library to version 2.16 or set log4j2.formatMsgNoLookups to true if possible."
    condition: none
    rules:
      - 'c:find / -regex ".*log4j.*.jar" -type f -exec sh -c "unzip -p {} META-INF/MANIFEST.MF | grep Implementation-Version" \; -> r: 2.10.| 2.11.| 2.12.| 2.13.| 2.14.| 2.15.'
  - id: 10001
    title: "Ensure Java is not running or is properly configured"
    description: "The Log4j library is vulnerable to RCE on versions between 2.10 and 2.15."
    remediation: "Update the log4j library to version 2.16 or set log4j2.formatMsgNoLookups to true if possible."
    condition: any
    rules:
      - 'c:sh -c "ps aux | grep java | grep -v grep" -> r:java && r:Dlog4j2.formatMsgNoLookups=true'

Hacemos esto para que la política SCA se comparta con un grupo de agentes, que son los que ejecutarán las comprobaciones. En nuestro caso, estamos compartiendo la política con el grupo predeterminado, de ahí el default directorio.

Nota: Tenga en cuenta que, dependiendo del sistema monitoreado, el find El comando utilizado para detectar aplicaciones vulnerables puede hacer un uso intensivo de la CPU.

Además, una vez que se crea el archivo de política SCA, el propietario y el grupo se modifican para que Wazuh pueda usarlos:

chown ossec:ossec /var/ossec/etc/shared/default/log4j_check.yml

A continuación, agregamos el bloque SCA a /var/ossec/etc/shared/default/agent.conf para habilitar la nueva política en los agentes de Wazuh que pertenecen al default grupo:

<agent_config>
  <sca>
    <enabled>yes</enabled>
    <scan_on_start>yes</scan_on_start>
    <interval>24h</interval>
    <skip_nfs>yes</skip_nfs>    
    <policies> 
      <policy>/var/ossec/etc/shared/log4j_check.yml</policy>  
    </policies>
  </sca>
</agent_config>

A continuación, editamos una configuración local en el archivo de configuración del agente de Wazuh. Esto se hace directamente en los sistemas que se están monitoreando, ya que no hay forma de enviar esta configuración desde el servidor de Wazuh. El propósito de esta modificación es habilitar la ejecución de comandos en las políticas SCA que se reciben del servidor Wazuh. Esto no es necesario cuando esas políticas SCA son locales para el agente.

echo "sca.remote_commands=1" >> /var/ossec/etc/local_internal_options.conf

Para que la nueva configuración surta efecto, reiniciamos el agente de Wazuh. El servidor también envió el nuevo archivo de política SCA automáticamente.

Podemos ver en los eventos de SCA que el sistema actualmente tiene una versión vulnerable de Log4J 2.

Detectar intentos de explotación de Log4Shell

Para agregar otra capa de seguridad, creamos reglas que detectarán los intentos de explotación de Log4Shell.

Para este caso particular, monitoreamos los registros de acceso a la web y buscamos patrones específicos que se sabe que se utilizan para este exploit.

Agregamos la siguiente regla a nuestro servidor Wazuh en /var/ossec/etc/rules/local_rules.xml archivo:

<group name="log4j, attack,">
  <rule id="110002" level="7">
    <if_group>web|accesslog|attack</if_group>
    <regex type="pcre2">(?i)(((\$|24)\S*)((\{|7B)\S*)((\S*j\S*n\S*d\S*i))|JHtqbmRp)</regex>
    <description>Possible Log4j RCE attack attempt detected.</description>
    <mitre>
      <id>T1190</id>
      <id>T1210</id>
      <id>T1211</id>
    </mitre>
  </rule>

  <rule id="110003" level="12">
    <if_sid>110002</if_sid>
    <regex type="pcre2">ldap[s]?|rmi|dns|nis|iiop|corba|nds|http|lower|upper|(\$\{\S*\w\}\S*)+</regex>
    <description>Log4j RCE attack attempt detected.</description>
    <mitre>
      <id>T1190</id>
      <id>T1210</id>
      <id>T1211</id>
    </mitre>
  </rule>
</group>

También reiniciamos el administrador de Wazuh para aplicar esta regla:

systemctl restart wazuh-manager

Nuestro sistema de agentes ejecuta un servidor web Apache.

En algunos casos, es posible que Wazuh aún no esté monitoreando los archivos de registro web. Habilitamos la recopilación de datos de registro modificando el grupo de configuración en el lado del servidor de Wazuh. Para esto, agregamos el siguiente bloque a /var/ossec/etc/shared/default/agent.conf :

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/apache2/access.log</location>
</localfile>

Para probar esta regla, enviamos una solicitud web con patrones Log4Shell conocidos al sistema monitoreado. La solicitud se puede enviar desde cualquier dispositivo que tenga conectividad de red con el punto final:

http://your_system_ip_address/?x=${jndi:ldap://${localhost}.{{test}}/a}

Inmediatamente lo registramos en eventos de seguridad.

Conclusión

En resumen, hemos podido detectar la presencia de la vulnerabilidad Log4Shell utilizando una política SCA. También creamos una regla que monitorea el registro de acceso web para detectar cuando existe un patrón de explotación conocido en la solicitud web.

Esto es útil para aquellos que desean mantenerse proactivos mediante la implementación de medidas que alertarán cuando haya una indicación de la vulnerabilidad de Log4Shell.