Rilevamento di Log4Shell con Wazuh

Questa volta imparerai come rilevare Log4Shell con Wazuh

Apache Log4J è una delle librerie di registrazione più comuni in Java, utilizzata principalmente per i messaggi di errore. Fa parte di diverse applicazioni di alto valore tra cui iCloud, Twitter e Minecraft, tra gli altri.

Di recente, in Log4J 2 di Apache è stata rilevata una vulnerabilità zero-day denominata Log4Shell con CVE CVE-2021-44228 che consente ad attori malintenzionati di lanciare attacchi Remote Code Execution (RCE). Ciò significa che un aggressore può inviare comandi in remoto a un server che esegue applicazioni vulnerabili.

Le versioni interessate di Apache Log4j 2 sono 2.0-beta9 a 2.15 .

Di fatto, la versione 2.15.0 che era la correzione iniziale per la vulnerabilità è stata successivamente scoperta essere ancora vulnerabile. Quindi si consiglia di aggiornare alla versione 2.16.0 che disabilita JNDI e rimuove completamente %m{lookups} .

Esistono diversi modi per difendere il tuo sistema da questa vulnerabilità e da potenziali attacchi:

• Esecuzione di scansioni per rilevare quando esiste una versione vulnerabile di Apache Log4j 2 sul tuo sistema.
• Correggere la vulnerabilità aggiornando ad Apache Log4j 2 versione 2.16.0 o disabilitando JNDI.
• Creazione di regole di rilevamento che monitorano la connessione e i log di accesso al Web per rilevare i tentativi di sfruttamento.

La chiave per combattere l'attuale ondata di attacchi è il rilevamento precoce della vulnerabilità per l'applicazione immediata di patch e il monitoraggio costante di tutte le risorse per identificare quando si tenta di sfruttare questa vulnerabilità.

Nelle sezioni seguenti esamineremo come Wazuh può aiutare con il monitoraggio e il rilevamento di questa vulnerabilità.

controlla i passaggi di installazione di wazuh qui "https://unixcop.com/wazuh-the-open-source-security-platform/"

Scansione di versioni vulnerabili di Apache Log4j 2

Utilizzeremo una politica Wazuh SCA (Security Configuration Assessment) per questo. Le politiche SCA sono scritte in formato YAML e vengono utilizzate per eseguire controlli per il rafforzamento del sistema; in molti casi anche il rilevamento di software vulnerabile rientra in questa categoria.

Salvo diversa indicazione, tutte le seguenti configurazioni sono state eseguite sul lato server Wazuh. Di solito non è necessario modificare la configurazione locale degli agenti monitorati.

Innanzitutto, creiamo un nuovo file di policy in /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'

Lo facciamo in modo che la politica SCA venga condivisa con un gruppo di agenti, che sono quelli che eseguiranno i controlli. Nel nostro caso, condividiamo la policy con il gruppo predefinito, da cui il default directory.

Nota: Tieni presente che, a seconda del sistema monitorato, find il comando utilizzato per rilevare le applicazioni vulnerabili può richiedere un utilizzo intensivo della CPU.

Inoltre, una volta creato il file della politica SCA, il proprietario e il gruppo vengono modificati in modo che possa essere utilizzato da Wazuh:

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

Successivamente, abbiamo aggiunto il blocco SCA a /var/ossec/etc/shared/default/agent.conf per abilitare la nuova policy sugli agenti Wazuh che appartengono al default gruppo:

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

Di seguito abbiamo modificato un'impostazione locale nel file di configurazione dell'agente Wazuh. Questa operazione viene eseguita direttamente sui sistemi monitorati, poiché non è possibile eseguire il push di questa impostazione dal server Wazuh. Lo scopo di questa modifica è abilitare l'esecuzione dei comandi nelle politiche SCA che vengono ricevuti dal server Wazuh. Ciò non è necessario quando tali politiche SCA sono locali per l'agente.

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

Affinché la nuova impostazione abbia effetto, abbiamo riavviato l'agente Wazuh. Il server ha inoltre eseguito il push automatico del nuovo file della politica SCA.

Possiamo vedere sotto gli eventi SCA che il sistema ha attualmente una versione vulnerabile di Log4J 2 su di esso.

Rilevamento dei tentativi di exploit di Log4Shell

Per aggiungere un altro livello di sicurezza, abbiamo creato regole che rileveranno i tentativi di sfruttamento di Log4Shell.

Per questo caso particolare, abbiamo monitorato i log di accesso al Web e cercato modelli specifici noti per essere utilizzati per questo exploit.

Abbiamo aggiunto la seguente regola al nostro server Wazuh in /var/ossec/etc/rules/local_rules.xml file:

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

Abbiamo anche riavviato il gestore Wazuh per applicare questa regola:

systemctl restart wazuh-manager

Il nostro sistema di agenti esegue un server Web Apache.

In alcuni casi, Wazuh potrebbe non monitorare già i file di registro web. Abbiamo abilitato la raccolta dei dati di registro modificando il gruppo di configurazione sul lato server Wazuh. Per questo, abbiamo aggiunto il seguente blocco a /var/ossec/etc/shared/default/agent.conf :

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

Per testare questa regola, inviamo una richiesta web con pattern Log4Shell noti al sistema monitorato. La richiesta può essere inviata da qualsiasi dispositivo dotato di connettività di rete con l'endpoint:

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

L'abbiamo subito registrato sotto gli eventi di sicurezza.

Conclusione

In sintesi, siamo stati in grado di rilevare la presenza della vulnerabilità Log4Shell utilizzando una policy SCA. Abbiamo anche creato una regola che monitora il registro di accesso al Web per rilevare quando esiste un modello di exploit noto nella richiesta Web.

Questo è utile per coloro che vogliono rimanere proattivi implementando misure che avviseranno quando c'è un'indicazione della vulnerabilità di Log4Shell.