gitlab-runner-research は、攻撃者が自前ホスト型 GitLab Runner を登録または悪用して任意のパイプラインジョブを実行する方法を示す、概念実証（PoC）用リポジトリおよび解説です。このリポジトリには、攻撃者が Runner の登録トークンを発見または悪用し、Runner を登録し、悪意あるジョブを実行し、Runner の設定や分離が弱い場合にアーティファクトやシークレットへアクセスする方法を示すスクリプトとジョブテンプレートが含まれています。
概要
自前ホスト型 GitLab Runner は、Runner ホストが持つ権限とネットワークアクセスで CI/CD ジョブを実行します。運用側のコントロールが弱く、登録トークンが露出していたり、Runner のスコープが広すぎたり、ネットワーク分離が行われていない場合、攻撃者は Runner を兵器化できます。この PoC では、Runner の登録、悪意あるパイプラインジョブの投入、ジョブ実行を利用したアーティファクトの読み取り、変数の抽出、内部サービスへのアクセスといった、再現性のある手法を文書化しています。
特徴
- 登録の自動化: トークンが発見可能な場合に Runner 登録を自動化するスクリプト。
- 悪意あるジョブテンプレート: アーティファクトの要求、環境変数の列挙、内部エンドポイントの探索を行うよう設計されたパイプライン例。
- 再現可能なテストハーネス: 分離された Runner をデプロイし、ラボ環境で挙動を再現するためのステップバイステップ手順。
- 防御チェックリスト: すぐに適用できる簡潔な緩和策と検知ガイダンス。
インストール
リポジトリをローカルにクローンし、何かを実行する前に README とブログ記事を確認してください。本番システムや、あなたが管理していない環境に対してこれらのスクリプトを実行しないでください。
|
git clonehttps://github.com/Frichetten/gitlab-runner-research.git cd gitlab–runner–research |
環境構築、テスト手順、スクリーンショットについては、リポジトリの README と著者のブログに従ってください。
使い方
PoC は必ず制御されたラボ環境でのみ使用してください。安全なワークフローの一例は次のとおりです。
- 使い捨ての GitLab インスタンスをデプロイするか、分離された GitLab サーバー上のサンドボックス化されたテストプロジェクトを使用する。
- Runner 登録スクリプトを確認し、テスト用の登録トークンを保有していることを確認する。本番トークンは使用しない。
- テストトークンを使用して、自分が管理する VM またはコンテナ上にテスト Runner を登録する。
- 分離されたプロジェクトで提供されているジョブテンプレートを実行し、そのジョブがアクセスできるもの（アーティファクト、変数、ネットワーク）を観察する。
- 検知ルールの構築と緩和策の検証のために、ログ、ジョブトレース、ネットワークキャプチャを収集する。
攻撃シナリオ
目的: 発見した登録トークンを、Runner の悪用を通じた実運用レベルのアクセスへと変換する。
- 発見: 公開コード、Wiki、CI 設定、誤設定されたストレージなどを検索し、露出した登録トークンや漏えいした CI 変数を探す。
- 登録: トークンの権限に応じて、プロジェクト・グループ・インスタンススコープで Runner を登録する。
- 配信: アクセス可能なアーティファクトの読み取り、内部サービスの呼び出し、マウントされたパスからのシークレット取得を行うステップを含むジョブをトリガーする CI 設定をプッシュする。
- 実行: Runner がジョブを実行する。Runner ホストにネットワークの外向き通信やマウントされた認証情報がある場合、ジョブは機密データへアクセスしたり、さらなるピボットを行える。
- 流出／ピボット: ジョブが攻撃者管理のエンドポイントへデータを流出させるか、取得した認証情報を用いて他システムへアクセスする。
レッドチームにおける有用性
この PoC は、レッドチームが CI/CD リスクをコンパクトかつ高インパクトに実証するための手段を提供します。PoC を用いて、ビジネスインパクト（アーティファクト窃取、シークレット流出、ラテラルムーブメント）を示す明確で再現性のある証拠を作成し、迅速な是正措置を促してください。フォローアップ検証として、Burp Suite や OWASP ZAP を用いたプロキシテストや、Darknet のファジングアーカイブにあるファジング手法と組み合わせるとよいでしょう。
検知と緩和
- インスタンス全体 Runner を無効化: 必要な場合を除き、インスタンススコープの Runner は避ける。厳格な登録管理を行ったプロジェクト／グループスコープ Runner を優先する。
- 登録トークンの保護: トークンをシークレットとして扱い、ボルトに保管し、定期的にローテーションし、リポジトリや Wiki に決してコミットしない。
- Runner の分離: Runner を制限されたネットワークに配置し、外向き通信制御を強制し、ホストマウントなしの非特権コンテナでジョブを実行する。
- 最小権限: CI ホストおよび Runner に付与する IAM やサービスアカウントの権限を最小限に抑える。
- ハンティングとアラート: 新規 Runner 登録、不審な Runner ホスト名、標準パターン外のジョブを拾う Runner を検知する。
- パイプライン制約: 保護ブランチを必須とし、機密性の高いパイプラインにはマージリクエスト承認を強制し、保護変数やジョブトークンのスコープ制御を利用する。
- 監査とログ: CI ログとジョブ出力を一元管理し、プロジェクトをまたいだアーティファクトアクセスや内部メタデータエンドポイントへの呼び出し試行に対してアラートを発火させる。
比較
Runner の悪用は、漏えいしたシークレット、OIDC の誤設定、過剰な権限を持つサービスアカウントといった他の CI/CD 脅威と並ぶものです。自前ホスト型 Runner は、Runner の所有者が実行環境を制御しているため、リスクが高まります。この PoC は、静的なシークレットスキャンではなく、ランタイム実行を通じた運用上の悪用に焦点を当てています。
関連する他のツールとしては、GitLab Watchman – Gitlab の機密データと認証情報を監査 や Anteater – CI/CD セキュリティゲートチェックフレームワーク があります。
結論
gitlab-runner-research は、誤設定された自前ホスト型 Runner がいかに高インパクトな攻撃面となり得るかを示しています。最大限の運用価値を得るには、2 部構成で公開するとよいでしょう。パート 1 ではスクリーンショットと PoC 出力付きで攻撃チェーンを解説し、パート 2 ではセキュリティチームがすぐに実行可能な、簡潔な検知およびハードニングプレイブックを提供します。トークン衛生、ネットワーク分離、最小権限、堅牢なログ運用によって Runner を保護してください。
gitlab-runner-research の詳細やダウンロードはこちらから確認できます: https://github.com/Frichetten/gitlab-runner-research
Reader Interactions
