GitHubのブランチから削除された政府の認証情報が、18か月にわたって公開状態で取得可能なまま残り、しかも利用できる状態だった。
この露出は、11月10日付のWIREDの報道で取り上げられた調査結果の一つだ。ControlPlaneの研究者Chris Nesbitt-Smithは、33組織にまたがる349のコードベースをスキャンし、調査対象のおよそ3分の2で弱点を確認した結果、100件を超える重大な脆弱性を報告した。
セキュリティチームにとって、今回公表された情報は、露出した秘密情報の無効化、アプリケーション権限の制限、レコードを変更できる人物の確認について具体的な教訓となる。調査結果が示すのは政府全体の脆弱性発生率ではなく、研究者が調査したサンプルの状況だ。取り上げられた問題はその後対処されている。
削除したファイルに有効な認証情報が残った
同社のPlanning Inspectorateの開示で、ControlPlaneは、エクスポートされたAzure SynapseのノートブックにMicrosoft Entra IDアプリケーションの完全な認証情報が含まれていたと説明している。この連携はSharePointから人事ファイルを取得するためのものだったが、権限はテナント内のSharePointサイトと従業員のOneDriveアカウント全体に及んでいた。
ブランチからファイルを削除しても、認証情報は無効にならなかった。研究者によると、孤立したコミットがGitHubのrawコンテンツ配信基盤を通じてアクセス可能なまま残っていた。
ControlPlaneは、メタデータと、データを変更せずに失敗するよう設計された書き込み権限の確認を使ってアクセスを検証したと説明している。機関は8月26日に報告を受けてから約20分後に秘密情報を無効化した。
Planning InspectorateはWIREDに対し、監視によって研究者の活動はすでに検知されており、データ侵害が発生していないことも確認したと説明した。したがって、アクセスされる可能性と、盗難が確認された事実は区別する必要がある。
この事例には、秘密情報を公開したこと、連携に必要以上のアクセス権を与えたこと、リポジトリを整理した後もそのアクセスを利用可能なままにしたことという3つの失敗が重なっている。同様のリスクは、GitHubで秘密情報を漏えいさせたAI企業を調査した報告でも確認されており、削除済みフォークや開発者向けリポジトリに隠された認証情報などが含まれていた。
その他の開示事例では、異なるアクセス制御の不備が明らかに
公表された事例は、リポジトリの認証情報にとどまらない。ControlPlaneの報告は、ブラウザーに配信されるコード、調達フォーム、アカウント連携における弱点を説明している。
| サービス | ControlPlaneが発見したこと | 報告された対応 |
| スコットランド政府のオープンデータポータル | 公開JavaScriptに埋め込まれた長期間有効な管理者トークンにより、管理者アカウント情報が露出し、設定変更も可能になるおそれがあった。 | 所有者は、もはや必要ないと判断した後、サービスを恒久的に廃止した。 |
| 教育省の学校向け調達支援サービス「Get Help Buying for Schools」 | 有効なリクエスト識別子を持つ人物は、連絡先メールアドレスを含むリクエストの詳細を変更し、サインインせずにリクエストを送信できた。 | レコードへのアクセスと関連する操作は、アクティブなセッションにひも付けられた。 |
| 教育省の教員申請サービス | アカウント連携コードにより、競合する本人確認を拒否せずに既存のログイン連携を上書きできた。 | 競合する連携を拒否するチェックが追加された。 |
これらの調査結果と対応は、ControlPlaneの個別の開示資料に記録されている。
このスコットランドのポータルに関する開示は、ビルド時の環境変数に設定した値がブラウザーに送信されるJavaScriptへコンパイルされる場合、その環境変数では秘密情報を非公開に保てない理由を示している。その方法で配布された管理者の認証情報は、訪問者から利用可能になる。
この露出は、より広範な問題であるダウンロード可能なAndroidアプリにハードコードされた秘密情報にも通じる。ユーザーに配布された素材は、攻撃者にも調査できるからだ。
この学校向け調達に関する調査結果では、別の誤りがあった。長くランダムなリクエスト識別子が、事実上レコードを変更する権限として機能していた。ControlPlaneによると、教育省は7月10日に問題を修正した。
この教員アカウント連携に関する報告には、重要な制限がある。テストでは新しいサインインを研究者自身のアカウントに連携したが、別のアカウントを乗っ取る経路や、別の申請者のログインを置き換えることは実証していない。この開示が説明しているのは、コード上で特定されたリスクと、その後の修正だ。
セキュリティチームが今すぐ確認すべきこと
露出した認証情報への即時対応は、それを発行したサービスで行うべきだ。GitHubの修正ガイダンスでは、リポジトリ履歴を書き換えるかどうかを判断する前に、まず無効化またはローテーションを行うよう求めている。
セキュリティチームとエンジニアリングチームは、今回の開示をもとに次の4領域を確認すべきだ。
- 認証情報の有効性：過去に露出したパスワード、トークン、アプリケーション秘密情報のすべてが無効化またはローテーション済みであることを確認する。リポジトリに関するアラートを閉じたり、ファイルを削除したりしただけでは、アクセスが終了したことの証明にはならない。
- アプリケーション権限：各連携のアクセス権を、実際のタスクと照らし合わせる。1つの人事ファイルを読み取るだけのワークフローが、無関係なサイトや従業員のストレージ全体に書き込めるなら、精査が必要だ。
- 公開ビルド成果物：本番環境のJavaScript、エクスポートされたノートブック、ダウンロード可能なパッケージを調べ、埋め込まれた秘密情報がないか確認する。ソースコードのチェックだけでなく、リリース成果物も対象に含める。
- レコードの所有権：リクエスト識別子を変更することで、あるセッションが別のセッションのレコードを読み取ったり変更したりできないかテストする。ゲスト向けのワークフローとアカウント連携時の競合も、明示的に確認する。
有効なまま残り、機密システムに到達できる認証情報を優先し、利用可能なIDおよびサービスの監査ログを使ってその使用状況を調査する。過去のログ取得範囲に空白があれば記録し、インシデント評価が実際に立証できる事実を反映するようにする。
この露出した認証秘密情報に関するGoogle DevSiteの欠陥は、漏えいした秘密情報が別の弱点と組み合わさることで、より被害の大きい攻撃経路を生み出し得ることを示している。したがって、修正には認証情報だけでなく、それを信頼していたアプリケーションの挙動も含めるべきだ。
次回のレビューでは、古い露出認証情報が機能しないこと、連携が無関係なリソースにアクセスできないこと、権限のないセッションからのリクエストをレコードが拒否することを、チームに実演させる。これらの確認によって、基盤となるアクセスが変更された証拠を得られる。
続きを読む：露出した秘密情報と弱いアクセス制御は、公共サービスを狙った攻撃でも確認された。 1人のハッカーが12のAIエージェントを使って台湾の緊急サービスを狙った経緯と、調査結果から防御側が学べること。