GitGuardianは、公開されていた大量の認証情報の中から、依然として有効な474件のGitHubアプリ用秘密鍵を発見しました。中にはアカウント乗っ取りにつながる権限を持つものも含まれていました。
GitHubでは、組織がGitHubアプリをインストールすることで、プラットフォーム上の特定機能を自動化・拡張し、選択したリポジトリや権限にアクセスできるようになっています。しかし、こうしたアプリケーションが自身を認証するために使う秘密鍵は、手動で失効させない限り何年も有効なまま残ってしまう可能性があります。
GitGuardianによれば、この鍵が流出した場合、攻撃者が組織のGitHubアカウントに対して管理者権限を握る恐れがあるといいます。同社は2019年以降に収集した4,802件の公開流出済み鍵のうち、474件が依然として有効なGitHubアプリ用秘密鍵であることを発見しました。
鍵の有効性をテストする過程で、同社はそれらが付与するアクセス権限も特定しました。GitGuardianの研究者Gaetan Ferry氏がブログ投稿で述べたところによると、「侵害されたアプリの72%はプライベートリポジトリの内容を読み取ることができ、207件は書き込みも可能でした。つまり、たった1つの流出鍵が組織全体の乗っ取りにつながりかねない」ということです。
流出した鍵の影響を受けたGitHubアプリの一つに、「Access Tokens for GitHub Actions」がありました。これはGitHub Actionsのワークフローへのアクセスを管理するために使われるアプリケーションです。その秘密鍵は2024年1月、誤ってリポジトリにコミットされたことで流出し、このアプリをインストールしていたCivicaやSierra Nevada Corpを含む最大300の組織に影響を及ぼした可能性があります。
GitGuardianが流出鍵を発見した他のGitHubアプリには、BuildBuddy、Crusher.dev、そして米疾病対策センター(CDC)に関連する非公開アプリケーションなどがありました。
セキュリティソフトウェアベンダーColorTokensのチーフエバンジェリストであるAgnidipta Sarkar氏によれば、初期段階の悪用は「極めて単純」であり、攻撃者は有効な秘密鍵と対応するアプリIDさえあれば実行できるといいます。同氏は、被害を最大化するために、攻撃者が「リポジトリに悪意のあるコードを注入し、そのコードがビルドまたはデプロイされる際に、下流のユーザーや本番環境を侵害する」形で攻撃を連鎖させる可能性があると指摘しました。
Sarkar氏はさらに、攻撃者がCI/CDランナーの設定を改変し、組織の内部ネットワークインフラ上で任意のコードを実行できるようになる可能性もあると付け加えました。
GitGuardianは、影響を受けたすべてのアプリケーション所有者に流出鍵について通知したとしています。また、同社自身のシークレットスキャンサービスも、流出した認証情報を監視するためにGitHubアプリを使用していると述べています。
流出した鍵は多様なアクセス権限を保持
組織がGitHubアプリをインストールする際には、そのアプリがアクセスできるリポジトリと、そこで実行できる操作を決定します。GitGuardianの調査では、影響を受けたアプリのうち40件がセルフホスト型ランナーを管理でき、98件がワークフローを制御でき、44件が組織管理者権限を持っていたことが判明しました。
組織管理者権限を持つアプリについて、Sarkar氏は「攻撃者が自分自身をオーナーとして追加し、正規の管理者をロックアウトして、GitHub組織を完全に乗っ取ることができてしまう」と述べています。
流出したアプリの中には、303件ものインストール実績を持つものがあった一方、まったくインストールされていないものもありました。そして59%は1件のみのインストールで、私的利用であることを示唆しています。
こうした内部利用・単一インストールのアプリについて、Ferry氏は「これらは社内の自動化ツール、CIボット、単発のツール類であり、もう使われていなくても簡単に忘れ去られてしまうものです」と述べています。こうしたアプリは誰にも気づかれないまま稼働を続け、鍵も無期限に有効であり続ける可能性があります。
GitGuardianはまた、流出した秘密鍵が本来のものとは無関係のリポジトリに存在していたケースを156件発見しました。これにより、その認証情報を所有するGitHubアプリとの紐付けがより困難になっていました。
「被害の範囲はアプリの所有者だけにとどまりません」とFerry氏は述べています。「そのアプリをインストールしたすべての組織に及び、サプライチェーンの依存関係を通じて、そのアプリが関わるコードを利用するすべての下流ユーザーにまで広がります」
鍵のローテーションこそが唯一の解決策
GitHubは公式のドキュメントで、秘密鍵は自動的に失効することはなく、手動で失効または削除する必要があると警告しています。それにもかかわらず、多くの組織は鍵の仕組みについて誤った前提を抱いており、これを実施できていない可能性があります。
秘密鍵はアプリの設定画面で生成され、短命なJSON Web Token(JWT)に署名するために使われます。このJWTをGitHubが受理すると、インストールアクセストークンが発行される仕組みです。このインストールトークンには、組織がアプリをインストールした際に付与された権限が引き継がれます。
JWTは数分で失効し、インストールトークンも有効期限はわずか1時間しかありません。このため悪用可能な時間は非常に短く、鍵の管理を失っても限定的なリスクしかないという印象を与えてしまいます。
しかし、秘密鍵さえ保持していれば、誰でも無数のJWTを生成してそのGitHubアプリになりすまして認証を行い、秘密鍵が有効である限り、GitHubに新たなインストールトークンを次々と発行させることができてしまいます。
「これは見落としというより、意図的な設計上のトレードオフである可能性が高いでしょう」と、Sarkar氏は短命トークンと恒久的な鍵を組み合わせた実装について述べています。「これはマシン間認証の伝統的な仕組みであり、予期せぬダウンタイムを防ぐためのものです」。同氏は、この「永続的」な設計は運用のシンプルさと継続性を優先しており、ローテーションのセキュリティ上の負担はすべてアプリ所有者側にのしかかっていると付け加えました。
GitGuardianは、秘密鍵を定期的にローテーションまたは失効させることを推奨しています。なぜなら鍵は、それを作成した人物やその理由が忘れ去られた後も生き続けてしまうことがあるからだと、Ferry氏は述べています。「2020年に誤ってコミットされた鍵が、そのミスがとっくに忘れられた今日でも、依然として認証に使えてしまうことがあるのです」と同氏は語りました。
一方でSarkar氏は、手動での失効は非常にまれであり、ほぼ常に事後対応でしかないと指摘します。「ほとんどのITサービスマネジメントのマニュアルにはその必要性が記載されていますが、セキュリティインシデントや監査、あるいは特定の変更が求められない限り、実際に実施されることはほとんどありません」と同氏は説明しました。
