Skip to content
KitploitKITPLOIT
ツールブログ
提出
ツールブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
CVE-2026-58073-check — 安全にVeeam Service Provider Consoleの認証バイパスCVE-2026-58073を検出する | Kitploit
ツール/GitHubGitHub/bishopfox/cve-2026-58073-check
クラウドインフラストラクチャセキュリティ脆弱性スキャナー脆弱性分析ネットワークセキュリティペネトレーションテスト
GitHubbishopfox/cve-2026-58073-check

CVE-2026-58073-check

安全にVeeam Service Provider Consoleの認証バイパスCVE-2026-58073を検出する

リポジトリを見る
1日前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

Veeam Service Provider Console エージェント偽装 — パッチ状態検出スクリプト

Veeam Service Provider Console における KB4893 脆弱性(2026-08-04 公開)のための、安全で認証不要の検出ツールです。認証や TLS の前に、ターゲットごとに1つの質問に答えます:このコンソールに KB4893 の修正が適用されているか?

主役となる2つの脆弱性は連鎖します。CVE-2026-58073(CVSS 9.5)は、認証されていないネットワーク上のピアが、接続済みの管理エージェントになりすまし、そのエージェントの実際の証明書を発行されることを可能にします。これは、エージェントのハンドシェイクが、ピアが自身の証明書に書き込んだ GUID から認可を決定するためです。CVE-2026-58072(CVSS 9.0)は、エージェントの ID を取得すると到達可能な任意のファイル書き込みです。連鎖すると、すべてのテナントのバックアップを管理するコンソール上での、認証なしのリモートコード実行となります。同じアドバイザリでは、CVE-2026-58071(CVSS 8.2、Portal Administrator としてのプロキシ化されたアプライアンス API)と CVE-2026-58067(CVSS 8.7、認証なしのメモリ枯渇 DoS)も修正されています。CVE-2026-58073 と CVE-2026-58072 は HackerOne を通じて Veeam に報告されました。アドバイザリは報告者を明示していません。

このスクリプトは、偽装の試行、証明書の要求、ファイルの書き込みを行いません。ルーターがアドバタイズするプロトコル世代を読み取るだけです。

実行しても安全ですか?

はい。この検出器は本番環境および評価での使用を想定して設計されています:

  • 認証は試行されず、どちらの脆弱性も実行されません。 存在しないレシーバーを指定した Connector ハンドシェイクのみを送信します。TLS セッションはネゴシエーションされず、証明書は提示されず、SaveFiles は呼び出されません。
  • ターゲットの状態は変更されません。 サーバーの唯一の動作は、ChannelHostProxy.m_multiplexers での失敗する辞書検索です。レシーバーは登録されず、チャネルやマルチプレクサーは構築されず、エージェントレコードには触れません。Receiver タイプのハンドシェイクは名前を登録しますが、このツールは決して送信しません。
  • ログのフットプリントは文書化され、帰属可能です。 2つの TCP 接続と ConnectionHub.log の6行で、それぞれにレシーバー名 bf-probe-<uuid4> が含まれるため、防御側はスキャンと攻撃を区別できます。正確な行は以下に示します。
  • 誤検知ガード。 ターゲットが VSPC ConnectionHub であることを証明した場合にのみ VULNERABLE と報告されます(下記参照)。したがって、静かな TCP サービスが未パッチのコンソールと誤認されることはありません。

ターゲットに残るもの

ツールはターゲットごとに2つの TCP 接続を開き、それぞれに1つの ConnectionHub ハンドシェイクを送信し、存在しないレシーバー bf-probe-<uuid4> を指定します。

デフォルトの --transport auto では、ポートが示すトランスポートと異なるトランスポートのターゲットは、追加で1接続を消費します:誤ったトランスポートのプローブは、レシーバー名が読み取られる前にハンドシェイク中に拒否され、その後、正しいトランスポートが両方の実際のプローブに使用されます。--transport direct または --transport gateway を指定すると、正確に2接続に固定できます — 変更要求で接続数を提示している場合は、これを行う価値があります。

サーバー上で変更される状態:なし。 Connector コードパスは ChannelHostProxy.m_multiplexers で辞書検索を実行し、見つからず、エラーを返します。レシーバーは登録されず、マルチプレクサーやチャネルは作成されず、TLS セッションはネゴシエーションされず、エージェントレコードには触れません。このツールは、名前を登録する唯一のタイプである Receiver タイプのハンドシェイクを決して送信しません。

ログエントリは %ProgramData%\Veeam\Veeam Availability Console\Log\Server\ConnectionHub.log に書き込まれます。ライブの 9.2.1.33875 ConnectionHub からの逐語的な内容(タイムスタンプとスコープ JSON は省略):

root@kitploit:~
probe 1 (version 6)、パッチ適用済み・未適用の両ビルド:
    [INFO] ChannelHostProxy: Accept connection begin {"RemoteEndPoint":"<ip>:<port>","Line":"1"}
    [INFO] ChannelHostProxy: Accept connection end   {"RemoteEndPoint":"<ip>:<port>","Line":"2",...}
    [WARN] ChannelHostProxy: Cannot connect transmitter. Requested receiver not found
           (receiver name:bf-probe-<uuid>) {"RemoteEndPoint":"<ip>:<port>","Line":"3",...}

probe 2 (version 7)、パッチ適用済みビルドのみ:
    同じ3行

probe 2 (version 7)、未適用ビルド:
    [INFO] ChannelHostProxy: Accept connection begin
    [WARN] ChannelHostProxy: Handshake failed. Reason:Unsupported client version "7"
    [INFO] ChannelHostProxy: Accept connection end

2接続、6行、他のエントリなし、状態変更なし — ライブホストで確認済みです。

ConnectionHub.log 内のリテラル文字列 bf-probe- はこのツールのトラフィックを識別するため、防御側はそれを帰属でき、スキャンチームは送信した内容を証明できます。別のマーカーが必要な場合は、ソース内の RECEIVER_PREFIX を変更してください。

仕組み

ConnectionHub 管理エージェントルーターは、認証や TLS の前にクライアントハンドシェイクを読み取り、Request.Read はクライアントがアドバタイズするプロトコルバージョンをハードコードされた範囲に対して検証します。修正により、CVE を修正した同じビルドでその範囲が拡大されました:

ビルドチェック受け入れ
<= 9.2.1.33875(脆弱)(uint)(versionByte - 3) <= 33, 4, 5, 6
>= 9.3.0.35057(パッチ適用済み)(uint)(versionByte - 3) <= 4

したがって、バージョン7をアドバタイズするハンドシェイクは、明確なバイナリ判別子となります。検出器はターゲットごとに2つのプローブを送信します。この順序には理由があります(トランスポート検出により3つ目が追加される場合があります — 下記参照):

プローブアドバタイズ目的
1バージョン 6Requested receiver not found を返す必要があり、ターゲットが実際に VSPC ConnectionHub であることを証明
2バージョン 7応答があれば PATCHED、沈黙なら VULNERABLE

ステージ1のゲートがないと、プローブ2の沈黙はインターネット上の静かな TCP サービスにも一致し、ファイアウォールが脆弱な Veeam コンソールとして報告されることになります。

両トランスポート、ターゲットごとに検出

管理エージェントが使用する両方のパスで動作します:

トランスポートポート露出
ConnectionHub への直接9999通常は内部
Veeam Cloud Connect ゲートウェイ経由6180設計上インターネットに面している

ゲートウェイパスには、直接パスにはないリレープロローグが必要です。そのため、プローブ1はトランスポート検出を兼ねます。デフォルトの --transport auto では、1つのトランスポートを試し、フィンガープリントゲートが通過しない場合は、もう1つを試します。通過した方がラッチされ、プローブ2はそれを再利用します — 混在するターゲットファイルにホストごとの注釈は不要です。

ラッチは重要な役割を果たします。プローブ2が他のトランスポートで再試行できる場合、沈黙はバージョンチェックに帰属できなくなり、「2つのバイトパスのうち1つが応答しなかった」というだけになり、それが誤った VULNERABLE が生成される方法です。

どちらのトランスポートが最初に試されるかはポートによって決まり、これは見た目だけの問題ではありません — 2つの不一致は非常に異なる速度で失敗します:

不一致相手側の解釈コスト
リレープローローグ → 直接ハブhostType 44 / versionByte 0 の int16 メタ、Request.Read の範囲チェックに失敗1ラウンドトリップで破棄
直接ハンドシェイク → ゲートウェイ1,012,729,346 の int32 フレーム長ゲートウェイは決して届かないバイトを待ち、完全なタイムアウトを消費

したがって、auto はポートを所有するサービスを先頭にします:6180 ではゲートウェイが先、それ以外では直接が先です。これにより、一般的なケースは単一の試行に保たれ、高コストの不一致は高速パスから外れます。TCP を開けないプローブは、2番目のトランスポートを試さずに短絡するため、広範囲スイープでの死んだホストは1タイムアウトで済み、2つではありません。

正確なビルドではなく、プロトコル世代を報告

VULNERABLE は「KB4893 の修正が存在しない」ことを意味し、「これが 9.2.1.33875 である」ことを意味しません。9.2.1 より古いビルドは同じバージョンチェックを共有するため、プロトコル6を報告し、脆弱として報告されるべきです(コードから推定され、測定されたものではありません — 制限事項 を参照)。ただし、ツールは 9.2.1 と 9.1 や 8.1 を区別できません。正確なビルドが必要な場合は、コンソール UI で確認してください。

要件

  • Python 3.8+、標準ライブラリのみ — サードパーティパッケージは不要です。

使用方法

root@kitploit:~
# 単一ホスト(デフォルト TCP/9999)
./cve_2026_58073_check.py vspc.example.com

# 明示的なポート、複数ホスト
./cve_2026_58073_check.py vspc.example.com:9999 10.0.0.5

# リストをスキャン、1行に1ターゲット('#' コメント可)、コンパクト出力
./cve_2026_58073_check.py -f targets.txt --brief

# パイプライン用の機械可読出力
./cve_2026_58073_check.py -f targets.txt --json > results.json

# Veeam Cloud Connect ゲートウェイ — リレートランスポートは自動検出されます
./cve_2026_58073_check.py cc-gw.example.com:6180

# トランスポートを固定して検出をスキップ(ポートはデフォルトで 6180 になります)
./cve_2026_58073_check.py --transport gateway cc-gw.example.com

# ネットワークアクセスなしでワイヤーコーデックを検証
./cve_2026_58073_check.py --self-test

オプション

例

未パッチのコンソール(デフォルトの2行出力)。[!] マーカーと VULNERABLE は TTY で赤く表示されます:

root@kitploit:~
$ ./cve_2026_58073_check.py vspc.example.com
[!] vspc.example.com:9999: VULNERABLE  [protocol-7-rejected]
      ConnectionHub rejects protocol 7 but accepts 6, so the KB4893 fixes are absent (<= 9.2.1.33875)

パッチ適用済みのコンソール:

root@kitploit:~
$ ./cve_2026_58073_check.py patched.example.com
[+] patched.example.com:9999: PATCHED  [protocol-7-accepted]
      ConnectionHub accepts protocol 7, so the KB4893 fixes are present (>= 9.3.0.35057)

ゲートウェイターゲット、リレートランスポートが自動検出されます。(gateway) サフィックスは、判定が行われたトランスポートを示します:

root@kitploit:~
$ ./cve_2026_58073_check.py cc-gw.example.com:6180
[!] cc-gw.example.com:6180 (gateway): VULNERABLE  [protocol-7-rejected]
      ConnectionHub rejects protocol 7 but accepts 6, so the KB4893 fixes are absent (<= 9.2.1.33875)

環境全体のスイープ、ホストごとに1つの整列された行(--brief)。終了ステータスは、いずれかのホストが VULNERABLE の場合は 1、それ以外は 0 — スクリプトに便利です:

root@kitploit:~
$ ./cve_2026_58073_check.py -f targets.txt --brief; echo "exit: $?"
VULNERABLE    vspc.example.com:9999            protocol-7-rejected
PATCHED       patched.example.com:9999         protocol-7-accepted
UNAFFECTED    fileserver.example.com:9999      not-vspc
ERROR         unused.example.com:9999          unreachable
exit: 1

パイプライン用の機械可読出力(--json)。ターゲットごとにすべてのプローブが含まれるため、発見事項は証拠から再導出でき、信頼する必要はありません。transport は判定が行われたトランスポートであり、各プローブは使用したトランスポートを保持します — したがって、自動検出されたターゲットは拒否された試行も表示します:

root@kitploit:~
$ ./cve_2026_58073_check.py vspc.example.com --json
[
  {
    "target": "vspc.example.com:9999",
    "host": "vspc.example.com",
    "port": 9999,
    "transport": "direct",
    "verdict": "VULNERABLE",
    "reason": "protocol-7-rejected",
    "detail": "ConnectionHub rejects protocol 7 but accepts 6, so the KB4893 fixes are absent (<= 9.2.1.33875)",
    "protocol_version": 6,
    "affected_cves": [
      "CVE-2026-58073",
      "CVE-2026-58072",
      "CVE-2026-58071",
      "CVE-2026-58067"
    ],
    "probes": [
      {
        "version_byte": 6,
        "transport": "direct",
        "connected": true,
        "responded": true,
        "status": "Error",
        "message": "Cannot connect transmitter. Requested receiver not found (receiver name:bf-probe-b7c40be0-e2e8-41dc-9fc3-cbbd7345954a)",
        "error": ""
      },
      {
        "version_byte": 7,
        "transport": "direct",
        "connected": true,
        "responded": false,
        "status": "",
        "message": "",
        "error": ""
      }
    ]
  }
]

判定

終了コード

コード意味
0VULNERABLE のターゲットなし
1少なくとも1つのターゲットが VULNERABLE
2使用法エラー(不正な引数 / 読み取り不能なターゲットファイル)

制限事項

  • ビルド番号ではなく、プロトコル世代。 上記の 正確なビルドではなく、プロトコル世代を報告 を参照してください。
  • ゲートウェイトランスポートはモックリレーに対してのみ実行されています。 プロローグとバイト単位のパススルーは、逆コンパイルされた Cloud Connect ゲートウェイコードから導出され、そこから作成したモックに対して実行されました。本番の Cloud Connect ゲートウェイに対しては実行されていません。これは --transport auto のゲートウェイ区間にも適用されます。--transport direct を指定して、未テストのパスをスイープから完全に除外してください。
  • 露出のみ。 VULNERABLE の判定はパッチ状態を示すものであり、誰かがコンソールを悪用したかどうかを示すものではありません。悪用は、パッチ適用済み・未適用の両ビルドでコンソールのログに独自の痕跡を残します。それらは別途調査してください。
  • 到達可能性。 結果は、実行するネットワーク位置からコンソールが応答する内容を反映します。

修復

Veeam Service Provider Console 9.3.0.35057 以降にアップグレードしてください(KB4893)。4つの問題はすべてその1つのビルドで修正されており、9.2.x へのバックポートはないため、修復はホットフィックスではなくバージョンアップグレードです。

アップグレードが行わない2つのことがあります。TCP/9999 に到達できるユーザーを制限しません。これは、管理エージェントが存在するサブネットのみに応答する必要があります。また、コンソールがすでに発行したエージェント証明書(未パッチの間に攻撃者に発行されたものを含む)を失効させません。悪用の証拠を見つけた場合は、侵害されたエージェント証明書のガイダンスについて Veeam サポートのケースを開いてください:それらのローテーションは文書化された手順ではなく、ポータルで管理できる証明書はエージェント証明書に署名する CA ではありません。

ライセンス

このコードは MIT ライセンス の下で配布されています。

法的免責事項

事前の相互同意なしにターゲットを攻撃するためのこのツールの使用は違法です。適用されるすべての地域、州、連邦法を遵守する責任はエンドユーザーにあります。開発者は一切の責任を負わず、このプログラムによって引き起こされた誤用や損害について責任を負いません。

関連情報

  • Veeam KB4893 — ベンダーアドバイザリと修正ビルド
  • NVD — CVE-2026-58073
  • NVD — CVE-2026-58072
ツールをダウンロード
3, 4, 5, 6, 7
フラグ説明
targets1つ以上の HOST[:PORT](ポートはデフォルトで 9999、--transport gateway では 6180)
-f, --targets-file FILEファイルからターゲットを読み取る(1行に1つ、# コメント)
--transport {auto,direct,gateway}ConnectionHub への到達方法。auto(デフォルト)はターゲットごとに検出、gateway は Cloud Connect リレープローグを前置し、ポートをデフォルトで 6180 にします
-p, --port PORTデフォルトポートを上書き
--timeout SECSプローブごとのタイムアウト(デフォルト:8)
--workers N同時ターゲット数(デフォルト:16)、出力は入力順を維持
-b, --briefターゲットごとに1つの整列された行 — 多数のホストのスキャンに最適
--json構造化 JSON を出力、ターゲットごとに送信されたすべてのプローブを含む
--no-color色付き出力を無効化(NO_COLOR と非 TTY も尊重)
--self-test.NET ワイヤーコーデックを検証して終了、ネットワークアクセスなし
判定理由タグ意味
VULNERABLEprotocol-7-rejectedプロトコル6を受け入れ、7を拒否する確認済みの VSPC ConnectionHub。KB4893 の修正が存在しない(<= 9.2.1.33875)。
PATCHEDprotocol-7-acceptedプロトコル7を受け入れる確認済みの VSPC ConnectionHub。KB4893 の修正が存在する(>= 9.3.0.35057)。
UNAFFECTEDnot-vspcTCP は受け入れたが、試行したどのトランスポートでも有効な ConnectionHub ハンドシェイクに応答しなかったため、VSPC ConnectionHub ではない。
INCONCLUSIVEunexpected-replyフィンガープリントプローブに Requested receiver not found 以外の応答を返した。
INCONCLUSIVEinconclusive-discriminatorフィンガープリントゲートを通過した後、バージョン7プローブに合格でも不合格でもない方法で応答した — または2番目の接続が完全に失敗した。再試行してください。
ERRORunreachable接続できなかった、または Cloud Connect ゲートウェイが最初に試したトランスポートでリレープローグを拒否した(auto では、ポート 6180 の任意のターゲットを意味します)。