Dockerコンテナのセキュリティ問題

# １．はじめに
[**ドッカー**](https://www.docker.com/) とは、コンテナ技術を用いた仮想化プラットフォームです。仮想化とは、物理的な資源であるハードウェアを効率的に活用するために、ハードウェアのスペースの上に仮想マシンを作る技術であり、仮想化方法によっては仮想マシン（Virtual Machine）とコンテナ（Container）で分けられます。コンテナ（Container）技術はホストOSの機能をそのまま活かしてプロセスを隔離し、独立された環境を設ける技術のことです。

実際、コンテナ基盤の仮想化プラットフォームとして業界標準のように使用されるドッカーは、使用される分ほどセキュリティ脆弱性が発生する際、大きな被害を与える可能性があります。今回の投稿では、**攻撃対象領域の漏えいで発生しかねないドッカーコンテナの深刻なセキュリティ問題**とOSINT検索エンジンを利用して**ドッカーコンテナの攻撃対象領域を検知する方法**について書いてみたいと思います。

# ２．Private Docker Registryのセキュリティ問題
ドッカーコンテナは、ドッカークライエント（Docker Client）、ドッカーホスト（Docker Host）、レジストリ（Registry）で構成されます。この中で、特にセキュリティ問題になりうるのは[「**ドッカーレジストリ（Docker Registry）」**](https://docs.docker.com/registry/)であります。ドッカーのレジストリにはドッカーで管理されるあらゆる重要情報が含まれ、外部へ公開の可否によって**Public Registry、Private Registry** に分けられます。

「Public Registry」は、ドッカーの公式レジストリであるドッカーハブ（Docker Hub）やその他のベンダーのレジストリと同様に外部へ公開されているレジストリです。逆に、「Private Registry」はユーザーがプライベートで構築して内部網で使い、制限されたユーザー（会社または、チーム員）のみアクセスできるようにするのが一般的です。

外部のアクセスが不可能であるため、敏感な情報などが含まれている場合が多く、「Private Registry」に設定ミスなどの問題が起こる場合、まっすぐセキュリティ問題につながれます。そのうえ、たまに便利に利用する目的でドッカーレジストリを外部インターネットにつないておいたり、クラウドに設置したまま忘れてしまう場合もあります。このようなセキュリティ問題で外部の非認可の人のアクセスを許し、開発ソースの漏えいなどのセキュリティインシデントが起こりやすいです。

OSINT検索エンジンの [**Criminal IP**](https://www.criminalip.io/ja)のIT資産検索 (https://www.criminalip.io/ja/asset) でTitleフィルターに次のクエリを入力すると、攻撃対象領域に漏えいされているPrivate Registryを検知できます。
>**_Search Query: [Title: Docker Registry](https://www.criminalip.io/ja/asset/search?query=Title%3A+Docker+Registry)_**
>**_Search Query: [Title: Docker Registry UI](https://www.criminalip.io/ja/asset/search?query=Title%3A+Docker+Registry+UI)_**
>**_Search Query: [Title: Docker Registry Browser](https://www.criminalip.io/ja/asset/search?query=Title%3A+Docker+Registry+Browser)_**

![docker1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003594/dfc396ba-9fec-cd84-9bc5-e0643ca49961.png)　
むろん、このように外部へ漏えいされたDocker Registryだとしてもアクセスしたとき、以下のイメージのようにログイン認証コード（401コード）が出力されれば、最小限のログイン認証装置は設けられるレジストリです。このようなレジストリはパスワードが漏えいされていない限り完全に危険な状態としては見られません。（当然、究極的にはこのようなログインページすら見えないように外部網のアクセスを完全ブロックするべきです。）

![docker5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003594/297fbe0d-f0bf-4e66-9e1f-f5ad16b1dca1.png)
検知されたRegistryの中ではログイン認証を通さずアクセスできるものもあります。アクセスしてみると、以下のようなRepositories画面が現れ、レジストリ内部の重要なファイルが完全に漏洩されています。

ハッカー、一般人、誰でも認証なしで簡単にソースコードが含まれたイメージファイルをダウンロードできます。
![docker6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003594/22344b6c-2c05-dbb4-63d4-a86d43530490.png)

# ３．Docker APIサーバーによる攻撃対象領域の漏えい
先述したRegistryはウェブページがあるため、OSINT検索エンジンでページのTitle名を検索してみましたが、ウェブページが存在しなくてもAPIサーバーを通じてドッカーコンテナ内の情報が漏れる可能性があります。「Docker Registry HTTP API」はドッカーのイメージ配布を便利に管理するためのREST APIで、ドッカー レジストリのような役目を果たします。なので、外部にログイン認証システムがないDocker Registry HTTP APIサーバーが漏えいされていると、ドッカー レジストリに認証もないままアクセスできる状態と一緒です。 

[**Criminal IP**](https://www.criminalip.io/ja)のIT資産検索で漏えいされたドッカ―のAPIサーバーを検知するために、ドッカ―レジストリのAPIサーバーのヘッダである「Docker-Distribution-Api-Version」を検索してみましょう。その結果、1,260個の漏洩されたドッカ―のAPIサーバーが確認されます。
>**_Search Query: [Docker_Distribution_Api_Version](https://www.criminalip.io/ja/asset/search?query=Docker_Distribution_Api_Version)_**

![docker2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003594/8a8e195c-6fec-85b0-3e63-28b473fb4114.png)
ドッカ―レジストリのAPIサーバーにアクセスしてみると、下の画面で見えるように、ヘッダにはどんなBody情報もありません。この状態では特にセキュリティ問題はなさそうです。
![docker7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003594/0431b123-66ec-9dc0-0b5a-8b48e237698b.png)
しかし、追加作業でAPIサーバーからドッカ―レジストリに関する詳しい情報を得られます。以下のイメージのように、APIサーバーへアクセスした後、「/v2/_cataglog」のコマンドを追加すると、Repositoriesの全体リストが出るという衝撃的な結果が現れます。
![docker8,9.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003594/41429bc8-ea30-bdc3-e78b-3aee3b1c3fd3.png)

# ４．Docker Composeの設定ファイルのセキュリティ問題
[**ドッカー コンポーズ（Docker Compose）**](https://docs.docker.com/compose/)はいくつかのコンテナを有機的に結び使える機能です。この機能を使用すると、あらゆるシステムを連動するとき、まるで1つのアプリケーションのように使えるため、エンジニアは複雑な作業を簡単で有用に行うことができます。例えば、ウェブアプリケーションをサービスする際、ウェブサーバー（Apache、IIS、Nginx）とDatabase（Oracle、MySQL、PosgressSQL）を同時に設定しなければなりません。

その時、 ドッカーを使うとしても個別的にコンテナを生成しなければなりません。しかし、ドッカーコンポーズ（Docker-compose）を利用すると、いろんなコンテナを1つのサービスで結び付けられるため、作業がとても簡単になります。

ただし、ドッカーコンポーズで使われるYAML環境の設定ファイルにセキュリティ問題が発生する可能性があります。YAMLファイルにアクセスできる場合はドッカーで作られたウェブサーバーやDBサーバーのアカウントを乗っ取ることができ、ドッカーコンポーズで使用されるサーバーがディレクトリリスティングの脆弱性をそのまま置いた状態ならば、YMLファイルに簡単に近づき、アカウントを乗っ取ることができます。

[**Criminal IP**](https://www.criminalip.io/ja)のIT資産検索で次のフィルターの組み合わせでドッカ―コンポーズのYMLファイルがあるウェブサイトを検知できます。
> **_Search Query: [Docker-compose.yml title:Index of/](https://www.criminalip.io/ja/asset/search?query=Docker-compose.yml+title%3A+Index+of+%2F)_**

![docker3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003594/09232580-55ee-0d45-8fba-6e63bc50e78d.png)
検索結果は総430個で、その中でアクセスを許すサーバーにアクセスしてみたところ、ディレクトリがインデックスされたウェブサイトに漏えいされているDocker-Compose.ymlの設定ファイルを見つけました。
![docker12.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003594/125a9710-d6f1-f327-378d-5856287b391c.png)
![docker10,11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003594/49bdc465-7cf0-b455-4e36-40426d932780.png)
漏えいされたDocker-Compose.ymlの設定ファイルを詳しく調べてみると、**認証に関係している環境の変数（environment）にUsernameとPasswordが記載されています。**

# ５．Docker Swarmのセキュリティ問題
ドッカースウォーム（Docker Swarm）はいくつかのドッカーホストを1つのクラスター化するコンテナオーケストレーション管理ツールで、 ドッカーコンポーズと同様に作業の利便性のために使われます。

[**Criminal IP**](https://www.criminalip.io/ja)のIT資産検索で「Title: Docker Swarm」フィルターをかけて検索すると、漏えいされたドッカ―スウォムを見つけられます。
> **_Search Query: [Title: Docker Swarm](https://www.criminalip.io/ja/asset/search?query=Title%3A+Docker+Swarm)_**

![docker4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003594/00f5aa3a-f486-24a5-dcf3-a1bad4a66225.png)
検索されたドッカースウォーム（Docker Swarm）は総24個で、実際にマネージャーノードにアクセスした画面は以下のようです。このマネージャーノードが外部からアクセスできるようになると、想像したくないくらいたくさんのセキュリティ問題が起こりかねません。
![docker13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3003594/15ecbecb-3f80-2d10-e304-061ff296612a.png)

# ６．おわりに
効率的な開発環境づくりと配布のために使われる ドッカーはもはや必須不可欠なプラットフォームとして位置づけられました。いつも通り、ハッカーらはよく使われる、使うしかないサービスを攻撃のターゲットにするため、ドッカーもやはり小さな欠点からも深刻な被害をもたらすかもしれません。しかし、ドッカーコンテナを使うことでこのようなセキュリティ欠点が発生するのではなく、むしろ公式的に公表された脆弱性は素早いセキュリティパッチと点検ガイドで対応できます。

しかし、先に話したドッカーコンテナのセキュリティ問題は残念ながらプラットフォーム自体の問題ではなく、ユーザーの設定ミス、攻撃対象領域管理のミスで発生します。そして、ドッカーだけではなく個人または、企業で使われる全てのアプリケーションのセキュリティ問題は攻撃対象領域の漏えいによって起こります。クラウド時代にこれからもっと多い製品とサービスが使われるとともに、ハッカーのターゲットとなる攻撃対象領域も増えることを多数のセキュリティ専門家は見込んでいます。この問題を解決するには、ひたすら漏えいされた資産を迅速に検知し、認知し、対応することしかありません。

攻撃対象領域を減らすためには、[**Criminal IP**](https://www.criminalip.io/ja)のようなOSINT検索エンジンまたは、[**Criminal IP ASM**（Attack Surface Management）](https://www.criminalip.io/ja/asm/attack-surface-management)のような攻撃対象領域管理自動化システムを通じて定期的な資産管理をすることをお勧めします。