メガロドン攻撃、6時間で5,561件のGitHubリポジトリを標的に

メガロドン攻撃、6時間で5,561件のGitHubリポジトリを標的に

「メガロドン」と名付けられたGitHub CI/CDサプライチェーン攻撃が、自動化された大規模なリポジトリ侵害の新たな基準を打ち立てた。わずか6時間という単一の時間枠の中で、攻撃者は偽のIDを使って5,561件のGitHubリポジトリに5,718件の悪意あるコード更新をプッシュし、クラウド認証情報・SSHキー・ソースコードのシークレットを密かに流出させるよう設計されたワークフローファイルを注入した。このキャンペーンの圧倒的なスピードと規模は、ほとんどのチームがリアルタイムで検知・対応できる能力を超える、産業化されたパイプライン攻撃への転換を示している。

メガロドン攻撃の手口：偽IDと自動化されたワークフロー注入

メガロドンの攻撃者たちは、ゼロデイ脆弱性の悪用やエンドユーザーのマシンへの高度なマルウェア配布には頼らなかった。その代わりに、GitHubのCI/CDインフラそのものが持つ信頼性を悪用した。偽のコントリビューターIDを構築することで、プルリクエストを提出するか、ワークフロー設定ファイル、具体的にはGitHub Actionsが自動ビルドおよびデプロイパイプラインの定義に使用するYAMLファイルを直接改ざんした。

悪意あるワークフローファイルがリポジトリに着地すると、パイプラインがトリガーされるたびに自動的に実行される。これは通常、プッシュイベントやプルリクエストのマージ時に発生する。その実行はGitHub自身のランナー環境内で行われ、そこにはリポジトリのシークレット、環境変数、クラウドプロバイダーにスコープされたトークンへのアクセス権があることが多い。メガロドンのワークフローは、リポジトリのメンテナーが変更を確認する前に、そのアクセス窓を利用してデータを攻撃者が管理するインフラへ外部に流出させたとみられる。

このキャンペーンの際立った特徴はその自動化にある。6時間で5,500以上のリポジトリに対して約5,720件の異なるコードプッシュを実行することは、手作業ではできない。ターゲットを特定し、偽のIDで認証し、もっともらしいワークフローの変更を作成し、それらを並行して提出できるスクリプト化されたツールが必要だ。このレベルの自動化は、いかなる人間の監視チームも追跡できないスピードで攻撃対象領域が拡大することを意味する。

何の認証情報が盗まれたか、そして開発者にとってなぜ重要か

各悪意あるワークフローのペイロードは認証情報の収集だった。標的には、GitHubのSecretsとして保存されるか、ワークフローの環境変数内で参照されるクラウドプロバイダーの認証情報（最も一般的なのはAWS、GCP、Azureのアクセスキー）が含まれていた。サーバーアクセスやサービス間認証に使用されるSSH秘密鍵も対象に含まれており、ソースコードや設定ファイルに埋め込まれた平文のシークレットも同様だった。

これらの認証情報の種類は連鎖的なリスクをはらんでいる。広範な権限を持つIAMロールに紐付いた盗まれたAWSアクセスキーがあれば、攻撃者は数分以内にインフラを立ち上げ、データストアを流出させ、接続されたサービスに横展開できる。SSHキーは、最初の侵害が検出されGitHubリポジトリがクリーンアップされた後も、本番サーバーへの持続的なアクセスを提供し続ける可能性がある。このデータの価値はリポジトリそのものをはるかに超えている。

これは仮説的なリスクパターンではない。今年初め、CISAの委託業者がAWSキーと平文パスワードを公開GitHubリポジトリで公開してしまった事例が示すように、開発環境における認証情報の不適切な管理は、専任のセキュリティ体制を持つ組織でさえも影響を受ける。メガロドンは、個々の人為的ミスがすでに繰り返し実証してきた同じ悪用経路を、単に産業化したにすぎない。

また、認証情報の盗取ツールやパイプライン自体も標的になり得ることも注目に値する。最近のBitwarden CLIサプライチェーン攻撃は、開発者がシークレットの管理に使用するツールでさえ上流で侵害される可能性があることを示しており、信頼の連鎖は単一のリポジトリやパイプライン設定を超えて広がることを意味する。

開発チームのための多層防御：シークレット管理、暗号化された通信、アクセス制御

メガロドンは、オープンソースおよびプライベートリポジトリ全般に共通するいくつかの弱点を突いた。それらに対処するには、単一の制御ではなく多層的なアプローチが必要だ。

第一に、シークレットはワークフローファイル、環境設定ファイル、ソースコードのいずれにも平文で保存すべきではない。GitHubの暗号化Secrets機能はベースラインを提供するが、それらのシークレットも最小権限の原則に従うべきだ。ステージング環境にデプロイするワークフローに、本番データベースの認証情報は必要ない。シークレットのスコープを厳密に絞ることで、ワークフローが侵害された際の影響範囲を限定できる。

第二に、ブランチ保護ルールとワークフローファイル変更に対する必須レビュアーの設定が、自動化された攻撃が回避しなければならない人間によるチェックポイントを作り出す。.github/workflows/ファイルへのいかなる変更も、少なくとも1件の承認済みレビューを必須とすることで、メガロドンが依存した急速な自動注入を遅らせるか阻止できる。

第三に、サードパーティのGitHub Actionsをフローティングタグではなく特定のコミットSHAに固定することで、侵害されたアクションの公開者がタグを悪意あるコードに静かに更新するという、別の関連する攻撃ベクトルを防ぐことができる。これは最近のGitHub Actionsサプライチェーンインシデントのいくつかにおけるメカニズムだった。

最後に、ワークフロー実行の監査ログと異常検知により、予期しない外部ネットワーク接続や異常なシークレットアクセスパターンを表面化させることができる。GitHubの監査ログAPIとサードパーティのCI/CDセキュリティツールが、これらのシグナルの検出に役立つ。

今すぐGitHubリポジトリとCI/CDパイプラインを監査する方法

あなたの組織がアクティブなCI/CDパイプラインを持つGitHubリポジトリを管理しているなら、いくつかの即時対応を優先する価値がある。

.github/workflows/配下のすべてのファイルについて、最近追加または変更されたエントリー、特に見覚えのないコントリビューターによって追加されたものを確認する。デフォルトブランチのビューだけでなく、ワークフローファイルに特化したコミット履歴を確認すること。

攻撃期間中にアクティブだったシークレット、または未露出であることを確信を持って確認できないシークレットをローテーションする。クラウド認証情報については、同じ時間帯における異常なAPIコールについて、プロバイダー側のアクセスログを確認する。

どのリポジトリコントリビューターとアプリケーションが書き込みアクセス権を持つかを監査する。偽IDによる攻撃はコードをプッシュする能力に依存しているため、コントリビューターの権限を厳格化し、ワークフロー変更に必須レビューを有効にすることで、主要な侵入口を排除できる。

最後に、すべてのコミットで実行される専用のシークレットスキャンツールの採用を検討し、認証情報がリポジトリにコミットされる前に検出するようにする。いくつかのオープンソースおよび商用オプションがGitHubと直接統合されている。

あなたへの影響

メガロドンキャンペーンは、CI/CDパイプラインが主要な攻撃対象領域となっている理由を実証的に示している。パイプラインセキュリティをアプリケーションセキュリティより二次的なものとして扱う開発者やセキュリティチームは、最も機密性の高い認証情報への広く開かれた経路を残していることになる。

今週、シークレット監査から始めよう。ワークフローファイルを変更できる人物を確認し、クリーンであると確認できない認証情報をローテーションし、まだ行っていなければデフォルトブランチのブランチ保護を有効にする。メガロドン攻撃のスピードは、アラートが発火した時点で、すでに流出が完了している可能性があることを意味する。予防とアクセスのスコープ設定が唯一の確実な防御手段だ。