サプライチェーン攻撃「Repo Squatting」：GitHub Actions経由で認証情報を窃取する巧妙ななりすまし手口と防御戦略

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

サプライチェーン攻撃「Repo Squatting」：GitHub Actions経由で認証情報を窃取する巧妙ななりすまし手口と防御戦略

【脅威の概要と背景】

本レポートで扱うのは、GitHubのエコシステムにおける「リポジトリ占拠（Repo Squatting）」を用いたサプライチェーン攻撃です。これは、人気のある公式リポジトリ名と非常に類似した名前（例: npm/actions ではなく np-m/actions）で悪意のあるリポジトリを作成し、ユーザーの誤認を誘って、CI/CDパイプライン（GitHub Actions）内でマルウェア実行や認証情報の窃取を試みるソーシャルエンジニアリングと技術的要素を組み合わせた手法です。特定のCVE番号は付与されていませんが、この攻撃はオープンソースソフトウェアの依存関係に潜む恒常的なリスクであり、ATT&CKフレームワークにおいては「T1588.002（開発ツールの窃取）」や「T1195.002（サプライチェーンの妥協：サードパーティ）」に関連付けられます。

【攻撃シナリオの可視化】

Repo Squattingは、GitHub Actionsなどの自動化されたワークフローを悪用して、標的組織の環境内でマルウェアを実行させるキルチェーンを構築します。

Mermaid図解（Repo Squattingによるサプライチェーン攻撃）

graph TD
    A["攻撃者: 悪意あるActionsリポジトリの作成"] -->|名称の類似性(Typo Squatting)| B("公式リポジトリと誤認させる");
    B --> C["開発者: CI/CDワークフローへの参照追加"];
    C -->|誤ったリポジトリ名を参照| D{"GitHub Actions実行"};
    D --> E("悪意あるコードの実行");
    E -->|GITHUB_TOKENの窃取/永続化| F["攻撃者のC2サーバーへ送信"];
    F --> G["組織リソースへの不正アクセス"];

解説

  1. Preparation (A→B): 攻撃者は、公式の著名なActions（例: actions/checkout）と酷似した名前（例: actionss/checkout）のリポジトリを作成し、その内部に悪意のあるステップを仕込みます。

  2. Infection (C→D): 開発者がActionを検索・実装する際、リポジトリ名のタイポ（打ち間違い）や確認不足により、誤って悪意あるリポジトリを参照するようワークフローファイル（.github/workflows/*.yml）を記述します。

  3. Execution (D→E): プッシュやプルリクエストなどのイベントがトリガーされると、GitHub Actionsランナーは悪意あるリポジトリからコードを取得し、ジョブコンテキスト内で実行します。

  4. Impact (E→F→G): 実行された悪意あるコードは、当該ジョブに付与されている最小権限以上のGITHUB_TOKENを窃取したり、環境変数やシークレットを外部に送信したりして、リポジトリ内のコード、プライベートパッケージ、または組織内の他のリソースへのアクセスを確立します。

【安全な実装と設定】

Repo Squatting攻撃を防ぐ最も確実な方法は、GitHub Actionsの依存関係（uses:句）を厳格に指定し、依存元リポジトリの完全な識別子と固定されたバージョン（コミットSHA）を使用することです。

誤用例（脆弱な書き方）

最新バージョンへの自動追従を期待し、ブランチ名やタグ名のみを指定する書き方は、攻撃者がタグやブランチを操作した場合にリスクが高まります。

“`yaml:action-vulnerable.yml

開発者がTypo Squattingのリポジトリを参照していることに気づいていない。

例: ‘actionss’ は正規の ‘actions’ ではない悪意あるリポジトリ

jobs: build: runs-on: ubuntu-latest steps:

  - uses: actionss/checkout@v3  # <-- 脆弱性: リポジトリ名が間違っている

  - uses: official-org/action-name@main # <-- 脆弱性: mainブランチが書き換えられるリスク

### 安全な代替案（厳格なセキュリティコード）

依存するActionは、信頼できる組織が提供していることを確認し、**ブランチやタグではなく、必ず完全なコミットSHA-1ハッシュ値で固定**します。これにより、攻撃者がリポジトリの内容を後から書き換えても、既存のワークフローが勝手に悪意あるコードを実行することはありません（依存関係のロック）。

```yaml:action-secure.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:

      # 1. 信頼できる組織/リポジトリを使用


      # 2. ブランチ/タグではなく、特定のコミットハッシュ（40文字）で固定


      # GitHub Marketplaceや公式ドキュメントでSHA値を確認すること


      - name: Checkout Code
        uses: actions/checkout@b4d241d7d0840b395123d47668b5a046c8b0e796 # <-- v4.1.6 相当の固定SHA値

      # 3. 組織内のアクションは内部でのみ利用する設定を優先


      - uses: self-hosted-runner/internal-tool@v1

設定による保護策（組織レベル）

GitHub Enterprise CloudおよびOrganizationユーザーは、ポリシー設定によってRepo Squattingの発生リスクを大幅に下げることができます。

  1. 外部Actionsの使用制限:

    • 組織設定 (Settings -> Actions -> General) にて、「Allow select actions」を選択し、自社で作成したActions、および特定の検証済みサードパーティActions（例: actions/*、github/*）のみを許可リストに追加します。

    • 特に、「Allow actions created by GitHub」と「Allow marketplace verified actions」のみを許可し、未検証のサードパーティActionsの利用をデフォルトで禁止することが推奨されます。

  2. Secretと権限の管理:

    • CI/CDジョブに対しては、最小権限の原則を徹底し、GITHUB_TOKENの権限範囲を必要最低限（contents: readなど）に制限します。

    • 重要なシークレット（例: AWS認証情報）は、信頼できる内部ActionまたはOIDC（OpenID Connect）を利用した認証を通じてのみアクセスできるように設定します。

【検出と緩和策】

Repo Squatting攻撃は静的な監査だけでは見落としやすいため、ランタイム環境とSCM監査ログの両面で監視を行う必要があります。

フェーズ 検出ポイント（EDR/SIEM） 応急的な緩和策（Workaround）
開発/コードレビュー 依存関係変更の監視: GitHub Pull Requestで .github/workflows/ ファイルが外部リポジトリを参照するように変更された際の通知（特に新しいオーナーや見慣れないリポジトリ名）。 Pull Requestテンプレートの強制: 外部Actionsを追加する場合、必ずレビュアーがそのリポジトリの信頼性を公式ドキュメントやGitHub Marketplaceで検証することを要求する。
実行時 ランタイム環境監視: CI/CDランナー上で予期しないネットワーク接続（C2通信の試み）や、認証情報ファイルへのアクセス試行をEDRで検知。 ランナー環境の隔離: セルフホストランナーを使用している場合、ランナーが外部リポジトリや重要な本番環境へアクセスできないようにネットワークACLで制限する。
全体 GitHub監査ログの分析: 頻繁に依存関係が変更されているリポジトリ、またはOrganization設定でActionsの制限ポリシーが緩和された際のログをハイライト。 Actionsの即時無効化: 不正なActionの実行が確認された場合、そのワークフローファイル（.yml）内の当該ステップをコメントアウトするか、ワークフロー自体を一時的に無効化する。

【実務上の落とし穴】

1. 可用性（サービス継続）とのトレードオフ

「安全な実装」で推奨したコミットSHA-1での依存関係の固定は、セキュリティを向上させますが、Actionの提供元がセキュリティパッチや新機能を追加しても、ワークフロー側が自動的に追従できなくなります。 リスク: セキュリティ修正を取り込む際も手動でSHA値を更新する必要があり、運用負荷が増大します。これを怠ると、依存しているAction側に脆弱性が発見されても、古い脆弱なバージョンを使い続けることになります。 対策: Dependabotなどの依存関係管理ツールや、定期的な監査スクリプトを用いて、固定したSHA値が最新の安定バージョンに対応しているかを自動チェックする仕組みを導入します。

2. 誤検知（False Positive）のリスク

多くの組織では、開発者が独自に作成したユーティリティActionsや、複数のリポジトリ間で共通利用するActionsが存在します。これら内部の依存関係変更を外部の脅威と誤認し、アラートのノイズを増大させる可能性があります。 対策: 内部的に管理しているリポジトリのリストを作成し、監視システムがこれらの内部依存関係の変更を正常なアクティビティとして扱うように、ホワイトリストを整備します。

【まとめ】

GitHub Repo Squattingは、見過ごされがちな依存関係のタイポミスを突く高度な攻撃です。組織のサプライチェーンを守るため、以下の3つの優先事項を直ちに実施してください。

組織として今すぐ確認・実施すべき3つの優先事項

  1. Actionsの使用制限ポリシーの強化:

    • GitHub Organization設定において、未検証のサードパーティActionsの実行を禁止し、許可リスト（Allow List）に基づいて、信頼できるアクションのみ実行を許可する設定を適用する。（最優先）

  2. 依存関係の厳格な監査と固定:

    • 既存の全てのGitHub Actionsワークフローを監査し、外部リポジトリを参照しているActionsについて、必ずコミットSHA-1ハッシュ値を使用してバージョンを固定する。

  3. 開発者へのセキュリティ教育:

    • 新しいActionを導入する際、必ずGitHub Marketplaceで提供元と信頼性を確認し、リポジトリ名（オーナー/リポジトリ名）にタイポがないか、ダブルチェックすることを義務付ける。

参考文献

  • GitHub Docs: Security hardening for GitHub Actions (具体的なセキュリティ設定方法に関する公式ドキュメント)

  • OpenSSF (Open Source Security Foundation): Scorecard Project (依存関係の健全性を自動評価するためのツールと基準)

  • MITRE ATT&CK Framework: T1588.002 – Obtain Capabilities: Development Tools (攻撃者が開発環境を標的にする手法に関する解説)

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました