「Gheist」、GitHubトークンを悪用してクラウドの機密情報を窃取

侵害されたGitHubトークンを悪用し、数千件の開発者リポジトリからクラウドの機密情報や認証情報を収集する攻撃が続いています。侵害された開発者アカウントが、企業のクラウド環境への入り口になり得ることを改めて示す事例です。

Wiz Researchが週末に公開したレポートによると、「Gheist」と名付けられたこの攻撃キャンペーンでは、850以上の侵害されたGitHubアカウントにまたがって、1万3,500を超える悪意あるブランチ（プロジェクトのコードの別バージョン）が作成されました。

被害は個人のプロジェクトから企業の非公開リポジトリまで幅広く及んでいます。ただし、公開リポジトリについては、7月にGitHubが導入した保護機能によって守られていると、レポートは述べています。

Wizの研究者Rami McCarthy氏はDark Readingに対し、「GitHubが追加した対策は、公開リポジトリをワークフローの悪用手口から守ることに主眼を置いたものです」と語ります。一方で、「企業の認証情報が侵害されてしまえば、この対策は適用されません」とも指摘しました。

Wizはまた、Gheistの影響を受けたGitHubアカウントと、ほかの悪用キャンペーンとの間に重複があることも確認しました。重複していたのは、リポジトリを介したマルウェア配布、計算資源を得るためのGitHub Actionsの悪用の試み、そして別のマルウェア活動に関連するとみられる感染などです。

この重複は、Gheistを類似のキャンペーンと区別する特徴です。盗まれた開発者トークンが、攻撃者の間で再利用または共有されている可能性を示唆しており、McCarthy氏は「この脅威をめぐる状況の複雑さと活発さを示すものです」と述べています。

窃取の中核を担うワークフロー

研究者らによると、このキャンペーンは「sync-check」という名前のワークフローに依存しています。盗まれたトークンでアクセスできるすべてのリポジトリに、このワークフローがコミットされます。

研究者らは次のように説明しています。「このワークフローは、リポジトリのシークレットを自身のワークフローログに出力させようとします。その後、ツールがGitHub APIを通じてログをダウンロードし、数秒後に実行履歴を削除します。ツールのAPIリクエストにはユーザーエージェント『gheist』が含まれており、これがキャンペーン名の由来です」

Wizがこの活動の追跡を始めたのは9月15日で、10月24日の時点でも攻撃は続き、進化し続けているといいます。研究者らがGitHubに報告したところ、関与したアカウントの約3分の2が利用できなくなりました。レポートはこれを「対応措置が取られたことを示している可能性が高い」としています。

盗まれたトークンがさらなる機密情報の窃取を助長

研究者らによると、トークンの入手元は主に2つとみられます。情報窃取型マルウェアと、過去のソフトウェアサプライチェーン侵害で流出した認証情報です。

GitHubトークンは、ユーザーやアプリケーションにリポジトリ、コード、管理機能へのアクセスを認可するものです。そのため、プロジェクトや組織の侵害をもくろむ攻撃者にとって価値の高い標的になっています。

レポートによると、Gheistは盗んだGitHubトークンを使って、「ci-sync-」に6文字を続けた名前のブランチを作成します。続いて、コミットメッセージを「ci: sync config」として、.github/workflows/sync-check.ymlにGitHub Actionsのワークフローを追加します。

研究者らは「このコミットには署名がなく、作成者はトークンの所有者として記録されます」と述べています。これによって発生するプッシュイベントがワークフローを起動し、環境変数とリポジトリのシークレットをログに出力させようとします。攻撃ではこの出力をBase32でエンコードし、GitHub APIでログを取得した後、数秒でワークフローの実行履歴を削除します。

研究者らは「シークレットはGitHub自身のAPIを通じて持ち出されるため、ブロックすべき攻撃者のドメインや外部への通信は存在しません」と説明しています。

狙われる企業

重要な発見は、公開リポジトリ向けの保護機能が適用されない非公開リポジトリや企業環境で、Wizが攻撃の成功を確認したことです。McCarthy氏はDark Readingに対し、これに対してGitHubを狙う活動の大半は、主に公開リポジトリに影響すると述べています。

サプライチェーンセキュリティ企業Cloudsmithのセキュリティ責任者James Matchett氏は、メールでのインタビューで次のように語りました。「数カ月前に担当者へ発行された認証情報が、依然としてフルの書き込み権限を持っていたため、組織が最も安全だと考えていた環境で攻撃が成功しました。『非公開』は対策になりません。対策とは、スコープを絞った短命な認証情報、プッシュとプルが可能な対象の厳密な棚卸し、そしてインシデントのたびに認証情報をローテーションする規律です」（サプライチェーンセキュリティ）

Wizによると、攻撃者は複数のユーザーや自動化アカウントのトークンを次々と使い回し、悪意あるワークフローを仕込む前に非公開リポジトリをクローンしていました。研究者らはさらに、数時間のうちに、同じ組織のクラウド認証情報がAWS Secrets Managerの列挙に使われたと付け加えています。

McCarthy氏によると、Wizはこのキャンペーンの影響を「十数社規模」と見積もっています。ただし同氏は、「GitHubリポジトリの大量クローンと中核となる認証情報の窃取を除けば、一貫した、あるいは自動化された悪用は確認していません」と話しています。

トークン悪用への対策

トークンの悪用は、開発パイプラインを経由して組織に侵入する手口として、ますます一般的になっています。昨年のBlack Hat Europeで発表された研究では、過去1年間に起きた最も重大なソフトウェアサプライチェーンのインシデントのいくつかで、攻撃者がGitHubの欠陥を悪用していたことが明らかになりました。防御側は、開発プロジェクトを組織の重要な資産として扱う必要があります。

Wizは、Gheistやその他のトークン悪用への対策として、セキュリティチームに次の対応を促しています。悪意あるGitHub Actionsワークフローを探し出すこと、流出したシークレットをローテーションすること、そして侵害されたセルフホスト型ランナーをインフラ侵害の可能性があるものとして扱うことです。

より具体的には、「ci-sync-」に6文字を続けた名前のブランチのうち、変更内容がコミットメッセージ「ci: sync config」の新規ファイル.github/workflows/sync-check.ymlだけであるものを探すよう、研究者らは助言しています。管理者は、GitHubの監査ログも確認すべきです。具体的には、「ci-sync-*」ブランチでのワークフロー実行のうち、完了から1分以内に削除されたものや、ユーザーエージェント「gheist」による活動が対象です。

GitHubトークンの悪用（GitHub token abuse）に対する幅広い防御策として、セキュリティ企業Secure.comのエンジニアリング責任者Waseem Ahmed氏は、組織に対し「長期有効な個人アクセストークンを、GitHub Appsまたは短命のきめ細かいトークンに置き換える」ことと、「本番環境のシークレットを保持するすべての環境でレビュアーを必須にする」ことを勧めています。こうした対策は、攻撃者が有効なトークンを入手した場合でも、機密性の高い認証情報へのアクセスを制限するのに役立ちます。