Détecter Log4Shell avec Wazuh

Cette fois, vous apprendrez comment détecter Log4Shell avec Wazuh

Apache Log4J est l'une des bibliothèques de journalisation les plus courantes en Java, principalement utilisée pour les messages d'erreur. Il fait partie de plusieurs applications de grande valeur, notamment iCloud, Twitter et Minecraft, entre autres.

Récemment, une vulnérabilité zero-day appelée Log4Shell avec CVE CVE-2021-44228 a été détectée dans Log4J 2 d'Apache qui permet à des acteurs malveillants de lancer des attaques d'exécution de code à distance (RCE). Cela signifie qu'un agresseur peut envoyer à distance des commandes à un serveur exécutant des applications vulnérables.

Les versions Apache Log4j 2 concernées sont 2.0-beta9 à 2.15 .

En effet, la version 2.15.0 qui était le correctif initial de la vulnérabilité a été découvert plus tard comme étant toujours vulnérable. Il est donc recommandé de mettre à jour vers la version 2.16.0 qui désactive JNDI et supprime complètement %m{lookups} .

Il existe plusieurs façons de défendre votre système contre cette vulnérabilité et les attaques potentielles :

Exécution d'analyses pour détecter la présence d'une version vulnérable d'Apache Log4j 2 sur votre système.
Corriger la vulnérabilité en mettant à jour Apache Log4j 2 version 2.16.0 ou désactiver JNDI.
Créer des règles de détection qui surveillent les journaux de connexion et d'accès Web pour détecter les tentatives d'exploitation.

La clé pour lutter contre la vague actuelle d'attaques est la détection précoce de la vulnérabilité pour un correctif immédiat et une surveillance constante de tous les actifs pour identifier toute tentative d'exploitation de cette vulnérabilité.

Nous verrons comment Wazuh peut aider à la surveillance et à la détection de cette vulnérabilité dans les sections suivantes.

veuillez vérifier les étapes d'installation de wazuh ici "https://unixcop.com/wazuh-the-open-source-security-platform/"

Analyse des versions vulnérables d'Apache Log4j 2

Nous utiliserons une politique Wazuh SCA (Security Configuration Assessment) pour cela. Les politiques SCA sont écrites au format YAML et sont utilisées pour exécuter des vérifications pour le renforcement du système ; dans de nombreux cas, la détection de logiciels vulnérables entre également dans cette catégorie.

Sauf indication contraire, toutes les configurations suivantes ont été effectuées côté serveur Wazuh. Il n'est généralement pas nécessaire de modifier la configuration locale des agents surveillés.

Tout d'abord, nous créons un nouveau fichier de stratégie dans /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'

Nous faisons cela pour que la stratégie SCA soit partagée avec un groupe d'agents, qui sont ceux qui exécuteront les vérifications. Dans notre cas, nous partageons la stratégie avec le groupe par défaut, d'où le default répertoire.

Remarque : Veuillez noter que, selon le système surveillé, le find La commande utilisée pour détecter les applications vulnérables peut être gourmande en CPU.

De plus, une fois le fichier de stratégie SCA créé, le propriétaire et le groupe sont modifiés afin qu'il puisse être utilisé par Wazuh :

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

Ensuite, nous avons ajouté le bloc SCA à /var/ossec/etc/shared/default/agent.conf pour activer la nouvelle politique sur les agents Wazuh qui appartiennent au default groupe :

<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>

Ci-dessous, nous avons modifié un paramètre local sur le fichier de configuration de l'agent Wazuh. Cela se fait directement sur les systèmes qui sont surveillés, car il n'y a aucun moyen de pousser ce paramètre à partir du serveur Wazuh. Le but de cette modification est de permettre l'exécution de commandes dans les politiques SCA reçues du serveur Wazuh. Cela n'est pas nécessaire lorsque ces stratégies SCA sont locales pour l'agent.

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

Pour que le nouveau paramètre prenne effet, nous avons redémarré l'agent Wazuh. Le serveur a également envoyé automatiquement le nouveau fichier de stratégie SCA.

Nous pouvons voir sous les événements SCA que le système contient actuellement une version vulnérable de Log4J 2.

Détection des tentatives d'exploitation Log4Shell

Pour ajouter une autre couche de sécurité, nous avons créé des règles qui détecteront les tentatives d'exploitation de Log4Shell.

Pour ce cas particulier, nous avons surveillé les journaux d'accès Web et recherché des modèles spécifiques connus pour être utilisés pour cet exploit.

Nous avons ajouté la règle suivante à notre serveur Wazuh dans le /var/ossec/etc/rules/local_rules.xml fichier :

<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>

Nous avons également redémarré le gestionnaire Wazuh pour appliquer cette règle :

systemctl restart wazuh-manager

Notre système d'agent exécute un serveur Web Apache.

Dans certains cas, Wazuh peut ne pas déjà surveiller les fichiers journaux Web. Nous avons activé la collecte des données de journal en modifiant le groupe de configuration côté serveur Wazuh. Pour cela, nous avons ajouté le bloc suivant à /var/ossec/etc/shared/default/agent.conf :

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

Pour tester cette règle, nous envoyons une requête Web avec des modèles Log4Shell connus au système surveillé. La demande peut être envoyée à partir de n'importe quel appareil disposant d'une connectivité réseau avec le point de terminaison :

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

Nous l'avons immédiatement enregistré sous les événements de sécurité.

Conclusion

En résumé, nous avons pu détecter la présence de la vulnérabilité Log4Shell en utilisant une politique SCA. Nous avons également créé une règle qui surveille le journal d'accès Web pour détecter la présence d'un modèle d'exploitation connu dans la requête Web.

Ceci est utile pour ceux qui souhaitent rester proactifs en mettant en œuvre des mesures qui alerteront en cas d'indication de la vulnérabilité Log4Shell.