不備のあるコンテナサービス構成とその公開によるリスクとは

This post is also available in: English (英語)

概要

コンテナ構成がデフォルトのままになっているコンテナ ホスティング デバイスは、個別に4万台以上存在し、これらのインスタンスは簡単に特定できる状況にあります。コンテナ プラットフォーム KubernetesとDocker については、それぞれやはり個別に2万以上のインスタンスが存在しています。ただしこれら4万以上の各プラットフォームが、必ずしもエクスプロイトや機密データの漏洩に対し脆弱ということではありません。この状況が浮き彫りにしているのは「どうも基本的構成手順に不備が見られるようだ」ということ、そして「それが原因で、企業が将来的に侵害インシデントの標的となり得るだろう」ということだけです。クラウド サービス内で、一見単純な構成不備があると、組織に対して重大な影響が及ぶ場合もあります。例えば、Docker Hubが19万アカウント分のキーとトークンを失った事件は、クラウド環境内のキーおよびトークン ストレージの脆弱なセキュリティ構成を攻撃者が利用したことが原因でした。またLaddersから1,300万件以上のユーザー記録が漏洩した事件は、基本的なコンテナの構成不備のために重大な結果がもたらされた典型的事例です。コンテナ サービスを展開しているすべての企業は、セキュリティ構成の最前線にて、Laddersの事件から得られた教訓を生かすべきでしょう。

弊社のリサーチでは、単純な検索条件によって、世界中で20,353個のKubernetesコンテナが使われていることがすぐに判明しました。これらのインスタンスの場所は米国、アイルランド、ドイツ、シンガポール、オーストラリアで、大多数はAmazon上でホストされていました。また単純な検索条件によって、世界中で23,354個のDockerコンテナが使われていることもあっさり明らかになりました。これらのインスタンスの場所は中国、米国、ドイツ、香港、フランスでした。Dockerの場合も、トップのホスティング元はAmazonでしたが、これらのインスタンスでは、より幅広いホスティング元の分布を確認できました。

次に、これらの公開されたインスタンスのいくつかについても調査を行うことで、どのサービスが公開され、どの情報が漏洩されたのかを確認しました。データベース インスタンスを公開しているサイトや、個人情報を容易に公開してしまうサイトも見つけることができました。

以下のリサーチでは、Unit 42の調査結果を、コンテナの構成不備、公開されたサービスを特定する方法、コンテナ サービスのセキュリティを確保するための対策の観点から説明し、コンテナ サービスで一般的に見られる構成不備について解説していきます。

これにより読者の皆様が、概説されたデータ収集方法を回避しつつ、今まで以上に安全かつプライベートな形でコンテナ プラットフォーム構造を展開できるようサポートします。

クラウド サービス

「クラウド サービス」には、インターネット接続経由で利用可能なあらゆるサービスが含まれます。企業はクラウド サービスを利用すれば、たとえば需要が変動しそうなサービスを提供するために、とくに可用性を確保すべきプロジェクトなどを迅速に展開し、維持し、サポートすることが可能になります。クラウド サービスの一般例としては、APIゲートウェイ、Webサービス、データベースなどが挙げられます。マネージド サービス プロバイダまたはセルフサービス型の内部組織が、いくつかのオーケストレーション プラットフォームを提供しています。これによってコンテナ用の構成機能とプラットフォームのためのポリシー適用が実現されます。この機能は、セキュリティまたは監査ロギング、ロールベースのアクセス制御、クラウド インフラストラクチャ用のネットワーク接続などに対応しています。適切なオーケストレーション プラットフォームやサービス プロバイダを選定できれば、クラウド コンテナのセキュリティを確保するために大きく役立ちます。

Shodan

どのクラウド サービスとコンテナ プラットフォームが公衆インターネットで公開されたかを特定するために、Unit 42はまず、Shodanを使ってこれらのサービスの特定しやすさを調べました。ちなみにShodanは、「IoT(モノのインターネット)デバイスを見つけるためのGoogle」と呼ばれています。本リサーチの主目的はIoTデバイスを特定することではありませんが、同様の技術を用いて、公衆インターネットに接続されているクラウド システムやコンテナも特定できます。IoTデバイス同様コンテナもインターネットに接続されているので、構成不備があれば公開されてしまうことがあります。

Shodanは、公開されているインターネット アドレス空間を継続的にスキャンします。そして特定の各アドレスについて、サービスや各ポートからのレスポンスをリクエストし、これらを記録します。これらのレスポンスはデータベースに保存され、その後、Shodanのメンバー(会員)が閲覧できます。Shodanは、高度なシステム分析、サービス分類、タグ付け機能などのサービスを提供します。これらを用いることで、特定された各システムの機能や範囲について、追加的な洞察をもたらします。こうしたデータの一部は、無料で使用できるShodanアカウントから入手できますが、自動化処理による悪用を避けるため、通常は速度制限が課されています。他方、Shodanチームによってまとめられた追加的な分析コンテンツは、有料アカウントの所持者のみに提供されます。有料会員が利用できる特典としては、結果を返すための速度制限の緩和、詳細な検索リクエスト用の高度なフィルタ機能、特定のネット範囲に対する変更アラート通知の増加、あらかじめ定義された基準と比較する自動スキャン、そして特定の分析タグ用のクエリ機能などが挙げられます。

本ブログで特定されたコンテナ サービスがいかに見つけやすいかを体験していただくため、以下の例は、無料Shodanアカウントで実行できるようにしています。

公開されたデフォルト コンテナの探索

ほとんどカスタマイズされていないデフォルトのコンテナ プラットフォームには明確な特徴があり、これらを探せば、Shodan検索内で容易に特定を行えます。「kubernetes」、「docker」、あるいは「k8s」(Kubernetesの略語で、「k」と「s」の間に8つの文字があることを意味する)のようなキーとなる単語を使えば、簡単に検索を実行し、デフォルト コンテナを特定することができます。

以下に、ShodanのWebサイトを使った簡単な検索例とその結果を示します。

Kubernetes

「Kubernetes」でShodan検索を実行すると、結果として、この単語を含むデバイスが合計20,353台ヒットします。追加的なメタデータ情報も返されるため、リサーチャーはこれを掘り下げれば、興味深い結果を得られる可能性があります。例えば、上位の国、サービス、会社、オペレーティング システム、商品などの項目です。返された情報から、単語「Kubernetes」を含むデバイスが最も多く使われているのは米国であること、および、これらのデバイスの大多数をホストしている会社がAmazon.comであることが分かります。図1に、Shodanが取り出した情報の種類と結果を示します。

図1.Shodan Webページの「Kubernetes」のクエリ結果

図2に、Shodan CommandLine Interface (CLI)ツールを使った場合の例を示します。この例では、特定のキーワードの「カウント」機能が使われています。図の通り、キーワード「Kubernetes」を含むデバイスの現時点での数が示されており、デバイスの合計数は図1と同じく20,353台となっています。Shodan CLIで使用可能なコマンドに関するその他の情報については、Shodan CLIページをご覧ください。複雑な検索を実行したいと思っているリサーチャーにとっては、Shodan検索のスクリプト可能な機能は非常に有用であると言うことができます。

図2.Shodan CLIの「Kubernetes」のクエリ結果

k8s

図3は、単語「k8s」を含むデバイスの合計数が509台であることを示します。返された結果によると、ここでも依然としてトップの国が米国であり、k8sのデバイスをホストしているトップの会社がAmazon.comであるのは興味深い点です。

図3. Shodan Webページの「k8s」のクエリ結果

図4のShodan CLIを使った場合も、k8sに関して同じカウント結果が示されています。

図4. Shodan CLIの「k8s」のクエリ結果

Docker

図5は、単語「Docker」を含むデバイスの数が23,354台であることを示します。Kubernetesのデバイスと比べると1,001台多くなっていますが、これはDockerのほうが古く、コンテナ プラットフォームとして定着しているためです。ただし、興味深いのは、上位5つの国の合計数がそれぞれ、Kubernetesやk8sと比べ、互いに近接している点です。中国が6,015台でトップ、米国が4,617台で2位の結果となりました。ここでも依然として上位5社の中でAmazon.comが1位を占めましたが、残りの4社のうち3社は中国の会社で、2位は香港の会社でした。これらの数字から、各国内でDockerコンテナをホストするためにどの会社が選ばれているかについて、洞察を導き出すことができます。

図5. Shodan Webページの「Docker」のクエリ結果

以上の検索により、KubernetesとDockerのコンテナ プラットフォームにはそれぞれ、インターネットに公開されている個別のインスタンスが2万以上あることが明らかになりました。また、Kubernetesプラットフォームは、一般的に使われている略称であるk8sにより、さらに509台、個別のインスタンスが構成されていることも判明しました。ただしこれら4万以上の各プラットフォームは、必ずしもエクスプロイトできる脆弱性を持っていたり、機密データの漏洩リスクを持っていたりするわけではありません。この状況が浮き彫りにしているのは「たとえばコンテナの名前変更のし忘れなどの極めて基本的な構成手順の不備が見られるようだ」という傾向だけです。どれほど無害であっても、業界内で、基本的な構成不備は存在します。基本的なコンテナの使い方において構成不備がある場合、それは野心的な攻撃者をどれほど引きつけるでしょうか。またさらに重要な点として、そのような構成不備があるコンテナ プラットフォームから機密情報が集められる可能性はあるでしょうか。

当社のリサーチから出された答えは「可能性はある」です。コンテナが適切に構成されていないと、結果的に機密情報を失うことにつながる場合があります。こうした構成不備が報じられるケースも増えてきてはいますが、「Docker Hubが19万アカウント分のキーとトークンを失った事件」などのような見出しの取り上げ方では、背後にある根深い問題が隠れてしまいかねません。構成不備の問題をうまく取り上げている例は、最近報じられた、求人サイトのLaddersから1,300万件以上のユーザー記録が漏洩した事件でしょう。これは単純な構成不備が原因で、基本的な認証要件が実装されていなかったために起きたものです。

公開されたデフォルト サービスの探索

構成不備のあるコンテナ サービスの公開状態を特定するためには、まずリサーチ用の基準を構築し、調査対象のランドスケープについて理解する必要があります。Elastic、Kibana、MySQLの各サービスは、デフォルトで9200、5601、3306のポートをそれぞれ使用しています。Shodanは、各サービスのうち公開されているものの合計数について、基本的な洞察を提供することができます。

Elastic

Elasticデータベースは、データベース内に含まれるデータ用のデフォルトのRest APIインターフェイスとして、TCPポート9200を使用します。ブラウザ経由でElasticデータベースへナビゲートするとき、ユーザー向けにはJSONフォーマットのレスポンス(データセットは閲覧可能な状態)が表示されます。図6に、TCPポート9200を一般に公開しているデバイスの総数をカウントするために実行したShodan検索の結果を示します。合計144.8万台のデバイスが特定され、そのうち130万台が米国にありました。全デバイスの半分近くである775,284エントリは、「googleusercontent.com」のドメインを返しました。Google Infrastructure内の既知の課題に対応し、ポート9200とドメインを関連付ける追加的なリサーチを実施したところ、結果として、Google Cloudインフラストラクチャ上でElasticサービスがホストされていることが判明しました。以上のことは、これらの特定されたデバイスのほとんどがElasticサービスをホストしているという事実を示す確実な指標となります。このドメインは、すべてのElasticインスタンスの53%も占めていました。

図6.Shodan CLIによるポート9200の統計(Elastic)

Kibana

Kibanaは、データベース情報を表示するグラフィカル ユーザー インターフェイス(GUI)をユーザーに提供するために使用されるデータベース可視化ツールです。Kibanaは、デフォルトではTCPポート5601上でHTTPS Webブラウザ接続を使用します。図7に、TCPポート5601を一般に公開しているデバイスの総数をカウントするために実行したShodan検索の結果を示します。合計349,403台のデバイスが特定され、そのうち288,159台が米国にありました。前述のElasticの結果と同じように、エントリの大半を占める56,635台が「incapdns.net」のドメインのものでした。このドメインは、組織にWebホスティング サービスを提供するWebサイト ホスティング サービスです。このドメインは、ポート5601の全エントリの16%を占めていました。

図7.Shodan CLIによるポート5601の統計(Kibana UI)

MySQL

MySQLプロトコルは、デフォルトのTCPポート3306上でSQLデータベースと容易に通信できるようにするために使用されます。図8に、TCPポート3306を一般に公開しているデバイスの総数をカウントするために実行したShodan検索の結果を示します。世界中で合計481万6,000台のデバイスが特定され、そのうち213万8,000台が米国にありました。興味深いことに、これらの結果ではGoogle Cloudサービスは7位まで低下し、MySQLプロトコル対応サービスを最も多くホストしているドメインはAmazonになっています。注意すべき点は、圧倒的多数のMySQLプロトコル対応サービスが特定のホスティング ドメインで運用されているということはなく、最も比率が高いAmazonでホストされているインスタンスであっても、特定されたMySQL対応デバイス全体の4%足らずである点です。

図8.Shodan CLIによるポート3306の統計(SQL DB)

要約すると、これらの結果は、一般に公開されているサービスの合計範囲の枠組みを提供します。このブログの執筆時点では、ポート9200をリッスンしているデバイスは1,448,102台、ポート5601をリッスンしているデバイスは349,403台、ポート3306をリッスンしているデバイスは4,816,638台存在していました。注意すべき点は、これらの固有のシステムに格納されているデータがすべて一般に公開されているわけではない点です。大多数のシステムでは、格納されているデータにアクセスするには認証資格情報が必要であることが調査からわかっています。さらに、これらのシステムの一部は、Elastic、Kibana、またはMySQLプロトコル対応サービスをホストしているのではなく、単にこれらのサービスがデフォルトでリッスンするものと同じポートをリッスンする別のサービスをホストしている可能性もあります。そのため、これらの結果は、リサーチャーがコンテナの構成不備を特定する場合にはあまり役に立ちません。

範囲の絞り込み

これでランドスケープが明らかになったので、続いて範囲を絞り込んで、存在する可能性がある構成不備があるコンテナを特定していきましょう。まず、複数の検索を組み合わせることによって最初のベースライン クエリ(前のセクションの図6～8を参照)を強化します。たとえば、「Kubernetes」という語を使用して、デフォルトのコンテナ名でデフォルト ポート「port:9200」(ElasticデータベースのRestAPIポート)を検索してみます。このクエリ形式により、デフォルトのKubernetesコンテナ インスタンスで実行されているデフォルトのElasticサービスを特定できます。

KubernetesコンテナでホストされているElasticサービスに的を絞るため、「port:9200」と「kubernetes」の両方を指定して検索を実行しました。図9からわかるように、Kubernetesのみで検索した場合は固有の結果は20,353件(図1)、port:9200のみで検索した場合は140万件(図6)でしたが、これらの結果が合計13件にまで絞り込まれました。大半のデバイスは中国内でホストされており、米国にあるのは2台のみです。

図9. Shodan CLIによるポート9200 (Elastic)およびKubernetesの統計

続いて、ElasticサービスをホストしているDockerコンテナに的を絞るため、「port:9200」と「docker」をキー タームとして検索を実行してみました。図10は、デフォルトのDockerコンテナでホストされているデフォルトのElasticサービスが合計39台の固有のデバイスに含まれていたことを示しています。

図10.Shodan CLIによるポート9200 (Elastic)およびDockerの統計

140万件のデフォルトのElasticインスタンスではなく、デフォルトのKubernetesプラットフォームで実行されているデフォルトのElasticインスタンスが13件、デフォルトのDockerプラットフォーム上のインスタンスが39件にまで結果を絞り込みました。この量であれば、はるかに簡単に分析や詳細な調査を行うことができます。

Shodanは各システムのIPアドレスを記録しているので、次のShodan CLIコマンドを使用して、特定されたElasticインスタンスのアドレスを収集しました。

shodan search –fields ip_str port:9200

収集したIPアドレスを使用し、機密情報が含まれていないかどうか特定のシステムを調査しました。

例1

次のシステムでは、保護されていないElasticデータベースが実際に一般に公開されていました。このデータベースに機密情報は含まれていませんでしたが、これはElasticデータベースでどのような種類の情報が提供されている可能性があるかを示す良い例です。このElasticシステムに移動し、検索クエリ「<ipaddress>:9200/_search?q=*」を実行したところ、次のJSONデータが返されました。図11を参照してください。

図11.Elasticデータベースへのクエリの結果のJSON

例2

例2では、デフォルトのサービスを使用しているデフォルトのコンテナ内に機密情報が含まれていました。リサーチャーは、先ほど定義した次のURLクエリ形式を使用して、このElasticインスタンスに移動してみました。

<ipaddress>:9200/_search?q=*

調査すると、「users-registered-2018*」というタイトルのデータベースが特定されました。そこで、次のようにこのデータベースを検索クエリに追加しました。

<ipaddress>:9200/users-registered-2018*/_search?q=*

これにより、このデータベースに含まれる合計19個のユーザー電子メール アドレスが特定されました。図12を参照してください。

図12. 特定されたユーザー電子メール アドレス

電子メール アドレスは、クレジット カード番号、社会保障番号、または他の非常に機密性の高い情報などのアイテムと同じレベルの機密ではありません。しかし、悪意のある攻撃者の標的にされることが頻繁にあります。電子メール アドレスを利用して実行される可能性がある悪意のあるアクションの例として、スピアフィッシング攻撃が挙げられます。悪意のある攻撃者は、地理的な場所、オフィス ビルの数やタイプなど、組織に関する情報を収集することができ、中でも従業員の名前は最も重要です。この情報により、攻撃者は被害者にとって馴染みのある情報が含まれる標的型電子メールを作成し(ビジネス メール詐欺(BEC))、悪意のあるリンクをクリックさせてアカウントを侵害することができます。

Unit 42はさらに、このシステムが、格納されているデータの保護に役立ついかなる認証メカニズムも使用せずにElasticデータベースをホストしていただけでなく、保護されてない別のサービスもホストしていたことを突き止めました。それは、Elasticインスタンスと同時に実行されているKibanaのインスタンスです。

次のURL「<ipaddress>:5601」に対してクエリを実行したところ、Kibanaダッシュボードへのアクセスを取得することができ、そこには最初にElasticサービス内で見つかったものとは別のデータベース情報が含まれていました。ほかにも2つのデータベースを見つけました。内部インフラストラクチャのIPアドレスが含まれているデータベースが1つと、カスタムの内部統合システムのログ情報が含まれているデータベースが1つです。最後に、このユーザー登録データベースの寿命は2018年9月～11月の2か月のみであったように見えますが、このブログの執筆時点でサービスはまだ運用中でした。このブログの執筆時点ではデータベースの所有者はまだ特定されていませんが、引き続き、所有者を確認して被害者通知を行おうと努めています。

図13.Kibanaを使用して特定されたユーザー電子メール アドレス

緩和策

Unit 42は、コンテナ プラットフォームの全体的なセキュリティ向上のため、次の手順を提案します。

• コンテナのセキュリティ戦略に的を絞ったクラウド セキュリティ プラットフォームまたはマネージド サービスに投資する。
• ファイアウォール制御またはコンテナ プラットフォームのネットワーク ポリシーを使用して、コンテナでホストされるサービスへのアクセスを内部ネットワークまたは事前に指定した担当者に制限する。次のリンクはコンテナへのアクセスを保護するのに役立ちます。
  • Docker – iptableの設定
  • Kubernetes – ネットワーク ポリシー
• コンテナの基本的な認証要件を設定する。次の2つのリンクでは、DockerまたはKubernetesの基本的な認証プラクティスを設定する方法について有益な指示が提供されています。
  • Docker – トークン
  • Kubernetes – 認証
• 各コンテナ内で格納または管理されているデータの種類を特定し、適切なセキュリティ プラクティスを使用してこれらの種類のデータを安全に保つ。
  • 必要な保護を決定する際には、組織のコンプライアンス ポリシーが役立ちます。
• 各サービスを専用のコンテナに分離する。1つのコンテナで複数のサービスをホストしないようにすると、コンテナ自体のリソース効率が向上し、効果的なセキュリティ ポリシーの実装に役立ちます。

結論

デフォルトの設定は、組織にとって大きなセキュリティ リスクになる可能性があります。Unit 42が実施した調査により、デフォルト設定を検索するのがいかに容易であり、潜在的な攻撃者がShodanなどのオープン ソース ツールをどのように利用できるかが実証されました。デフォルトのコンテナ名を使用する、デフォルトのサービス ポートを一般に公開したままにするといった設定不備があると、組織は標的型の偵察活動に対して脆弱なままになります。適切なネットワーク ポリシーやファイアウォールを使用することにより、内部リソースが公衆インターネットに公開されるのを防止することができます。さらに、クラウド セキュリティ ツールに投資することで、現在のクラウド インフラストラクチャ内にあるリスクについてアラートを受け取ることができます。Laddersのデータ漏洩や、Docker Hubのキーとトークンの損失のような攻撃が発生すると、クラウドで業務を行っている組織が直面するリスクは莫大なものになります。