GitHub不正アクセスの実態、OAuthトークン窃取という盲点

業務システムのソースコード管理にGitHubを使い、複数のCI/CDツールやクラウドサービスと連携している開発チームに向けた話です。GitHubアカウントの侵害というと「パスワードを破られた」「多要素認証を突破された」といった正面突破を想像しがちです。ですが実際に起きている被害の多くは、もっと別の経路から発生しています。

何が起きるか

2022年、GitHubは大規模な不正アクセス事案を公表しました。HerokuやTravis CIといったサードパーティ連携サービスに発行されていたOAuthトークン（アプリ間の認可情報をやり取りする仕組みで、パスワードの代わりに使う一時的な鍵のようなもの）が盗まれ、それを使って複数の組織のプライベートリポジトリに不正アクセスされた事案です。

重要なのは、GitHub自体のログイン機構が破られたわけではないという点です。攻撃者はGitHubのパスワードを一度も入力していません。すでに正規に発行されていたトークンを、GitHub以外の場所から窃取して使い回しただけです。

影響範囲は組織単位で広がります。OAuthトークンには通常、そのアプリに許可された範囲のリポジトリへのアクセス権が紐づいています。連携しているサービスが1つ侵害されただけで、複数リポジトリの非公開コードが閲覧される可能性があります。

なぜ起きるか

原因を分解すると、GitHubが単独のサービスではなく「信頼の集合体」になっている点に行き着きます。開発者のGitHubアカウントは、組織・プライベートリポジトリ・GitHub Actions（GitHub上でCI/CDを実行する機能）・OAuthアプリ・個人アクセストークン（PAT）・SSHキー・クラウド認証情報・パッケージレジストリなど、多数の外部システムとつながっています。

この構造では、攻撃者はGitHub本体を狙わなくても、GitHubに接続する権限を持つ「別のどこか」を狙えば同じ結果を得られます。サーバー側から見れば「有効なトークン」「有効な権限」「正常なAPIリクエスト」の3条件が揃っているだけで、それが盗まれたものかどうかは判別できません。

フィッシング攻撃も同様の構造です。GitHubは、TOTPベースの二要素認証（時刻に応じて変化するワンタイムコードを使う認証方式）を使っていたアカウントでも、リアルタイムで認証情報を中継する精巧な偽ログインページによって突破された事例を報告しています。一方でハードウェアセキュリティキーはこの手口に対して耐性があったとされています。つまり「認証が強い」ことと「フィッシング耐性がある」ことはイコールではありません。

さらにアカウント侵害後の動きも見逃せません。攻撃者はアカウントを乗っ取った後、そこで終わらず新たなPATの発行、OAuthアプリの認可、SSHキーの追加といった「持続的なアクセス手段の確保」を試みたことが報告されています。1回の侵入が、複数の裏口を作る起点になり得るということです。

自分のプロジェクトが該当するか確認する

業務システムの開発現場でGitHub Organizationを使っているなら、まず確認すべき点は次の3つです。

Organization設定の「Third-party access」で、認可済みOAuthアプリの一覧と最終利用日を確認する
「Personal access tokens」画面で、有効期限なし・広範なスコープのトークンが放置されていないか確認する
SSHキーの登録一覧を見て、退職者や異動者のキーが残っていないか確認する

組織の管理画面（Settings > Third-party access > OAuth apps）では、各アプリがどのスコープ（read/write権限の範囲）を持っているかも一覧できます。CI/CDで使っているサービス、Slack連携、デプロイツールなど、業務で日常的に使うものほど見落とされがちです。

またPAT（個人アクセストークン）については、Classic形式かFine-grained形式かも確認しておく価値があります。Classic形式は権限範囲が粗く、リポジトリ全体に強いアクセス権を持ちやすいためです。Fine-grained personal access tokensは対象リポジトリと権限を細かく指定でき、漏洩時の被害範囲を絞り込めます。

対策の手順

組織のセキュリティ設定を見直す際は、次の順で進めると抜け漏れが減ります。

# GitHub CLIでOrganizationのメンバー一覧と権限を確認する例
gh api orgs/{org}/members --paginate

# 自分のアカウントに紐づくPATの一覧を確認（Web UIでの確認が基本だが gh でも一部把握可能）
gh auth status

手順としては以下を推奨します。

二要素認証を組織全体で必須化する（Settings > Security > Two-factor authentication）
可能であればハードウェアキーやパスキーを二要素認証の手段に採用する
OAuthアプリの棚卸しを行い、使っていない連携を削除する
PATは有効期限を必ず設定し、Fine-grainedへの移行を検討する
GitHub Actionsのワークフローで使うシークレットは環境ごとに分離し、必要最小限のスコープにする
監査ログ（Organization > Settings > Audit log）を定期的に確認し、見覚えのないOAuth認可やSSHキー追加がないか点検する

CI/CD基盤との接続点は特に重要です。Travis CIやHerokuのような外部サービスに発行したトークンが漏洩すれば、GitHub側の防御をすべて素通りしてリポジトリに到達します。連携サービスを追加するたびに「このサービスがもし侵害されたら、どこまで被害が及ぶか」を一度整理しておくと、後からの棚卸しが楽になります。

まとめ

GitHubの侵害は、正面からログインを突破する形ではなく、OAuthトークンの窃取やフィッシング、アカウント侵害後の裏口作りといった周辺経路から起きています。業務システムを運用するチームにとっては、GitHub本体の設定だけでなく、連携しているCI/CDサービスやOAuthアプリまで含めた棚卸しが欠かせません。

まず今日できることとして、Organization設定のThird-party accessとPAT一覧を開き、使っていない連携やスコープの広すぎるトークンがないか確認してみてください。それだけでも、思わぬ裏口を1つ塞げるはずです。