【ITニュース解説】A Bot Found Admin Access to a $13B Startup's GitHub in 25 Minutes. Here's Exactly How.

システムエンジニアを目指す者にとって、現代のITセキュリティは不可避の課題である。今回取り上げるニュースは、あるスタートアップ企業で実際に発生したセキュリティインシデントを通じて、私たちがソフトウェア開発やシステム運用において、いかに基本的な設定ミスが大きなリスクとなり得るかを明確に示している。

事件の舞台は、機械学習インフラを提供するBasetenという企業だった。同社のシステムは、自律型ペネトレーションテストエージェント「Strix」によって検査された。このStrixは、人の介入なしに自動でシステムに潜在する脆弱性を探し出すプログラムである。Strixはわずか25分という驚異的な速さで、Basetenが利用するGitHubの管理者権限を持つ個人アクセストークン（PAT）を発見した。これは、高度な攻撃手法ではなく、過去のDockerイメージ設定ミスに起因するものであった。

Strixが管理者権限に至るまでの25分間のプロセスは以下の通りである。まず、Strixは公開されている情報源、特に証明書の透明性ログから、Basetenが運用するHarborコンテナレジストリのアドレスgcp-us-east4-zlw.registry.baseten.coを発見した。コンテナレジストリは、Dockerイメージと呼ばれる、アプリケーションとその実行に必要な全てをパッケージ化したものを保存する場所である。

次に、StrixはこのHarborコンテナレジストリへのアクセスを試みた。重大な設定ミスとして、このレジストリは認証を必要とせず、誰でも公開プロジェクトの一覧を閲覧し、匿名でアクセスするためのトークンを取得できる状態だった。

Strixは、公開されていたbaseten/baseten-appというDockerイメージをレジストリから取得し、その内部構造を詳細に分析し始めた。Dockerイメージは複数のレイヤーで構成されており、各レイヤーはイメージのビルド過程における特定の操作の記録である。Strixはこれらのレイヤーを順に検査した。

この過程で「TruffleHog」というツールを使い、認証情報（クレデンシャル）の探索を行った。特に重要だったのは、Dockerイメージの「ビルド履歴」に含まれるcreated_byというメタデータを検査した点である。Dockerは、イメージがビルドされる際にDockerfile内で実行されたRUN命令のコマンド文字列を、たとえそのコマンドが一時的なファイルを作成・削除したとしても、履歴としてイメージ内に永続的に記録してしまう特性がある。

このビルド履歴から、Strixは2023年3月3日のビルド時に実行されたRUNコマンド内に、GITHUB_TOKENというGitHub個人アクセストークンの値が平文で含まれているのを発見した。このトークンは発見時で約3年半が経過していたが、依然として有効な状態であった。

発見されたトークンの有効性を「検証」するため、StrixはGitHub APIに対して簡単な呼び出しを行った。その結果、このトークンがbasetenbotというボットアカウントに属し、GitHubリポジトリ全体へのフルアクセス権限、管理者権限を含むプッシュ権限、そして顧客固有のプライベートリポジトリへの読み書き権限を持つことが確認された。しかも、このトークンには有効期限が設定されていなかった。これら一連の発見と検証が、全て自動で、わずか25分で完了したのだ。

このインシデントの「実際のバグ」は、Dockerファイルにおける秘密情報の扱いにあった。問題となった記述パターンは、以下のような形である。

ARG GITHUB_TOKEN
RUN git clone https://${GITHUB_TOKEN}@github.com/basetenlabs/baseten-app.git

このARG命令でGITHUB_TOKENを定義し、その値をRUN命令の中で直接使用するパターンが危険である。ARGでビルド時に渡された値は、その値を使用して実行されたRUNコマンドの履歴としてDockerイメージのレイヤーに平文で記録されてしまう。たとえそのRUNコマンドが一時的なファイルを作成・削除したとしても、一度履歴に残った情報はイメージ内に残り続ける。この問題はDocker 18.09以降で対策が提供されており、正しい記述方法は--mount=type=secretを使用することである。

RUN --mount=type=secret,id=github_token \
    GITHUB_TOKEN=$(cat /run/secrets/github_token) \
    git clone https://${GITHUB_TOKEN}@github.com/basetenlabs/baseten-app.git

--mount=type=secretオプションを使うことで、秘密情報は特定のRUNステップ内でのみ一時的に利用可能となり、イメージのレイヤーには一切記録されず、ステップ終了後には消滅する。これにより、秘密情報を安全に扱うことが可能になる。

しかし、この問題はDockerの不適切な使い方だけでなく、より広範なセキュリティ管理の失敗を示唆している。Docker経由での漏洩は発見のきっかけに過ぎず、真の根本原因は、「有効期限のないGitHub個人アクセストークン」が「ボットアカウント」に付与され、「3年半もの間一度も更新されなかった」という運用上の問題にあった。仮にコンテナレジストリが完全に保護されていたとしても、このトークン自体が常にシステム全体のセキュリティリスクとして存在し続けていた。たとえば、CI/CDログの誤った公開、開発者の端末の侵害、過剰な権限を持つ連携サービスなど、他の経路からでも同じように情報が漏洩する可能性があった。

GitHubは2022年から、より細かい権限設定と有効期限を設定できる「ファイングレイン・トークン」を提供している。それにもかかわらず、旧来の汎用性の高い「クラシックPAT」をボットアカウントに対して有効期限なしで発行し続けていることは、極めて危険な運用であり、いつ同様のインシデントが発生してもおかしくない状況を生み出す。

Basetenはこのインシデントに対して、迅速かつ模範的な対応を示した。脆弱性の報告を受けてから、翌朝にはHarborプロジェクトを非公開にし、同日中には該当トークンを更新するという、非常に速やかな対策を講じた。これは、多くの組織が同様の重大な脆弱性に対処するよりも早い対応である。

この事件が現代のITセキュリティにもたらす最も重要な教訓は、「脅威の発見速度が劇的に向上した」という点にある。かつて熟練したセキュリティ専門家が手動で数日かけて行っていた偵察・分析・発見のプロセスが、今や自律型エージェントによってわずか25分で、しかも自動的に実行可能になった。このようなエージェントは、同時に多数のターゲットに対して水平的に検査を行うことができ、脆弱性の発見コストを劇的に低下させた。

これは、古いビルド設定ミスによる漏洩のような脆弱性を発見できる「攻撃者」の範囲が、特定の専門家から「既製のツールを実行できる誰も」へと劇的に拡大したことを意味する。したがって、企業や開発者は自身の脅威モデルを更新し、Dockerファイルにおける秘密情報の管理、ボットアカウントに付与された個人アクセストークンの権限範囲と有効期限、コンテナレジストリの認証設定などを、改めて厳格に見直す必要がある。これらは特別な対策ではなく、基本的なセキュリティ対策であるが、今も多くの本番環境で、誰も確認していない古いDockerレイヤーの中に潜在的なリスクとして存在している可能性が高い。