この脆弱性はクリスマス直前に発覚し、最悪の場合、認証されていない攻撃者がリモートでサーバーのメモリを読み取ることを可能にしていました。修正プログラムは既に提供されていますが、影響範囲は広大です：この問題は過去10年近く遡るほぼ全てのMongoDBリリースに影響を及ぼしています。
この脆弱性は「MongoBleed」（CVE-2025-14847）と命名され、MongoDBサーバーにおける認証前の脆弱性である。zlib圧縮プロトコルヘッダー内の長さの不一致フィールドに起因し、これによりサーバーが未初期化のヒープメモリを認証されていないクライアントに返す可能性がある。 平たく言えば：攻撃者がネットワーク経由でMongoDBインスタンスに到達できれば、ログインすることなくメモリ内容を「流出」させようとする試みが可能となる。
MongoDBの公式課題管理システムは修正策を明示しており、サポート対象の全ブランチ（8.2.3、8.0.17、7.0.28、6.0.27、5.0.32、または4.4.30）において修正済みリリースへのアップグレードをユーザーに強く推奨しています。
MongoBleedが特に懸念される理由は、その悪用が極めて容易である点にある。 公開された概念実証コードは既に利用可能で、到達可能なMongoDBサーバーのIPアドレスさえあれば実行できる。攻撃者はそこから漏洩したメモリをくまなく探索し、平文で保存されたデータベース認証情報、クラウドアクセスキー、その他の機密情報といった高価値な秘密情報を盗み出せる。このエクスプロイトはまさにこうした秘密情報を狙うために設計されており、現実世界での悪用を劇的に容易にしている。
至る所に見つかるMongoDB：Vectra を用いた露出、横方向のリスク、悪用のVectra
搾取を心配する前に、もっと基本的な質問に答えなければならない：
私の環境では、MongoDBは実際にどこで実行されていますか？
それは些細なことのように聞こえる。そうではない。
レガシーアプリケーション、シャドーIT、クラウド実験、コンテナ化されたワークロード、そして「一時的」なはずが恒久化したデータベースなど、MongoDBは誰も所有を覚えていない場所に突然現れる習性がある。Shodanによれば、現在20万以上のMongoDBインスタンスがインターネットに公開されている。これは氷山の一角に過ぎない。
より興味深い（そしてより危険な）問題は、あなたのネットワーク内部で何が起きているかです：
- 侵害されたホストからアクセス可能なMongoDBインスタンス
- 非標準ポートにバインドされたデータベース
- 認証の仮定なしに実行されるサービス
- 内部データベースは、横移動や権限昇格の完璧な足掛かりとなる
ネットワークレベルの可視性が重要となる場面こそ、Vectra 真価を発揮する領域です。
Vectra深いネットワーク可視性と豊富なメタデータにより、ポート、プロトコル、デプロイメントモデルを問わず、あらゆる場所のMongoDBを検知するために必要な素材は既に揃っています。メタデータだけでは不十分な場合、Vectra Match Suricata）がプロトコル認識型シグネチャによりさらに一歩踏み込んだ検知を可能にします。
これを分解してみよう。
1. ネットワーク上のMongoDBインスタンスの特徴
MongoDBを効果的に追跡するには、通信時の動作を理解する必要があります。
デフォルトネットワーク特性
大まかに言えば、MongoDBはTCPベースのクライアント・サーバープロトコルである。
共通の特徴には以下が含まれる：
- デフォルトのTCPポート:27017
- 一般的な代替ポート:27018、27019、またはコンテナ化/クラウド環境における任意の高ポート
- 長寿命のTCPセッション：クライアントは接続をオープンに保つことが多い
- 双方向リクエスト/レスポンストラフィック：単なる短いバーストではない
しかし、ポートベースの検知だけでは脆弱である——攻撃者も管理者もそのことを知っている。
MongoDB ワイヤプロトコル（平文）
TLSが有効化されていない場合、MongoDBの通信はネットワーク上で完全に可視化されます。
MongoDBワイヤプロトコルの主な特徴：
- 標準メッセージヘッダーを持つバイナリプロトコル
- ヘッダーフィールドには以下が含まれます：
- メッセージの長さ
- リクエストID
- IDへの応答
- オペコード（例：OP_MSG、OP_QUERY、レガシーオペコード）
- 初期のパケットにはしばしば以下が含まれる：
- クライアントハンドシェイク（isMaster / hello）
- ドライバーのメタデータ（言語、バージョン）
- 認証ネゴシエーション
ネットワークの観点から見ると、これにより次のことが得られる：
- サーバー応答をクリアする
- 識別可能なプロトコル構造
- 接続確立時の予測可能なリクエストパターン
言い換えれば：指紋認証が容易であり、非標準ポートでも同様である。
TLSを有効化したMongoDB
TLSは事態を複雑にするが、MongoDBを不可視にするわけではない。
TLSが有効な場合：
- ペイロードは暗号化されています
- プロトコルの内容は非表示です
- ただしセッションの動作とメタデータは残る
今もなお目にするもの：
- TCP宛先と送信元
- ポートの使用（非標準であっても）
- セッション時間
- バイト数と方向性
- 証明書メタデータ（利用可能な場合）
- サーバー名
- 発行者
- ホスト間での証明書の再利用
これは極めて重要です。なぜなら、現実世界の環境のほとんどは混合環境だからです：
- 一部のMongoDBインスタンスはTLSを使用します
- 他の人たちはそうしない
- 一部は平文から始まり、アップグレードする
- 一部は内部の「信頼できるネットワーク」という前提に依存している
VectraメタデータVectra、トラフィックを復号することなく、これらの差異を可視化します。
MongoBleedにとってこれが重要な理由
MongoBleedは、事前認証不要でネットワーク経由で到達可能な脆弱性です。
つまり：
- インターネットに公開されたMongoDB＝即時リスク
- 内部からアクセス可能なMongoDB＝侵害後の金鉱
- TLSは脆弱性を除去しない
- 認証は脆弱性を除去しない
攻撃者が接続できれば、彼らは調査できる。
2. ネットワークメタデータを用いたMongoDBインスタンスの追跡
ここで理論から実践へと移る。
Vectra 強化されたネットワークメタデータを生成し、ログ、エージェント、資産インベントリに依存することなくMongoDBインスタンスを特定することを可能にします。
インターネットに公開されたMongoDBインスタンスの発見
主要な探索手法：
- インターネットからの着信接続を受け入れる内部ホストを特定する
- フィルター対象:
- サーバーのような動作をするTCPサービス
- 長寿命セッション
- 多様な送信元IPアドレスからの繰り返し受信接続
- 相関する：
- 既知のMongoDBデフォルトポート
- 異常なポートへの高エントロピーなインバウンドトラフィック
- 複数のMongoDBリスナー間で再利用されるTLS証明書
これがすぐに表面化する：
- 忘れられたクラウド仮想マシン
- テストデータベースが誤って公開される
- 「一時的」だったサービスが恒久化した
そして、Shodanとは異なり、これはスキャン結果ではなく、実際のあなたの露出です。
SELECT
id.resp_h,
レスポンスホスト名.name,
COUNT(*) AS connection_count
FROM network.isession._all
WHERE id.resp_p = 27017
AND local_orig = FALSE
AND local_resp = TRUE
AND タイムスタンプ BETWEEN date_add('日', -14, now()) AND now()
id.resp_h、resp_hostname.name でグループ化
ORDER BY connection_count DESC
上限100
このシナリオでは、使用されているTCPポートに関係なく、TLS経由で動作するMongoDBサーバーの特定に焦点を当てます。暗号化されたトラフィックではペイロードの検査が不可能なため、TLSフィンガープリンティング、特にJA3およびJA4に依存します。これらはVectra によって観測された各TLSセッションに対して自動的に計算され、ネットワークメタデータに追加されます。
JA3およびJA4は、サポートされる暗号スイート、拡張機能、プロトコルバージョンなど、TLSハンドシェイクの特性をハッシュ化することでTLSクライアントのフィンガープリントを検出します。これに対応するサーバーサイドのJA3SおよびJA4Sは、TLSサーバー応答のフィンガープリントを取得するため、トラフィックを復号せずにサーバー技術を特定するのに特に有用です。
実際には、これにより非標準ポートで動作している場合やトランスポート層では区別がつかない場合でも、TLSのネゴシエーション方法に基づいてMongoDB TLSサーバーを特定することが可能になります。
ただし、JA3SおよびJA4Sのフィンガープリントはグローバルに一意ではない点に留意する必要があります。異なるサーバースタックやライブラリ間で類似のフィンガープリントが共有される可能性があり、衝突が発生する可能性があるため、コンテキストが依然として重要となります。
とはいえ、複数のMongoDBバージョンにわたるテストでは、JA3SおよびJA4Sのフィンガープリントはリリース間で高い一貫性を示しており、ネットワーク動作、セッションパターン、エンドポイントコンテキストと組み合わせることで信頼性の高い指標となる。
非標準ポート上のMongoDBサーバーの探索
既知のポートにバインドされていないMongoDBサーバーを特定するには、追加の分析とコンテキストが必要です。このようなケースでは、単純なポートベースのフィルタリングでは不十分であり、ネットワークメタデータから導出された高次元の指標に依存する必要があります。
効果的なアプローチの一つは、レスポンダのホスト名やTLSサーバー名インジケーション（SNI）などのサーバー側識別子を調査し、データベースインフラストラクチャを示唆するパターンを探すことです。 データベースの役割、クラスター、シャード、レプリカセットを参照するホスト名は、たとえ予期しないポートでリスニングしている場合でも、対象サービスがMongoDBバックエンドである可能性を強く示唆します。
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
FROM network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
AND local_orig = FALSE
AND local_resp = TRUE
AND タイムスタンプ BETWEEN date_add('日', -14, now()) AND now()
ORDER BY timestamp DESC
上限1000
宛先ポートも考慮に入れる場合:
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
FROM network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
AND id.resp_p = 27017
AND local_orig = FALSE
AND local_resp = TRUE
AND タイムスタンプ BETWEEN date_add('日', -14, now()) AND now()
ORDER BY timestamp DESC
上限1000
注記:MongoDBにはデフォルトのTLS証明書や秘密鍵は同梱されていません。TLSを有効化する際は、管理者が明示的に独自の証明書と鍵素材を提供する必要があります。さらに、MongoDBはTLSが有効な場合、デフォルトでTLS 1.3を使用します。これは、従来の証明書やx.509メタデータがネットワークテレメトリに公開されないことを意味します。
内部のMongoDBインスタンスの検出
内部のMongoDBは、外部への露出よりも危険な場合が多い。
なぜ？
- 攻撃者はインターネットをスキャンする必要はない
- 侵害されたホストは自由に列挙できる
- 内部データベースはしばしば強化が不十分である
狩猟パターンには以下が含まれる：
- 東西方向のTCPサービスが永続サーバーとして機能する
- アプリケーション層からの繰り返し接続
- 既知のMongoDB振る舞い （セッション長、リクエスト間隔）
- 多くの異なる内部ホストからアクセス可能なサービス
これはすぐに明らかになる：
- どこからでもアクセス可能なデータベース
- フラットネットワーク設計の問題点
- 理想的な横方向移動の目標
SELECT
id.resp_h,
レスポンスホスト名.name,
COUNT(*) AS connection_count
FROM network.isession._all
WHERE id.resp_p = 27017
AND local_orig = FALSE
AND local_resp = TRUE
AND タイムスタンプ BETWEEN date_add('日', -14, now()) AND now()
id.resp_h、resp_hostname.name でグループ化
ORDER BY connection_count DESC
上限100
ここでもJA3SとJA4Sを使用できます:
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
FROM network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
AND local_orig = TRUE
AND local_resp = TRUE
AND タイムスタンプ BETWEEN date_add('日', -14, now()) AND now()
ORDER BY timestamp DESC
上限1000
宛先ポートも考慮に入れる場合:
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
FROM network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
AND id.resp_p = 27017
AND local_orig = TRUE
AND local_resp = TRUE
AND タイムスタンプ BETWEEN date_add('日', -14, now()) AND now()
ORDER BY timestamp DESC
上限1000
潜在的なMongoBleed悪用の探索
ペイロードの可視性がなくても、悪用試行は痕跡を残す。
確認事項：
- MongoDBサービスへの異常な接続試行
- 予期せぬホストからの短命で繰り返される接続
- これまでMongoDBを使用したことがないシステムからの新しいMongoDBクライアントの動作
- 接続の急激な増加
- 非アプリケーションシステム（ワークステーション、ジャンプホスト、侵害されたサーバー）に由来するMongoDBトラフィック
これらは典型的な兆候です：
- 偵察
- 脆弱性テスト
- 自動メモリプロービング
Vectra視点Vectra、特にアイデンティティとホストコンテキストと組み合わせることで、この点を即座に際立たせます。
SELECT
id.orig_h,
id.resp_h,
id.resp_p,
期間
接続状態
タイムスタンプ
orig_ip_bytes,
応答IPバイト数
FROM network.isession._all
WHERE conn_state IN ('SF')
AND duration < 5000
AND orig_ip_bytes = 44
AND first_orig_resp_data_pkt = 'LAAAAAEAAAAAAAAA3AcAAA=='
AND タイムスタンプ BETWEEN date_add('日', -14, now()) AND now()
ORDER BY timestamp DESC
上限100
このクエリは、暗号化されていないMongoDBトラフィックを検索する方法の例です。最初のパケットのサイズは44バイトで、圧縮されたメッセージを定義するMongoDBヘッダーが含まれています。
MongoDBヘッダーのフォーマットは以下のように定義されます：
公開されたPoCは、44バイトの長さとオペコード2012（圧縮データ）を使用しています。
3.Vectra Match Suricata）のさらなる活用
メタデータは大きな助けとなる。Vectra Match 精度Match 。
Suricataベースのシグネチャを使用することで、MongoDBトラフィックと悪用パターンを明示的に特定できます。Vectra Match 商用ETProルールセットを基にしており、MongoBleed向けに以下の2つのルールを含みます。1つ目は検知 認証試行検知 、2つ目は検知 。Vectra Match ルールセットに含まれています。
潜在的な悪用使用の検出
MongoBleedに関しては、特に以下の署名が対象となります：
- 不正なプロトコル長または異常なプロトコル長
- 認証なしでの繰り返しハンドシェイク試行
- メモリ開示の試みと一致するプロトコル異常
- MongoDBサービスに対する高頻度プローブ行為
これはCVE固有のペイロードだけに依存するものではなく、攻撃者が回避するのがはるかに困難な動作に焦点を当てている。
alert tcp any any -> $HOME_NET 27017 (msg:"ET INFO MongoDB SASL 認証検出"; flow:established,to_server; flowbits:set,ET.MongoDB_Auth_Attempt; flowbits:noalert; content:"|dd 07 00 00|"; offset:12; depth:4; content:"saslstart"; fast_pattern; nocase; distance:0; reference:url,www.alienfactory.co.uk/articles/mongodb-scramsha1-over-sasl; classtype:misc-activity; sid:2066500; rev:1; metadata:affected_product MongoDB, attack_target Server, created_at 2025_12_29, deployment Perimeter, confidence High, signature_severity Informational, updated_at 2025_12_29; target:dest_ip;)
alert tcp any any -> $HOME_NET 27017 (msg:"ET EXPLOIT MongoDB Unauthenticated Memory Leak (CVE-2025-14847)"; flow:established,to_server; flowbits:isnotset,ET.MongoDB_Auth_Attempt; content:"|dc 07 00 00 dd 07 00 00|"; fast_pattern; offset:12; depth:8; content:"|02|"; distance:4; within:1; threshold:type threshold, track by_src, count 10, seconds 120; reference:url,bigdata.2minutestreaming.com/p/mongobleed-explained-simply; reference:cve,2025-14847; classtype:attempted-admin; sid:2066501; rev:1; metadata:affected_product MongoDB, attack_target Server, created_at 2025_12_29, cve CVE_2025_14847, deployment Perimeter, deployment Internal, confidence Low, signature_severity Major, updated_at 2025_12_29; target:dest_ip;)
平文、TLS、および非標準ポート — 対象範囲
これらすべての狩りを通じて、重要な教訓は単純明快だ：
- 平文MongoDB:プロトコル + メタデータ + 署名
- TLS MongoDB:メタデータ +振る舞い + 証明書
- 非標準ポート：動作は常にポートに勝る
攻撃者はMongoDBがどのポートで動作しているかを気にしない——防御側も同様に気にする必要はない。
監視対象と追跡対象の区別
当直医を呼ぶ
- インターネットに公開されているMongoDBは、不明なIPアドレスからのインバウンドバーストが発生している
- 内部のMongoDBサーバーは「スキャナーのような」接続集中が発生する
- 新規クライアントは非標準ポートでMongoDBプロトコル通信を開始する
狩りをするとき
- 非標準ポート（Tier 2）でMongoDBプロトコルを確認しました
- 不審な送信元からの認証試行を確認しました（レベル3）
- ペイロードの可視性がない場合でも、短命な接続の急増を確認できます（レベル2）
緩和策（検出はパッチ適用に代わるものではないため）
MongoDBの修正ガイダンスは明快です：修正済みバージョン（8.2.3 / 8.0.17 / 7.0.28 / 6.0.27 / 5.0.32 / 4.4.30）へアップグレードしてください。(jira.mongodb.org)
NVDはこの脆弱性をzlibヘッダーにおける長さフィールドの不一致により、認証不要でヒープ読み取りを可能にするものとして要約している。(NVD)
公開されたPoCが存在するため、攻撃者の労力が軽減される。(GitHub)
なぜこれが重要なのか？
MongoBleedは、データベースが受動的なインフラではないことを改めて示す最新の事例だ。それらは能動的な攻撃対象である。
答えられない場合は：
- MongoDBはどこで実行されていますか？
- 誰がそれに届くことができるのか？
- 今、誰がそれに触れているのか？
…それだけでは、パッチだけでは救えない。
Vectra 、これらの疑問に答える可視性を提供します。さらに「メモリリーク」が大規模な侵害に発展する前に、行動を起こすための検知・追跡能力を備えています。