研究者が英国政府のコードから100件超の脆弱性を発見

GitHubのブランチから削除された政府の認証情報が、18カ月にわたって公開状態のまま取得でき、しかも有効なままでした。

この問題は、11月10日付のWIREDの報道で取り上げられた調査結果の一つです。調査を行ったのは、ControlPlaneの研究者Chris Nesbitt-Smith氏で、英国の公共部門のコードを調べました。33の組織にわたる349のコードベースをスキャンし、100件を超える深刻な脆弱性を報告しています。調査対象のおよそ3分の2で、何らかの弱点が見つかりました。

公開された開示内容からは、セキュリティチームが学べる具体的な教訓が見えてきます。漏えいしたシークレットの失効、アプリケーション権限の制限、レコードを変更できる主体の確認です。ただし、今回の結果はあくまで研究者が調べたサンプルに基づくもので、政府全体の脆弱性の発生率を示すものではありません。取り上げられた問題は、すでに対処されています。

削除したファイルに、有効な認証情報が残っていた

ControlPlaneはPlanning Inspectorateに関する開示の中で、エクスポートされたAzure Synapseのノートブックに、Microsoft Entra IDアプリケーションの認証情報一式が含まれていたと説明しています。この連携の目的は、SharePointからHRファイルを1件取得することでした。しかし付与されていた権限は、テナント内のSharePointサイト全体と従業員のOneDriveアカウントにまで及んでいました。

ブランチからファイルを削除しても、認証情報は無効になりませんでした。研究者によると、孤立したコミットがGitHubのraw-contentインフラ経由で引き続きアクセス可能な状態だったということです。

ControlPlaneは、メタデータの確認と、データを変更しないよう設計された書き込み権限チェックでアクセスを検証したと説明しています。同機関は、8月26日に報告を受けてから約20分後にシークレットを失効させました。

Planning InspectorateはWIREDに対し、研究者の活動はすでに自らの監視で検知しており、データ侵害は起きていないことを確認したと述べています。そのため、アクセスできた可能性と、データが盗まれたと確認された事実とは、区別して考える必要があります。

このケースでは、3つの不備が重なっています。シークレットを公開したこと、連携に必要以上のアクセス権を与えたこと、そしてリポジトリを整理した後もそのアクセスが使える状態で残ったことです。AI企業によるGitHub上でのシークレット漏えいに関する調査でも、削除されたフォークや開発者のリポジトリに隠れた認証情報など、同様のリスクが見つかっています。

ほかの開示事例にみるアクセス制御の不備

公開された事例は、リポジトリの認証情報にとどまりません。ControlPlaneのレポートでは、ブラウザに配信されるコード、調達フォーム、アカウント連携にも弱点があったと説明されています。

これらの発見と解決策は、ControlPlaneの個別の開示で文書化されています。

スコットランドのポータルに関する開示は、ビルド時の環境変数がシークレットを守れない理由を示しています。環境変数の値がJavaScriptにコンパイルされてブラウザに送られる場合、その値は閲覧者に見えてしまうからです。管理者の認証情報をこの形で配布すれば、サイトを訪れた誰でも入手できることになります。

この露出は、ダウンロード可能なAndroidアプリにハードコードされたシークレットという、より広範な問題とよく似ています。ユーザーに配布されるものは、攻撃者も調べられるのです。

学校の調達に関する発見は、これとは別の誤りでした。長くランダムなリクエスト識別子が、事実上レコードを変更するための許可証として機能していたのです。ControlPlaneによると、教育省は7月10日にこの問題を修正しました。

教員のアカウント連携に関するレポートには、重要な限定条件があります。テストでは、新しいサインインを研究者自身のアカウントに連携させただけです。別のアカウント乗っ取りの経路や、ほかの申請者のログインを置き換えられることまでは実証していません。この開示は、コードから特定されたリスクと、その後の修正について述べたものです。

セキュリティチームが今すぐ確認すべきこと

認証情報が漏えいした場合、最初の対応は、それを発行したサービス側で行う必要があります。GitHubの修復ガイダンスでも、リポジトリの履歴を書き換えるかどうかを判断する前に、まず失効またはローテーションを行うよう示されています。

セキュリティチームとエンジニアリングチームは、今回の開示を踏まえ、次の4つの領域を確認するとよいでしょう。

• 認証情報の有効性：過去に漏えいしたパスワード、トークン、アプリケーションのシークレットがすべて失効またはローテーションされているかを確認します。リポジトリのアラートを閉じたり、ファイルを削除したりしても、アクセスが終了したことにはなりません。
• アプリケーションの権限：各連携のアクセス範囲を、実際の用途と照らし合わせます。HRファイル1件を読むだけのワークフローが、無関係なサイトや従業員のストレージにまで書き込めるなら、精査が必要です。
• 公開されるビルド成果物：本番環境のJavaScript、エクスポートしたノートブック、ダウンロード可能なパッケージに、シークレットが埋め込まれていないか調べます。ソースコードのチェックに加えて、リリース成果物も対象にしてください。
• レコードの所有権：リクエスト識別子を変更すると、あるセッションから別のセッションのレコードを閲覧・変更できてしまわないかをテストします。ゲスト向けワークフローとアカウント連携の競合も、明示的に確認してください。

まず、有効なまま機密性の高いシステムに到達できる認証情報を優先します。そのうえで、利用可能なIDおよびサービスの監査ログを使い、その利用状況を調査します。過去のログに欠落がある場合はその範囲を記録し、インシデントの評価が実際に確認できた事実を反映するようにしてください。

認証シークレットが露出したGoogle DevSiteの脆弱性は、漏えいしたシークレットが別の弱点と組み合わさり、被害のより大きい攻撃経路を生み出しうることを示しています。したがって対策では、認証情報そのものと、それを信頼していたアプリケーションの挙動の両方を対象にする必要があります。

次回のレビューでは、各チームに次の3点を実証してもらいましょう。漏えいした古い認証情報が使えなくなっていること、連携が無関係なリソースにアクセスできないこと、そしてレコードが権限のないセッションからのリクエストを拒否することです。これらの確認によって、根本的なアクセスが変わったことを裏付けられます。

関連記事：公共サービスを狙った攻撃でも、シークレットの露出と脆弱なアクセス制御が焦点となりました。 あるハッカーが12のAIエージェントを使って台湾の緊急サービスを狙った事例と、防御側がそこから学べることを紹介しています。