Last updated
AWS ハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCP ハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
CircleCIは、コードに対して何をいつ行うかを示すテンプレートを定義できる継続的インテグレーションプラットフォームです。このようにして、例えばリポジトリのマスターブランチから直接テストやデプロイを自動化できます。
CircleCIは、ログインしているアカウントに関連するgithubおよびbitbucketから権限を継承します。 私のテストでは、githubのリポジトリに対する書き込み権限があれば、CircleCIでプロジェクト設定を管理できることを確認しました（新しいsshキーの設定、プロジェクトAPIキーの取得、新しいCircleCI設定での新しいブランチの作成など）。
ただし、CircleCIプロジェクトにリポジトリを変換するには、リポジトリ管理者である必要があります。
ドキュメントによると、ワークフロー内で環境変数に値をロードする方法はいくつかあります。
CircleCIによって実行されるすべてのコンテナには、CIRCLE_PR_USERNAME、CIRCLE_PROJECT_REPONAME、CIRCLE_USERNAMEなどのドキュメントに定義された特定の環境変数が常にあります。
コマンド内でプレーンテキストとして宣言できます：
実行環境内に明示的に宣言できます：
build-job 環境内に明示的に宣言できます：
コンテナの環境内に明示的に宣言できます：
これらは秘密であり、プロジェクト（任意のブランチ）によってのみアクセス可能です。 これらは https://app.circleci.com/settings/project/github/<org_name>/<repo_name>/environment-variables に宣言されているのを見ることができます。
「変数のインポート」機能を使用すると、他のプロジェクトから変数をインポートできます。
これらは組織全体の秘密です。デフォルトでは、任意のリポジトリがここに保存された秘密にアクセスできるようになります：
ただし、異なるグループ（すべてのメンバーの代わりに）を選択して特定の人々にのみ秘密へのアクセスを与えることができます。 これは現在、秘密のセキュリティを向上させるための最良の方法の1つであり、すべての人がアクセスできるのではなく、一部の人だけがアクセスできるようにします。
VCS（例えばgithub）にアクセスできる場合、各リポジトリの各ブランチの .circleci/config.yml ファイルをチェックし、そこに保存されている潜在的なプレーンテキストの秘密を検索します。
コードをチェックすることで、各 .circleci/config.yml ファイルで使用されているすべての秘密の名前を見つけることができます。また、これらのファイルからコンテキスト名を取得するか、ウェブコンソールで確認できます： https://app.circleci.com/settings/organization/github/<org_name>/contexts。
すべてのプロジェクトおよびコンテキストの秘密を抽出するには、全体のgithub組織の中でたった1つのリポジトリに書き込みアクセスを持っていれば十分です（そしてあなたのアカウントはコンテキストにアクセスできる必要がありますが、デフォルトでは誰でもすべてのコンテキストにアクセスできます）。
「変数のインポート」機能を使用すると、他のプロジェクトから変数をインポートできます。したがって、攻撃者はすべてのリポジトリからすべてのプロジェクト変数をインポートし、その後すべてを一緒に抽出することができます。
すべてのプロジェクトの秘密は常にジョブの環境に設定されているため、envを呼び出してbase64で難読化するだけで、ワークフローのウェブログコンソールに秘密を抽出できます：
もしウェブコンソールにアクセスできないが、リポジトリにアクセスでき、CircleCIが使用されていることがわかっている場合は、毎分トリガーされるワークフローを作成し、外部アドレスに秘密を流出させることができます:
コンテキスト名を指定する必要があります（これによりプロジェクトシークレットも抽出されます）：
もしウェブコンソールにアクセスできないが、リポジトリにアクセスでき、CircleCIが使用されていることがわかっている場合、毎分トリガーされるワークフローを修正して、外部アドレスに秘密を流出させることができます:
新しい .circleci/config.yml をリポジトリに作成するだけでは circleci ビルドをトリガーするには不十分です。circleci コンソールでプロジェクトとして有効にする必要があります。
CircleCI は あなたのビルドを彼らのマシンまたはあなた自身のマシンで実行するオプションを提供します。 デフォルトでは、彼らのマシンは GCP にあり、最初は関連する情報を見つけることはできません。しかし、もし被害者が 自分のマシン（潜在的にはクラウド環境で）でタスクを実行している場合、興味深い情報が含まれたクラウドメタデータエンドポイントを見つけるかもしれません。
前の例ではすべてが Docker コンテナ内で起動されましたが、VM マシンを起動するように要求することもできます（異なるクラウド権限を持つ可能性があります）：
リモートDockerサービスへのアクセスを持つDockerコンテナでも:
CircleCIでユーザートークンを作成して、ユーザーのアクセスでAPIエンドポイントにアクセスすることが可能です。
https://app.circleci.com/settings/user/tokens
プロジェクトトークンを作成して、トークンに与えられた権限でプロジェクトにアクセスすることが可能です。
https://app.circleci.com/settings/project/github/<org>/<repo>/api
プロジェクトにSSHキーを追加することが可能です。
https://app.circleci.com/settings/project/github/<org>/<repo>/ssh
予期しないプロジェクトの隠れたブランチにcronジョブを作成して、毎日すべてのコンテキスト環境変数を漏洩させることが可能です。
あるいは、ブランチで作成または既知のジョブを修正して、毎日すべてのコンテキストとプロジェクトの秘密を漏洩させることが可能です。
GitHubのオーナーであれば、未確認のオーブを許可し、ジョブにバックドアとして設定することができます。
一部のタスクでコマンドインジェクションの脆弱性を見つけ、秘密の値を変更することでコマンドを注入することができます。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
