Docker Hubの2019年侵害で19万アカウントのリポジトリトークンが露出——修正対応が自動ビルドを壊した

2019年4月25日、Dockerは単一のDocker Hubデータベースへの不正アクセスを発見した。約19万アカウント分——Hubユーザーの5%弱——のデータが露出した可能性がある。ユーザー名、bcryptパスワードハッシュ、そしてDockerの自動ビルド機能を支えていたGitHubおよびBitbucketのアクセストークンである。Dockerは2日後、メール通知とサポート担当ディレクターのKent Lambによるサポート告知を通じてこれを公表した。

トークンの露出はパスワードよりもはるかに重大だった。ZDNetは、Docker Hubユーザーの大半が大企業内の従業員であり、本番環境にデプロイされるコンテナイメージを自動ビルドしていると指摘した。これらのトークンを保持する者は、プライベートなソースリポジトリに到達でき、さらに悪いことに、本番ソフトウェアをビルドするDockerfileを密かに改変できた。Docker自身は、侵入者が何かをダウンロードしたかどうかを断言できず、アクセスが「露出した可能性がある」と述べるにとどまった。

Dockerの対応は唯一安全なものであり、設計上、業務を混乱させるものだった。露出したパスワードをリセットし、影響を受けたすべてのGitHubおよびBitbucketトークンを失効させ、リポジトリのリンクを解除した。ユーザーはリポジトリを再接続し、GitHubおよびBitbucketのセキュリティログを不正利用の兆候について監査する必要があった。Docker自身のフォーラムでは、失効した連携が入れ替わる中で予期しない「Docker Cloud Build」デプロイキーがGitHubリポジトリに現れたとユーザーが報告し、自分のアカウントが本当に19万件の中に含まれていたかどうかを知る方法を尋ねたが、答えは得られなかった。

Dockerは侵入者を公に特定せず、データ持ち出しも確認しなかった。公式イメージは影響を受けておらず、その完全性を保証するための追加のセキュリティ対策を展開したと述べた。残った損害は信頼に対するものだった。コンテナエコシステムが配管設備のように扱うレジストリが、そこでの侵害が攻撃者に顧客のログイン情報だけでなくソースコードの鍵を渡すことを示したのだ。

影響を受けたすべてのパスワードをリセットし、すべての自動ビルドのGitHub/Bitbucketトークンを失効させ、リポジトリのリンクを解除した——各所有者が再接続するまでビルドは壊れたままだった

GitHubおよびBitbucketへの長期間有効なOAuthトークンが単一の運用中のHubデータベースに保管されていたため、一度の侵入で顧客のログイン情報だけでなくコードパイプラインが露出した。

Docker Hubはコンテナエコシステム全体にとって事実上の公開レジストリとなっていたため、その影響範囲は1社のものではなく業界全体のものだった。

Dockerはデータがダウンロードされたかどうかを判断できず、約19万のセキュリティチームが最悪の事態を想定して手動でリポジトリを監査せざるを得なかった。

露出したアカウントは平均的なユーザーではなく法人の自動ビルド運用者だったため、この認証情報の露出は日常的なパスワードリセットではなく、現実のサプライチェーンリスクとなった。

誰もがインフラとして扱うレジストリは、上流の認証情報の保管庫でもある。単一の運用データベースに長期間有効なソース管理トークンがあったことで、短時間の侵入が業界全体の監査に変わった。

Dockerは影響を受けたパスワードをリセットし、自動ビルドトークンを失効させ、リポジトリのリンクを解除し、予期しないアクセスがないかGitHubおよびBitbucketのログを確認するよう顧客に伝えた。公式イメージは影響を受けていないと宣言され、追加の完全性対策が加えられた。データ持ち出しは確認されず、攻撃者も公に特定されなかった。この事件は、CIからソース管理への認証情報を短命かつ狭い範囲に限定すべきだというサプライチェーンセキュリティの助言における定番の引用例となった。