Unit 42 クラウド脅威レポート: Dockerレジストリから漏洩したコード

2 min read

要約

Unit 42クラウド脅威レポート: 2020年春は、クラウド内のどこで設定ミスが発生しているかを判別するためのDevOpsのプラクティスに重点が置かれています。弊社の調査から、多数のDevOpsサービス(SSH、データベース、コードリポジトリ)が、インフラストラクチャの設定ミスのために不注意でインターネットにさらされていることが判明しました。このブログでは、Dockerレジストリから漏洩したコードの詳細な分析を示し、設定ミスにより安全でないこのようなインフラストラクチャがどのように組織のセキュリティ体制の侵害へとつながる可能性があるかを説明します。

設定ミスは、攻撃者が常に探している狙い易い脆弱性です。1つの設定ミスが、クラウドインフラストラクチャ全体を危険にさらす可能性があります。

「シフトレフト」の意味

シフトレフトとは、ソフトウェア開発ライフサイクル(SDLC)の早期に、脆弱なコードを特定し、脆弱性を取り除くためのプラクティスです。考え方は、可能なかぎり早期にSDLCにセキュリティ対策を統合し、実稼働前に脆弱性とバグを除去できるようにするというものです。シフトレフトへの移行は主にアプリケーションの安全性確保に重点が置かれていますが、同じコンセプトをインフラストラクチャにも適用できます。インフラストラクチャの脆弱性は、アプリケーションの脆弱性より深刻ではないとしても、同程度に深刻となる場合があります。Infrastructure as Code (IaC)の成熟により、今では、インフラストラクチャは、作成する前に、脆弱性について綿密に調べることができます。

弊社は、特に、ネットワークアクセス制御の設定ミスのために危険にさらされたDockerレジストリについて調べました。これらのレジストリには、アプリケーションのソースコードと以前に使用された旧バージョンが含まれています。漏洩すると、専有の知的財産が盗まれたり、悪意のあるコードが注入されたり、業務の重要なデータがハイジャックされたりする可能性があります。弊社は、2,956の危険にさらされたアプリケーションと、15,887の一意のアプリケーションバージョンを特定しました。これらの保護されていないレジストリの所有者には、研究機関、小売業者、ニュースメディア組織、およびテクノロジ企業が含まれています。

Dockerレジストリ

警告: Dockerイメージにはアプリケーションのソースコードと業務上の機密データが含まれるため、Dockerレジストリへのアクセスを制限し、データの整合性を確保することが非常に重要です。

Dockerイメージには、単一のコンテナとして導入できる一連のファイルが含まれています。Dockerイメージは、アプリケーションコード、依存ライブラリ、およびオペレーティングシステムファイルを単一のバンドルに組み込んでいます。このバンドルは、OSに依存しない環境で独立して実行できます。Dockerレジストリは、Dockerイメージを保存し整理するためのサーバーです。各Dockerレジストリの内部で、イメージは複数のリポジトリに整理され、各リポジトリは1つのアプリケーションのイメージを保持します(httpd、nginx、WordPressなど)。各リポジトリは、アプリケーションの複数のバージョンを保持することもでき、一意のタグによって各バージョンが識別されています。その結果、Dockerレジストリは、コンテナ化アプリケーション向けのバージョン管理されたストレージに似ています。Dockerレジストリは、レジストリAPIによって明確に定義された3つのプライマリ操作(イメージのプッシュ、イメージのプル、イメージの削除)をサポートしています。

コンテナイメージを保存するために、オンプレミスレジストリサーバーを設定するか、クラウドベースのレジストリサービスを使用することができます。オンプレミスレジストリは、正式なレジストリコンテナを使用して容易に作成できます。システム管理者が、ストレージインフラストラクチャ、DevOpsパイプライン統合、アクセス制御について責任を担います。大半のクラウドサービスプロバイダは管理対象レジストリサービスを提供しています。たとえばDockerHub、Amazon Elastic Container Registry (ECR)、Azure Container Registry (ACR)、Google Container Registry (GCR)などがあります。クラウドベースのレジストリは、通常、GUIユーザーインターフェイス、脆弱性スキャン、ネイティブのDockerレジストリの上に統合されたアクセス制御などの追加機能を提供しています。それらによって、レジストリインフラストラクチャの管理と維持の負荷が軽減されます。

保護されていないDockerレジストリを綿密に調査

Dockerレジストリサーバーの設定は単純ですが、通信をセキュリティ保護し、アクセス制御を適用するには、追加の設定が必要です。システム管理者は、適切なアクセス制御を適用することなく、意図せずにレジストリサービスをインターネットにさらしてしまうことがあります。この調査では、これらの「設定ミスのある」レジストリを検出し、漏洩したデータを探索することに関心を持ちました。弊社はメタデータのみを収集し、ファイルコンテンツへのアクセスは試みなかった点に留意してください。

Dockerレジストリでは、要求が401 Unauthorizedステータスコードで拒否された場合でも、各API応答には“Docker-Distribution-API-Version”ヘッダーが含まれます。このヘッダーシグネチャを使用して、ShodanとCensysで、インターネット上のDockerレジストリを検索できます。Dockerレジストリは、デフォルトでは、ポート5000 (http)または5001(https)で稼働しますが、それらはあらゆるポートを危険にさらす可能性があります。ポート番号ではなく、ヘッダーシグネチャを使用してShodanとCensysをクエリするメリットは、それらが全300以上のポートを対象として一致を返す点です。図1は、保護されていないレジストリを特定し、探索した方法を示しています。

Finding exposed docker registries 図1. 危険にさらされたDockerレジストリを検出するプロセス

ステップ1では、ShodanとCensysの検索APIを使用して、応答内に“Docker-Distribution-API-Version”ヘッダーが含まれるすべてのサーバーを検出します。
ステップ2では、“check version”要求を送信して応答を確認することで、実際のDockerレジストリサーバーを検出します。有効なレジストリサーバーは、“Docker-Distribution-API-Version”ヘッダーでそのバージョン番号を返します。たとえば、docker-distribution-api-version: registry/2.0などです。200ステータスコードはレジストリが認証を必要としないことを示し、401ステータスコードはレジストリがWWW-Authenticateヘッダーでの認証トークンの取得を想定していることを示します。
ステップ3では、“list repository”と“list tag”要求を送信して、プル操作が許可されているかどうかをテストします。200ステータスコードはプル操作が許可されていることを示し、401または403ステータスコードはイメージをプルするために認証が必要であることを示しています。
ステップ4では、ランダムなリポジトリ名を指定して“blob upload”要求を送信することで、プッシュ操作が許可されているかどうかをテストします。この要求は、レジストリにイメージアップロードプロセスを初期化するように求めます。プッシュ操作が許可されている場合、レジストリは“location”ヘッダーに含めたアップロードURLとステータスコード202を返します。その後、このアップロードセッションは、“cancel upload”要求によって終了されます。ステータスコード204は、アップロードセッションが正常にキャンセルされたことを示しています。
ステップ5では、ランダムなリポジトリ名とランダムなイメージダイジェストを指定して“image deletion”要求を送信することで、削除操作が許可されているかどうかをテストします。実際にイメージを削除することなくステータスコードを確認することで、削除オプションが許可されているかどうかを判別できます。削除操作が許可されているが、イメージダイジェストが存在しない場合は、ステータスコード400がエラーメッセージ“DIGEST_IMVALID”とともに返されます。削除操作が許可されていない場合は、ステータスコード405がエラーメッセージ“UNSUPPORTED”とともに返されます。

保護されていないDockerレジストリにおける所見

弊社の調査から、941のDockerレジストリがインターネットにさらされており、117のレジストリが認証なしでアクセス可能であることが特定されました。これらのレジストリ内には、合計2,956のリポジトリと15,887のタグがあります。117の保護されていないレジストリのうち、80レジストリでプル操作が、92レジストリでプッシュ操作が、7レジストリで削除操作が許可されています。イメージコンテンツを調べることなく、リバースDNS検索またはTLS証明書のcnameによって、保護されていないレジストリの約25%の特性を明確化できました。これらのレジストリの所有者は、研究機関から、小売業者、ニュースメディア組織、およびテクノロジ企業に至るまで広範にわたっています。危険にさらされている一部のレジストリでは、50を超えるリポジトリと100を超えるタグが露呈されています。悪意のある攻撃者は、ソースコードと履歴タグのすべてを使って、システムを侵害するためのカスタマイズしたエクスプロイトを設計できます。プッシュ操作が許可されている場合、安全なアプリケーションイメージがバックドア付きのイメージと置き換えられる可能性があります。これらのレジストリは、マルウェアをホストするために使用されることもあります。削除操作が許可されていれば、ハッカーはイメージを暗号化または削除して、身代金を要求するでしょう。通常、各レジストリには複数のクライアントがアクセスするため、侵害されたレジストリからイメージをプルして実行するすべてのクライアントが即座に脆弱化します。

図2-5に、危険にさらされたレジストリでの所見をまとめています。図2は、httpsまたは認証ヘッダーを実装しているレジストリの割合(%)を示しています。弊社が着目したのは、認証ヘッダーを必要としないレジストリです。図3は、保護されていないレジストリで許可されている操作(プル、プッシュ、または削除)のベン図です。図4は、危険にさらされたリポジトリとタグのサンプルスナップショットを示しています。図5は、保護されていないレジストリのリポジトリとタグの数の詳細です。これらのレジストリから漏洩したデータの量を目の当たりにし、言うまでもなく、横方向の移動が引き起こす潜在する被害を考えると衝撃的と言えます。

Exposed Docker Registries 図2. 危険にさらされているレジストリのTLSと認証の採用率 図3. 危険にさらされているレジストリの許可されている操作 Exposed Docker Repositories 図4. 保護されていないリポジトリとタグのサンプル Exposed Docker Registries. 図5. 危険にさらされているレジストリのリポジトリとタグの数

結論

このブログでは、Dockerレジストリの設定ミスが、機密データを漏洩し、全面的な侵害、業務の中断を引き起こす可能性を示しました。この特定の設定ミスに対する修復戦略は単純です。たとえば、インターネットからのレジストリへのアクセスを防ぐためのファイアウォールルールを追加し、すべてのAPI要求に認証ヘッダーを適用するなどです。ただし、インフラストラクチャのアプリケーションの数と複雑さは増加の一途をたどっており、セキュリティは骨の折れる仕事となっています。常時、脆弱性をスキャンし、悪意のある活動を監視するには、自動化されたツールが必要です。より早く問題を特定できるほど、実稼働環境をエクスプロイトされる可能性は低くなります。

Prisma Cloudは、インフラストラクチャのセキュリティからアプリケーションのセキュリティまで、ソフトウェア開発ライフサイクル全体を保護するための包括的なソリューションを提供しています。シフトレフトとDevOpsセキュリティを重視することも、Prisma Cloudクライアントで大半の高度なサイバー攻撃を防御するために役立ちます。

調査の詳細とお客様の組織で実装するためのベストプラクティスについては、Unit 42クラウド脅威レポート: 2020年春をダウンロードしてご覧ください。

Unit 42 クラウド脅威レポート: Dockerレジストリから漏洩したコード