GNU/Linux >> Linux の 問題 >  >> Linux

WazuhによるLog4Shellの検出

今回は、Wazuhを使用したLog4Shellの検出について学習します

Apache Log4Jは、Javaで最も一般的なログライブラリの1つであり、主にエラーメッセージに使用されます。これは、iCloud、Twitter、Minecraftなどの価値の高いアプリケーションの一部です。

最近、CVECVE-2021-44228を使用したLog4Shellと呼ばれるゼロデイ脆弱性がApacheのLog4J2で検出され、悪意のある攻撃者がリモートコード実行（RCE）攻撃を開始できるようになりました。これは、加害者が脆弱なアプリケーションを実行しているサーバーにリモートでコマンドを送信できることを意味します。

影響を受けるApacheLog4j2のバージョンは2.0-beta9です。 2.15へ 。

実際のところ、バージョン2.15.0 これは脆弱性の最初の修正であり、後でまだ脆弱であることが発見されました。したがって、バージョン2.16.0に更新することをお勧めします これにより、JNDIが無効になり、%m{lookups}が完全に削除されます。 。

この脆弱性と潜在的な攻撃からシステムを守る方法はいくつかあります。

  • スキャンを実行して、脆弱なバージョンのApacheLog4j2がシステムに存在するかどうかを検出します。
  • ApacheLog4j2バージョン2.16.0に更新して脆弱性をパッチする またはJNDIを無効にします。
  • 接続ログとWebアクセスログを監視して悪用の試みを検出する検出ルールを作成します。

現在の攻撃の波に対抗するための鍵は、即時パッチ適用のための脆弱性の早期発見と、この脆弱性を悪用する試みがいつあるかを特定するためのすべての資産の継続的な監視です。

次のセクションでは、Wazuhがこの脆弱性の監視と検出にどのように役立つかを見ていきます。

ここでwazuhのインストール手順を確認してください「https://unixcop.com/wazuh-the-open-source-security-platform/」

ApacheLog4j2の脆弱なバージョンをスキャンする

これには、Wazuh SCA（セキュリティ構成評価）ポリシーを利用します。 SCAポリシーはYAML形式で記述されており、システム強化のチェックを実行するために使用されます。多くの場合、脆弱なソフトウェアの検出もこのカテゴリに分類されます。

特に明記されていない限り、以下の構成はすべてWazuhサーバー側で行われました。通常、監視対象のエージェントのローカル構成を編集する必要はありません。

まず、/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'

これは、SCAポリシーが、チェックを実行するエージェントのグループと共有されるようにするためです。この例では、ポリシーをデフォルトグループと共有しているため、default ディレクトリ。

注： 監視対象のシステムによっては、findに注意してください。 脆弱なアプリケーションを検出するために使用されるコマンドは、CPUを集中的に使用する可能性があります。

さらに、SCAポリシーファイルが作成されると、所有者とグループが変更され、Wazuhが使用できるようになります。

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

次に、SCAブロックを/var/ossec/etc/shared/default/agent.confに追加しました defaultに属するWazuhエージェントで新しいポリシーを有効にします グループ：

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

以下では、Wazuhエージェント構成ファイルのローカル設定を編集しました。 Wazuhサーバーからこの設定をプッシュする方法がないため、これは監視対象のシステムで直接実行されます。この変更の目的は、Wazuhサーバーから受信したSCAポリシーのコマンドを実行できるようにすることです。これらのSCAポリシーがエージェントに対してローカルである場合、これは必要ありません。

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

新しい設定を有効にするために、Wazuhエージェントを再起動しました。サーバーは、新しいSCAポリシーファイルも自動的にプッシュしました。

SCAイベントの下で、システムに現在脆弱なLog4J2バージョンがあることがわかります。

Log4Shellエクスプロイトの試みの検出

セキュリティの別のレイヤーを追加するために、Log4Shellの悪用の試みを検出するルールを作成しました。

この特定のケースでは、Webアクセスログを監視し、このエクスプロイトに使用されることがわかっている特定のパターンを探しました。

/var/ossec/etc/rules/local_rules.xmlのWazuhサーバーに次のルールを追加しました ファイル：

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

また、このルールを適用するためにWazuhマネージャーを再起動しました：

systemctl restart wazuh-manager

エージェントシステムはApacheWebサーバーを実行しています。

場合によっては、WazuhがまだWebログファイルを監視していない可能性があります。 Wazuhサーバー側の構成グループを変更することでログデータの収集を可能にしました。このために、次のブロックを/var/ossec/etc/shared/default/agent.confに追加しました。 ：

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

このルールをテストするために、既知のLog4Shellパターンを含むWebリクエストを監視対象システムに送信します。リクエストは、エンドポイントとのネットワーク接続がある任意のデバイスから送信できます：

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

すぐにセキュリティイベントでログに記録されました。

結論

要約すると、SCAポリシーを利用することで、Log4Shellの脆弱性の存在を検出することができました。また、Webアクセスログを監視して、既知のエクスプロイトパターンがWebリクエストに存在することを検出するルールを作成しました。

これは、Log4Shellの脆弱性の兆候が見られたときにアラートを出す手段を実装することで、プロアクティブな状態を維持したい場合に役立ちます。


Linux

  1. trace-cmdを使用したカーネルトレース

  2. 例を含むNohupコマンド

  3. LinuxでのJQコマンドと例

  1. LVMを使用してLinuxをインストールする

  2. Ddでバイナリにパッチを適用しますか？

  3. C での 64 ビット コンパイルの検出

  1. Linuxでduをdustに置き換えます

  2. 例を含むwcLinuxコマンド

  3. Linuxipコマンドと例