CVE-2025-14847 MongoBleed in the Wild: ネットワークメタデータによるMongoDBの露出と悪用の特定 by Fabien Guillot

この脆弱性はクリスマス直前の数日前に表面化し、最悪の場合、未認証の攻撃者がサーバーメモリをリモートから読み取ることを可能にしました。修正はすでに提供されていますが、影響範囲（blast radius）は大きく、この問題は過去ほぼ 10 年にわたる実質的にすべての MongoDB リリースに影響します。

「MongoBleed」(CVE-2025-14847) と呼ばれるこの欠陥は、MongoDB Server における認証前（pre-auth）の脆弱性です。zlib 圧縮されたプロトコルヘッダー内の長さフィールドの不整合に起因し、サーバーが未認証クライアントに対して未初期化のヒープメモリを返してしまう可能性があります。平たく言えば、攻撃者がネットワーク越しに MongoDB インスタンスへ到達できるなら、ログインせずともメモリ内容を「漏出（bleed）」させる試行が可能です。

MongoDB 自身のイシュートラッカーでも対処方法は明確に示されており、サポート対象の全ブランチで修正済みリリース（8.2.3、8.0.17、7.0.28、6.0.27、5.0.32、または 4.4.30）へのアップグレードが強く推奨されています。

MongoBleed が特に懸念されるのは、悪用のハードルが非常に低いことです。公開された PoC（概念実証コード）がすでに存在し、必要なのは到達可能な MongoDB サーバーの IP アドレス程度です。そこから攻撃者は漏出したメモリを漁り、価値の高いシークレットを探し出せます。たとえば平文で保存されているデータベース認証情報、クラウドアクセスキー、その他の機密情報などです。このエクスプロイトはまさにこうした種類のシークレットを狙うよう設計されており、現実の悪用のハードルを大きく下げています。

どこにでもある MongoDB を見つける：Vectra を使って露出、横展開リスク、悪用を特定する

悪用を心配する前に、より基本的な質問に答える必要があります。

自分の環境のどこで実際に MongoDB が動いているのか？

一見簡単そうに聞こえます。実際はそうではありません。

レガシーアプリケーション、シャドー IT、クラウド実験、コンテナ化されたワークロード、「一時的」だったはずなのにいつの間にか恒久化したデータベースなどが混在する中で、MongoDB は「誰が所有していたか誰も覚えていない場所」に突然現れがちです。Shodan によれば、現在インターネットに 200,000 以上の MongoDB インスタンスが露出しています。これは氷山の一角にすぎません。

より興味深く (そしてより危険な）のは、ネットワーク内部で何が起きているかです。

侵害されたホストからアクセス可能なMongoDBインスタンス

非標準ポートにバインドされたデータベース

認証の仮定なしに実行されるサービス

内部データベースは、　ラテラルムーブメントや権限昇格の完璧な足掛かりとなる

ここで重要になるのがネットワークレベルの可視性であり、Vectra AIプラットフォームが強みを発揮する領域です。

Vectra の深いネットワーク可視性と強化されたメタデータがあれば、ポート、プロトコル、デプロイモデルに依存せず MongoDB をどこでもハントするための素材はすでに揃っています。そしてメタデータだけでは不十分な場合でも、Vectra Match（Suricata）を使えば、プロトコルを理解したシグネチャでさらに一段踏み込めます。

これを分解してみましょう。

1. ネットワーク上のMongoDBインスタンスの特徴

MongoDBを効果的に追跡するには、通信時の動作を理解する必要があります。

デフォルトネットワーク特性

大まかに言えば、MongoDBはTCPベースのクライアントサーバープロトコルです。

共通の特徴には以下が含まれます。

デフォルトのTCPポート:27017

一般的な代替ポート:27018、27019、またはコンテナ化/クラウド環境における任意の高ポート

長寿命のTCPセッション：クライアントは接続をオープンに保つことが多い

双方向リクエスト/レスポンストラフィック：単なる短いバーストではない

しかし、ポートベースの検知だけでは脆弱であり、攻撃者も管理者もそのことを知っている。

MongoDB ワイヤプロトコル(平文)

TLSが有効化されていない場合、MongoDBの通信はネットワーク上で完全に可視化されます。

MongoDBワイヤプロトコルの主な特徴：

標準メッセージヘッダーを持つバイナリプロトコル

ヘッダーフィールドには以下が含まれます：

メッセージの長さ

リクエストID

IDへのレスポンス

OpCode (例：OP_MSG、OP_QUERY、レガシー ops)

初期のパケットにはしばしば以下が含まれる：

クライアントハンドシェイク (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,   resp_hostname.name,   
COUNT(*) AS connection_count 
FROM network.isession._all 
WHERE id.resp_p = 27017  
  AND local_orig = FALSE   
  AND local_resp = TRUE   
  AND timestamp BETWEEN date_add('day',-14, now()) AND now()
GROUP BY id.resp_h, resp_hostname.name
ORDER BY connection_count DESC
LIMIT 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 サーバーを特定するには、追加の分析とコンテキストが必要です。このようなケースでは、単純なポートベースのフィルタリングは不十分で、ネットワークメタデータから導出されるより高次の指標に依存する必要があります。

有効なアプローチの 1 つは、応答側のホスト名や TLS Server Name Indication（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 timestamp BETWEEN date_add('day',-14, now()) AND now()
ORDER BY timestamp DESC 
LIMIT 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 timestamp BETWEEN date_add('day',-14, now()) AND now()
ORDER BY timestamp DESC
LIMIT 1000

‍

注：MongoDB にはデフォルトの TLS 証明書や秘密鍵は同梱されていません。TLS を有効化する場合、管理者が自分で証明書と鍵を明示的に用意する必要があります。また、TLS が有効な場合、MongoDB はデフォルトで TLS 1.3 を使用します。これは従来の証明書および x.509 メタデータがネットワークテレメトリに露出しないことを意味します。

内部のMongoDBインスタンスの検知

内部のMongoDBは、外部への露出よりも危険な場合が多いです。

なぜ？

攻撃者はインターネットをスキャンする必要はない

侵害されたホストは自由に列挙できる

内部データベースはしばしば強化が不十分である

ハンティングのパターンには次が含まれます。

東西方向のTCPサービスが永続サーバーとして機能する

アプリケーション層からの繰り返し接続

既知のMongoDB振る舞い (セッション長、リクエスト間隔)

多くの異なる内部ホストからアクセス可能なサービス

これはすぐに明らかになります。

どこからでもアクセス可能なデータベース

フラットネットワーク設計の問題点

理想的なラテラルムーブの目標

 SELECT
  id.resp_h,   
  resp_hostname.name,  
  COUNT(*) AS connection_count 
FROM network.isession._all 
WHERE id.resp_p = 27017  
  AND local_orig = TRUE   
  AND local_resp = TRUE   
  AND timestamp BETWEEN date_add('day',-14, now()) AND now()
GROUP BY id.resp_h, resp_hostname.name 
ORDER BY connection_count DESC 
LIMIT 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 timestamp BETWEEN date_add('day',-14, now())
  AND now() ORDER BY timestamp DESC 
LIMIT 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 timestamp BETWEEN date_add('day',-14, now())
  AND now()
ORDER BY timestamp DESC
LIMIT 1000

‍

潜在的なMongoBleed悪用の探索

ペイロードの可視性がなくても、悪用試行は痕跡を残します。

確認事項：

MongoDBサービスへの異常な接続試行

予期せぬホストからの短命で繰り返される接続

これまでMongoDBを使用したことがないシステムからの新しいMongoDBクライアントの動作

接続の急激な増加

非アプリケーションシステム (ワークステーション、ジャンプホスト、侵害されたサーバー) に由来するMongoDBトラフィック

これらは典型的な兆候です：

偵察

脆弱性テスト

自動メモリプロービング

Vectra のエンティティ中心ビューでは、特に ID とホストコンテキストを組み合わせることで、これらが素早く浮かび上がります。

SELECT     
  id.orig_h,     
  id.resp_h,     
  id.resp_p,     
  duration,     
  conn_state,     
  timestamp,     
  orig_ip_bytes,     
  resp_ip_bytes 
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 timestamp BETWEEN date_add('day', -14, now()) 
  AND now() 
ORDER BY timestamp DESC 
LIMIT 100

‍

このクエリは、暗号化されていないMongoDBトラフィックを検索する方法の例です。最初のパケットのサイズは44バイトで、圧縮されたメッセージを定義するMongoDBヘッダーが含まれています。

MongoDBヘッダーのフォーマットは以下のように定義されます：

struct MsgHeader {
  int32 messageLength; // total message size, including this 
  int32 requestiD; // identifier for this message   
  int32 responseTo; I/ requestiD from the original request
        //_(used in responses from the database)
  int32 opCode; //message type
}

公開されたPoCは、44バイトの長さとオペコード2012(圧縮データ)を使用しています。

3.Vectra Match (Suricata) のさらなる活用

メタデータは大きな助けとなります。Vectra Match は正確な検出を可能にします。

Suricata ベースのシグネチャを使用することで、MongoDB のトラフィックとエクスプロイトのパターンを明確に識別できます。Vectra Match ルールセットは Commercial ETPro ルールセットに基づいており、MongoBleed 用の以下の 2 つのルールが含まれています。1 つ目はインバウンド認証試行を検出するためのルール、2 つ目はエクスプロイト自体を検出するためのルールです。これらはどちらも Vectra Match Curated Ruleset に含まれています。

潜在的な悪用使用の検知

MongoBleedに関しては、特に以下の署名が対象となります：

不正なプロトコル長または異常なプロトコル長

認証なしでの繰り返しハンドシェイク試行

メモリ開示の試みと一致するプロトコル異常

MongoDBサービスに対する高頻度プローブ行為

これはCVE固有のペイロードだけに依存するものではなく、攻撃者が回避するのがはるかに困難な動作に焦点を当てています。

alert tcp any any -> $HOME_NET 27017 (msg:"ET INFO MongoDB SASL Authentication Detected"; 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 AI プラットフォームは、これらの疑問に答える可視性を提供します。さらに「メモリリーク」が大規模な侵害に発展する前に、行動を起こすための検知・追跡能力を備えています。

さらに詳しく知りたい方は、次回のAttack Labセッションにご参加ください。MongoBleedの仕組みを分解し、MongoDB内のリスクを迅速に調査・検証する方法をご紹介します：登録ページへのリンク

‍

CVE-2025-14847 MongoBleed in the Wild: ネットワークメタデータによるMongoDBの露出と悪用の特定