CircleCI Security
Last updated
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)
