ドッカー とは、コンテナ技術を用いた仮想化プラットフォームです。仮想化とは、物理的な資源であるハードウェアを効率的に活用するために、ハードウェアのスペースの上に仮想マシンを作る技術であり、仮想化方法によっては仮想マシン（Virtual Machine）とコンテナ（Container）で分けられます。コンテナ（Container）技術はホストOSの機能をそのまま活かしてプロセスを隔離し、独立された環境を設ける技術のことです。実際、コンテナ基盤の仮想化プラットフォームとして業界標準のように使用される ドッカー は、使用される分ほどセキュリティ脆弱性が発生する際、大きな被害を与える可能性があります。今回の投稿では、攻撃対象領域の漏えいで発生しかねない ドッカーコンテナ の深刻なセキュリティ問題とOSINT検索エンジンを利用して ドッカーコンテナ の攻撃対象領域を検知する方法について話します。
ドッカーコンテナ のセキュリティ問題、要は Private Docker Registry
ドッカー コンテナ は、ドッカー クライエント、ドッカー ホスト、レジストリ（Registry）で構成されます。この中で、特にセキュリティ問題になりうるのは「 ドッカー レジストリ（Docker Registry）」であります。ドッカーのレジストリにはドッカーで管理されるあらゆる重要情報が含まれ、外部へ公開の可否によって「Public Registry」、「Private Registry」に分けられます。「Public Registry」は、ドッカー の公式レジストリである ドッカー ハブ（Docker Hub）やその他のベンダーのレジストリと同様に外部へ公開されているレジストリです。逆に、「Private Registry」はユーザーがプライベートで構築して内部網で使い、制限されたユーザー（会社または、チーム員）のみアクセスできるようにするのが一般的です。外部のアクセスが不可能であるため、敏感な情報などが含まれている場合が多く、「Private Registry」に設定ミスなどの問題が起こる場合、まっすぐセキュリティ問題につながれます。そのうえ、たまに便利に利用する目的でドッカーレジストリを外部インターネットにつないておいたり、クラウドに設置したまま忘れてしまう場合もあります。このようなセキュリティ問題で外部の非認可の人のアクセスを許し、開発ソースの漏えいなどのセキュリティインシデントが起こりやすいです。
Search Query : Title: Docker Registry
Search Query : Title: Docker Registry UI
Search Query : Title: Docker Registry Browser
Criminal IPで「Title: Docker Registry」を検索した結果、
総1,580個の漏えいされたPrivate Registryか検索される
むろん、このように外部へ漏えいされたDocker Registryとしてもアクセスしたとき、以下のイメージのようにログイン認証コード（401コード）が出力されば、最小限のログイン認証装置は設けられるレジストリです。このようなレジストリはパスワードが漏えいされたない限り完全に危険な状態としては見られません。（当然、究極的にはこのようなログインページすら見えないように外部網のアクセスを完全ブロックするべきです。）
外部へ漏えいされたドッカ― レジストリ
外部へ漏えいされたドッカ― レジストリ
[Criminal IP Search 101 – ハッキングにさらされるドッカーコンテナレジストリ]
外部へ漏えいされたドッカ― レジストリ
検知されたRegistryの中ではログイン認証を通さずアクセスできるものもあります。アクセスしてみると、以下のようなRepositories画面が現れ、レジストリ内部の重要なファイルが完全に漏洩されています。
ハッカー、一般人、誰でも認証なしで簡単にソースコードが含まれたイメージファイルをダウンロードできます。
ログインの認証装置なしで重要ファイルが全部外部に漏えいされたドッカ―レジストリ
ドッカー APIサーバーによる攻撃対象領域の漏えい
先述したRegistryはウェブページがあるため、OSINT検索エンジンでページのTitle名を検索してみましたが、ウェブページが存在しなくてもAPIサーバーを通じてドッカーコンテナ内の情報が漏れる可能性があります。「Docker Registry HTTP API」はドッカーのイメージ配布を便利に管理するためのREST APIで、ドッカー レジストリのような役目を果たします。なので、外部にログイン認証システムがないDocker Registry HTTP APIサーバーが漏えいされていると、ドッカー レジストリに認証もないままアクセスできる状態と一緒です。
Criminal IPのIT資産検索 で漏洩された ドッカー のAPIサーバーを検知するためには、 ドッカー レジストリのAPIサーバーのヘッダである「Docker-Distribution-Api-Version」を検索します。
Search Query : Docker_Distribution_Api_Version
Criminal IPに「Docker_Distribution_Api_Version」のキーワードを検索した結果、
1,260個の漏洩されたドッカーのAPIサーバーが確認される
ドッカー レジストリのAPIサーバーにアクセスしてみると、下の画面で見えるようにヘッダ以外はどんなBody情報もありません。この状態では特にセキュリティ問題はなさそうです。
しかし、追加作業でAPIサーバーから ドッカー レジストリに関する具体的な情報を得られます。
漏えいされた ドッカー レジストリのAPIサーバー、ヘッダ情報しか確認されない
以下のイメージのように、APIサーバーへアクセスした後、「/v2/_catalog」のコマンドを追加すると、Repositoriesの全体リストが出る衝撃的な結果が現れます。
ドッカー コンポーズ（Docker Compose）の設定ファイルのセキュリティ問題
ドッカー コンポーズ（Docker Compose）はいくつかのコンテナを有機的に結び使える機能です。この機能を使用すると、あらゆるシステムを連動するとき、まるで1つのアプリケーションのように使えるため、エンジニアは複雑な作業を簡単で有用に行うことができます。
例えば、ウェブアプリケーションをサービスする際、ウェブサーバー（Apache、IIS、Nginx）とDatabase（Oracle、MySQL、PosgressSQL）を同時に設定しなければなりません。
その時、 ドッカー を使うとしても個別的にコンテナを生成しなければなりません。しかし、 ドッカー コンポーズ（Docker-compose）を利用すると、いろんなコンテナを1つのサービスで結び付けられるため、作業がとても簡単になります。
ただし、 ドッカー コンポーズで使われるYAML環境の設定ファイルにセキュリティ問題が発生する可能性があります。YAMLファイルにアクセスできる場合は ドッカー で作られたウェブサーバーやDBサーバーのアカウントを乗っ取ることができ、 ドッカー コンポーズで使用されるサーバーがディレクトリリスティングの脆弱性をそのまま置いた状態ならば、YAMLファイルに簡単に近づき、アカウントを乗っ取ることができます。
Search Query : Docker-compose.yml title: Index of /
Criminal IPに「Docker-compose.yml title: Index of /」のキーワードで検索した結果、
430個のドッカーコンポーズYAMLファイルがあるウェブサイトを見つけられる
430個のドッカーコンポーズYAMLファイルがあるウェブサイトを見つけられる
検索結果は総430個で、その中でアクセスを許すサーバーにアクセスしてみたところ、ディレクトリがインデックスされたウェブサイトに漏えいされているDocker-Compose.ymlの設定ファイルを見つけました。
ディレクトリがインデックスされたウェブサイトに漏えいされている
Docker-Compose.ymlの設定ファイル
Docker-Compose.ymlの設定ファイル
ディレクトリがインデックスされたウェブサイトに漏えいされている
Docker-Compose.ymlの設定ファイル
Docker-Compose.ymlの設定ファイル
漏えいされたDocker-Compose.ymlの設定ファイルを詳しく調べてみると、認証に関係している環境の変数（environment）にUsernameとPasswordが記載されています。
漏えいされたDocker-Compose.ymlの設定ファイルに記載されたUsernameとPassword
ドッカー スウォーム（Docker Swarm）のセキュリティ問題
ドッカー スウォーム（Docker Swarm）はいくつかの ドッカー ホストを1つのクラスター化するコンテナオーケストレーション管理ツールで、 ドッカー コンポーズと同様に作業の利便性のために使われます。
Search Query : Title: Docker Swarm
Criminal IPにTitleフィルターを利用してDocker Swarmを検索した結果、
24個の漏えいされたDocker Swarmが検索される
検索されたドッカー スウォーム（Docker Swarm）総24個で、実際にマネージャーノードにアクセスした画面は以下のようです。
このマネージャーノードが外部からアクセスできるようになると、想像したくないぐらいたくさんのセキュリティ問題が起こりかねません。
漏えいされたDocker Swarmのマネージャーノード
結論
効率的な開発環境づくりと配布のために使われる ドッカー はもはや必須不可欠なプラットフォームとして位置づけられました。いつも通り、ハッカーらはよく使われる、使うしかないサービスを攻撃のターゲットにするため、 ドッカー もやはり小さな欠点からも深刻な被害をもたらすかもしれません。しかし、ドッカーコンテナを使うことでこのようなセキュリティ欠点が発生するのではなく、むしろ公式的に公表された脆弱性は素早いセキュリティパッチと点検ガイドで対応できます。
しかし、先に話した ドッカーコンテナ のセキュリティ問題は残念ながらプラットフォーム自体の問題ではなく、ユーザーの設定ミス、攻撃対象領域管理のミスで発生します。そして、ドッカーだけではなく個人または、企業で使われる全てのアプリケーションのセキュリティ問題は攻撃対象領域の漏えいによって起こります。クラウド時代にこれからもっと多い製品とサービスが使われるとともに、ハッカーのターゲットとなる攻撃対象領域も増えることを多数のセキュリティ専門家は見込んでいます。 この問題を解決するには、ひたすら漏えいされた資産を迅速に検知し、認知し、対応することしかありません。攻撃対象領域を減らすためには Criminal IP のようなOSINT検索エンジンまたは、Criminal IP ASM のような攻撃対象領域管理自動化システムを通じて定期的な資産管理をすることをお勧めします。
関連して APIキーの攻撃対象領域漏えいによる情報漏れと操作可能のDjangoウェブアプリケーション に関する投稿をご参照ください。
0コメント