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

By

Category: Cloud, Reports, Unit 42

Tags: , , , , , ,

https://unit42.paloaltonetworks.com/wp-content/uploads/2020/02/Docker-r3d3-900x450.png

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

要約

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パイプライン統合、アクセス制御について責任を担います。大半のクラウド サービス プロバイダは管理対象レジストリ サービスを提供しています。たとえばDockerHubAmazon Elastic Container Registry (ECR)Azure Container Registry (ACR)Google Container Registry (GCR)などがあります。クラウドベースのレジストリは、通常、GUIユーザー インターフェイス、脆弱性スキャン、ネイティブのDockerレジストリの上に統合されたアクセス制御などの追加機能を提供しています。それらによって、レジストリ インフラストラクチャの管理と維持の負荷が軽減されます。

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

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

Dockerレジストリでは、要求が401 Unauthorizedステータス コードで拒否された場合でも、各API応答には“Docker-Distribution-API-Version”ヘッダーが含まれます。このヘッダー シグネチャを使用して、ShodanCensysで、インターネット上の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と認証の採用率 Exposed Docker Registries 図3. 危険にさらされているレジストリの許可されている操作 Exposed Docker Repositories 図4. 保護されていないリポジトリとタグのサンプル  Exposed Docker Registries. 図5. 危険にさらされているレジストリのリポジトリとタグの数

結論

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

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

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

その他の資料