`tj-actions/changed-files` GitHub Actionがハッキング被害 - 23,000件のRepoで使用中

 (stepsecurity.io)
3 ポイント 投稿者 GN⁺ 2025-03-16 | 2件のコメント | WhatsAppで共有
  • 各ブランチの変更点追跡に使われる人気のGitHub Actionで、侵害されたコミットを通じて CI/CDシークレットの流出の試み が発生
  • 23,000件のRepoが影響を受け、GitHubはこのActionを削除したため、現在は利用不可
  • 代替Actionへの置き換え と、公開ワークフローログで シークレットが露出した可能性がある ため確認のうえ キーのローテーションが必須
  • StepSecurityの Harden-Runner が発見し、セキュリティを強化した代替Action step-security/changed-files を無料で提供中

事件の概要

  • tj-actions/changed-filesは23,000件以上のリポジトリで使われており、侵害が発生
    • 攻撃者はActionのコードを改変し、バージョンタグを悪意あるコミットに再指定
    • これにより GitHub ActionsのビルドログにCI/CDシークレットが出力 された
  • 公開されたワークフローログでシークレットが露出した可能性あり
  • Harden-Runnerが想定外のエンドポイントを検知した後に問題を発見
  • 悪意あるPythonスクリプトがRunner Workerプロセスからシークレットをダンプするよう動作
  • すべてのタグが同一の悪意あるコミットハッシュ (0e58ed8671d6b60d0890c21b07f8835ace038e67) に設定された

GitHubの対応措置

  • GitHubはtj-actions/changed-files Actionを削除し、利用を停止
  • 公式CVEは CVE-2025-30066

復旧対応方法

  • 1. StepSecurityが提供するセキュアな代替Actionを使用

    • tj-actions/changed-files Actionを step-security/changed-files@v45 に置き換え

  • 2. すべてのtj-actions/changed-files参照を削除

    • コードベースでtj-actions/changed-files参照を検索して削除: 
      git grep -l "tj-actions/changed-files"

  • 3. GitHub Actionsワークフロー実行ログを監査

    • 最近の実行ログでシークレットが漏えいしていないか確認が必要
    • 漏えいしたシークレットが見つかった場合は直ちにローテーション（再設定）が必要

  • 4. GitHub Actionsの許可リストを設定

  • 信頼できるGitHub Actionsのみ実行できるよう許可リストを構成:
    • GitHubの設定で許可可能:
      • Settings → Actions → Allow select actions

  • 5. StepSecurity Harden-Runnerを設定

    • Harden-Runnerでネットワークトラフィックとワークフロー実行の監視設定が可能

次のステップ

  • GitHubへ問題報告完了 → GitHub Issue: #2463
  • tj-actions/changed-filesリポジトリは削除済み
  • CVE-2025-30066 として正式登録
  • StepSecurity Harden-Runnerにより類似のセキュリティ問題の検知と防止が可能
  • セキュリティ体制を強化し、リアルタイム監視を行うためHarden-Runnerの設定を推奨

関連記事

2件のコメント

 
dl57934 2025-03-16

昨夜は動かなかったのですが、今はまた動いていますね
 
GN⁺ 2025-03-16
Hacker Newsのコメント

  • Renovateの作者兼メンテナーが攻撃シナリオを説明

    • 攻撃者は tj-actions/changed-files リポジトリへの書き込み権限を持っていた
    • 攻撃者は Renovate のコミットをスプーフィングし、最近のコミットに見せかけた
    • このスプーフィングは PR をだますためではなく、単に混乱を招くためのものだった
    • コミットは Unverified と表示され、ほとんどの人は署名付きコミットのみを強制していない
    • 本物の Renovate Bot は依存関係を更新するための PR を提案する
    • 自動マージを有効にしていた人もいたが、これはデフォルト設定ではない
    • この事件は、多くの人が git タグは不変だと誤解していることを思い出させる

  • ここ数年でサードパーティの依存関係や拡張機能に対する信頼が低下している

    • npm パッケージの依存関係が多い場合はインストールしない
    • vscode や chrome の拡張機能はインストールしない
    • 悪意あるコードが追加されたり、ライセンスが変更されたりすることが多い
    • eslint の依存関係ツリーを見ると、すべてを信頼してよいのか疑問に思う

  • リポジトリは再びオンラインになり、開発者が説明を提供

    • 攻撃は @tj-actions-bot アカウントの PAT トークンから発生した
    • アカウントのセキュリティは強化され、GitHub は侵害された PAT を失効させた

  • Clickhouse で github_events を調査し、攻撃に使われたアカウントを確認

    • "2ft2dKo28UazTZ", "mmvojwip" アカウントが疑わしい

  • CI/CD の実行方法が GitHub 上の任意のリポジトリを列挙するものになっているのは衝撃的

    • LLM の増加により、問題はさらに深刻になっている
    • 重要な作業は手動で実行すべき

  • StepSecurity の共同創業者がセキュリティインシデントを検知した方法を説明

    • Harden-Runner が GitHub Actions ワークフローのネットワーク呼び出しを監視し、異常を検知した

  • GitHub Actions の標準的な使い方が、不変ではない git タグを使うこと自体に問題がある

    • SHA-1 ハッシュアルゴリズムは衝突を起こしうるため、SHA-256 のサポートが必要

  • 不変の GitHub Actions が導入予定

    • Actions をフォークするか、コミットハッシュを使用する

  • maven-lockfile プロジェクトが自動マージされた PR を説明

    • 本物の Renovate Bot が偽の Renovate Bot のコミットを自動マージした

  • GitHub Actions は依存関係に対して lockfile を使うべき

    • Semver 記法は問題解決の良いソリューション