Erkennung von Log4Shell mit Wazuh

Dieses Mal erfahren Sie, wie Sie Log4Shell mit Wazuh erkennen

Der Apache Log4J ist eine der gebräuchlichsten Logging-Bibliotheken in Java, die hauptsächlich für Fehlermeldungen verwendet wird. Es ist Teil mehrerer hochwertiger Anwendungen, darunter unter anderem iCloud, Twitter und Minecraft.

Kürzlich wurde eine Zero-Day-Schwachstelle namens Log4Shell mit CVE CVE-2021-44228 in Apaches Log4J 2 entdeckt, die es böswilligen Akteuren ermöglicht, Remote Code Execution (RCE)-Angriffe zu starten. Dies bedeutet, dass ein Angreifer aus der Ferne Befehle an einen Server senden kann, auf dem anfällige Anwendungen ausgeführt werden.

Die betroffenen Versionen von Apache Log4j 2 sind 2.0-beta9 zu 2.15 .

Genau genommen Version 2.15.0 Das war die erste Lösung für die Sicherheitsanfälligkeit, die später als immer noch anfällig entdeckt wurde. Es wird daher empfohlen, auf Version 2.16.0 zu aktualisieren wodurch JNDI deaktiviert und %m{lookups} vollständig entfernt wird .

Es gibt mehrere Möglichkeiten, Ihr System gegen diese Schwachstelle und potenzielle Angriffe zu schützen:

• Durchführen von Scans, um zu erkennen, ob eine verwundbare Version von Apache Log4j 2 auf Ihrem System vorhanden ist.
• Patch der Schwachstelle durch Aktualisierung auf Apache Log4j 2 Version 2.16.0 oder JNDI deaktivieren.
• Erstellen von Erkennungsregeln, die Verbindungs- und Webzugriffsprotokolle überwachen, um Ausnutzungsversuche zu erkennen.

Der Schlüssel zur Bekämpfung der aktuellen Angriffswelle ist die frühzeitige Erkennung der Schwachstelle für sofortiges Patchen und die ständige Überwachung aller Ressourcen, um festzustellen, wann versucht wird, diese Schwachstelle auszunutzen.

In den folgenden Abschnitten werden wir untersuchen, wie Wazuh bei der Überwachung und Erkennung dieser Schwachstelle helfen kann.

Bitte überprüfen Sie die wazuh-Installationsschritte hier „https://unixcop.com/wazuh-the-open-source-security-platform/“

Scannen gefährdeter Versionen von Apache Log4j 2

Dazu verwenden wir eine Wazuh SCA-Richtlinie (Security Configuration Assessment). SCA-Richtlinien sind im YAML-Format geschrieben und werden verwendet, um Prüfungen zur Systemhärtung durchzuführen; In vielen Fällen fällt auch die Erkennung angreifbarer Software in diese Kategorie.

Sofern nicht anders angegeben, wurden alle folgenden Konfigurationen auf der Seite des Wazuh-Servers vorgenommen. Es besteht normalerweise keine Notwendigkeit, die lokale Konfiguration der überwachten Agenten zu bearbeiten.

Zuerst erstellen wir eine neue Richtliniendatei unter /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'

Wir tun dies, damit die SCA-Richtlinie mit einer Gruppe von Agenten geteilt wird, die diejenigen sind, die die Prüfungen durchführen. In unserem Fall teilen wir die Richtlinie mit der Standardgruppe, daher der default Verzeichnis.

Hinweis: Bitte beachten Sie, dass je nach überwachtem System der find Befehl zur Erkennung anfälliger Anwendungen kann CPU-intensiv sein.

Sobald die SCA-Richtliniendatei erstellt ist, werden außerdem der Besitzer und die Gruppe geändert, damit sie von Wazuh verwendet werden können:

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

Als Nächstes haben wir den SCA-Block zu /var/ossec/etc/shared/default/agent.conf hinzugefügt um die neue Richtlinie auf den Wazuh-Agenten zu aktivieren, die zu default gehören Gruppe:

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

Unten haben wir eine lokale Einstellung in der Konfigurationsdatei des Wazuh-Agenten bearbeitet. Dies erfolgt direkt auf den überwachten Systemen, da es keine Möglichkeit gibt, diese Einstellung vom Wazuh-Server zu übertragen. Der Zweck dieser Änderung besteht darin, die Ausführung von Befehlen in den SCA-Richtlinien zu ermöglichen, die vom Wazuh-Server empfangen werden. Dies ist nicht erforderlich, wenn diese SCA-Richtlinien für den Agenten lokal sind.

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

Damit die neue Einstellung wirksam wird, haben wir den Wazuh-Agenten neu gestartet. Der Server hat auch automatisch die neue SCA-Richtliniendatei übertragen.

Wir können unter SCA-Ereignissen sehen, dass das System derzeit eine verwundbare Log4J 2-Version enthält.

Erkennen von Log4Shell-Exploit-Versuchen

Um eine weitere Sicherheitsebene hinzuzufügen, haben wir Regeln erstellt, die Angriffsversuche von Log4Shell erkennen.

Für diesen speziellen Fall haben wir Webzugriffsprotokolle überwacht und nach bestimmten Mustern gesucht, von denen bekannt ist, dass sie für diesen Exploit verwendet werden.

Wir haben die folgende Regel zu unserem Wazuh-Server in /var/ossec/etc/rules/local_rules.xml hinzugefügt Datei:

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

Wir haben auch den Wazuh-Manager neu gestartet, um diese Regel anzuwenden:

systemctl restart wazuh-manager

Unser Agentensystem läuft auf einem Apache-Webserver.

In einigen Fällen überwacht Wazuh die Webprotokolldateien möglicherweise noch nicht. Wir haben die Erfassung von Protokolldaten aktiviert, indem wir die Konfigurationsgruppe auf der Seite des Wazuh-Servers geändert haben. Dazu haben wir den folgenden Block an /var/ossec/etc/shared/default/agent.conf angehängt :

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

Um diese Regel zu testen, senden wir eine Webanfrage mit bekannten Log4Shell-Mustern an das überwachte System. Die Anfrage kann von jedem Gerät gesendet werden, das über eine Netzwerkverbindung mit dem Endpunkt verfügt:

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

Wir haben es sofort unter Sicherheitsereignisse protokolliert.

Schlussfolgerung

Zusammenfassend konnten wir das Vorhandensein der Log4Shell-Schwachstelle durch die Verwendung einer SCA-Richtlinie erkennen. Wir haben auch eine Regel erstellt, die das Webzugriffsprotokoll überwacht, um zu erkennen, wenn ein bekanntes Exploit-Muster in der Webanforderung vorhanden ist.

Dies ist nützlich für diejenigen, die proaktiv bleiben möchten, indem sie Maßnahmen implementieren, die einen Alarm auslösen, wenn es einen Hinweis auf die Log4Shell-Schwachstelle gibt.