MongoDBへのランサム攻撃は解決済みの問題と見なされることが多いが、Flareの新たな調査は、この脅威が決して消えていないことを示している。
進化するどころか、攻撃者は継続して同じ、少ない労力で大きな利益を得る手口を使っている――インターネット上で公開されたMongoDBデータベースをスキャンし、消去したうえで、備えのない組織に少額のビットコイン身代金を要求する手口だ。
「MongoDBランサムウェアのケーススタディーは、いくつかの重要な点を教えてくれると同時に、昨日のセキュリティ上のミスが今日の犯罪ビジネスモデルになることを示す完璧な例だ」と、Flareのサイバーセキュリティー研究者Assaf Morag氏は、eSecurityPlanetへのメールで述べた。
同氏は次のように説明した。「リスク自体は新しいものではなかった。変わったのは、攻撃者がそれをいかに効率よく産業化し、収益化する方法を学んだかという点だ」
Assaf氏はさらに、「『古い』脆弱性や設定ミスなどというものは存在しない。攻撃者は、それを収益化できる、あなたが犯すたった1つのミスを常に探している」と付け加えた。
大規模化するMongoDBランサム攻撃
Flareの研究者は、認証機能が一切なく、インターネットに完全公開されていたMongoDBのインスタンスを3,100件以上特定した。
これらの公開データベースのうち、1,416件（約46%）はすでに消去され、約500ドル相当のビットコインを要求する身代金メモに置き換えられていた。
身代金要求のほぼすべてが、わずか5つのウォレットアドレスを指しており、単一のウォレットが98%以上の事例に登場していた。このことは、場当たり的な模倣犯の集まりではなく、1人の有力な攻撃者が継続的なキャンペーンを運用していたことを強く示している。
MongoDBランサム攻撃の仕組み
この攻撃の仕組みは単純で、2017年から2021年にかけて初めて報告されたMongoDBランサムキャンペーンからほとんど変わっていない。
攻撃者はインターネット上で、通常はポート27017で稼働している、公開状態のMongoDBサービスをスキャンし、認証情報を要求されなければ直接接続する。
侵入すると、データベースを列挙し、コレクションを削除して、データが永久に失われると脅す身代金メモを挿入する。
この一連の操作にマルウェアや権限昇格、ラテラルムーブメントは必要なく、支払いを選んだ被害者が見返りを何も受け取れなかったと報告するケースも多い。その結果、データは不可逆的に失われる。
高度なエクスプロイトではなく、設定ミスがリスクを生む
MongoDBランサムウェアの核心にあるのは、ソフトウェアの脆弱性ではなく設定ミスの悪用だ。
公開状態になったインスタンスの多くは、認証を強制せずにMongoDBをすべてのネットワークインターフェースにバインドする、デフォルトまたはコピーされた設定に起因している。
こうした安全でないパターンは、利便性やテストを目的としたDockerイメージ、オンラインチュートリアル、設定例を通じて広まることが多いが、その後、本番環境で再利用されている。
安全でないイメージと認証情報が公開範囲を拡大する仕組み
Flareは、30の名前空間にまたがり、この安全でないバインド設定を含むコンテナイメージをDocker Hub上で763件特定した。
これらのイメージの多くは利用が限定的だった一方、同じ設定を使用し、15,000回を超えてプルされている、広く採用されたプロジェクトも研究者は発見した。
これらのイメージをパブリックポートのマッピングやホストネットワーキングとともにデプロイすると、データベースは瞬時にインターネットからアクセス可能な標的になり得る。
認証情報の露出はリスクをさらに増幅する。
研究者は、GitHubリポジトリー、コンテナーレジストリー、ペーストサイト、ダークウェブのフォーラムから、漏洩したMongoDBの認証情報を数千件発見した。その多くは有効なままだった。
こうした漏洩認証情報が公開サービスと組み合わさることで、単一のCVEを悪用することなく、攻撃者が恐喝を大規模化できる、手間のかからないエコシステムが形成される。
CVEよりも公開状態が重要な理由
Shodanはインターネット上で発見可能なMongoDBサーバーを200,000台以上特定したが、アクセス制御なしで完全に公開されていたのは、そのごく一部、約3,100台にすぎなかった。
多くのサーバーで既知の脆弱性が明らかになったものの、その大半はサービス拒否状態など、影響の小さい問題だった。
確認された主なリスクは、パッチ未適用のソフトウェアではなく、恒常的な設定ミスによって可能になった認証なしのアクセスだった。
MongoDBランサムのリスクを低減する方法
MongoDBへのランサム攻撃が続くのは、巧妙な脆弱性ではなく、基本的なデプロイとアクセス制御の隙を突いているからだ。
リスクの低減に複雑なツールは必要ないが、規律ある設定、継続的な可視化、そして強固な運用準備が必要になる。
- MongoDBを公開インターネットにさらさないよう、アクセスをプライベートネットワーク、VPN、または踏み台ホストに制限する。
- すべてのデータベースユーザーとサービスに対して、強力な認証、RBAC、最小権限アクセスを適用する。
- パブリックなインバウンド通信からポート27017を遮断し、ネットワーク制御を強化するとともに、厳格なファイアウォールまたはKubernetesネットワークポリシーを適用する。
- 安全でないデフォルト設定を排除して、コンテナーおよびCI/CDのデプロイを安全にし、コピー＆ペーストした設定や、管理ツールを公開状態にすることを避ける。
- 継続的に露出を監視, 、異常な
- データベースアクティビティーや漏洩した認証情報を、アタックサーフェスおよびクラウドセキュリティーツールで確認する。不変のバックアップ
- 、認証情報のローテーション、管理されたエグレスによってデータの完全性を保護し、情報流出と復旧への影響を抑える。定期的にインシデント対応計画をテストし、更新して
、データベースの公開や恐喝事案を迅速に検知、封じ込め、復旧できるようにする。
これらの対策は、組織が被害範囲を限定し、レジリエンスを構築するのに役立つ。基本的なミスがMongoDBランサムウェアを勢いづかせる
MongoDBランサムウェアは、最も根強い脅威の一部が高度なエクスプロイトではなく、見過ごされた基本事項によって成功していることを浮き彫りにしている。
クラウドネイティブ環境が拡大し、インフラが急速に再利用される中、小さな設定上の近道が、気付かないうちに長期的かつ体系的な公開状態へと発展する可能性がある。アクセスを継続的に検証するゼロトラストモデルを採用し、