CircleCI Security
基本情報
CircleCI は、何を行い、いつ行うかを示すテンプレートを定義できる継続的インテグレーションプラットフォームです。これにより、テストを自動化したり、リポジトリのマスターブランチから直接デプロイしたりできます。
権限
CircleCI は、ログインしている アカウント に関連する github と bitbucket から権限を継承します。 私のテストでは、github のリポジトリに 書き込み権限 がある限り、CircleCI のプロジェクト設定を管理できることを確認しました(新しい ssh キーを設定したり、プロジェクト api キーを取得したり、新しい CircleCI 設定を持つ新しいブランチを作成したり...)。
ただし、リポジトリを CircleCI プロジェクトに変換するには、リポジトリの管理者である必要があります。
環境変数とシークレット
ドキュメントによると、ワークフロー内で環境変数に値をロードするための異なる方法があります。
組み込み環境変数
CircleCI によって実行されるすべてのコンテナには、常にドキュメントで定義された特定の環境変数が含まれます。例: CIRCLE_PR_USERNAME
, CIRCLE_PROJECT_REPONAME
, CIRCLE_USERNAME
。
平文
コマンド内で平文で宣言することができます。
run environment 内で明確なテキストで宣言することができます。
build-job environment 内で明確なテキストで宣言することができます。
コンテナの環境内で明確なテキストで宣言することができます。
プロジェクトの秘密
これらはプロジェクトによってのみアクセス可能な秘密です(どのブランチでも)。 これらは_https://app.circleci.com/settings/project/github/<org_name>/<repo_name>/environment-variables_で宣言されているのを見ることができます。
"Import Variables"機能を使用すると、他のプロジェクトからこのプロジェクトに変数をインポートできます。
コンテキストの秘密
これらは組織全体で共有される秘密です。デフォルトではどのリポジトリもここに保存された秘密にアクセスできます。
ただし、異なるグループ(すべてのメンバーの代わりに)を選択して、特定の人にのみ秘密へのアクセス権を与えることができます。 これは現在、秘密のセキュリティを向上させる最良の方法の1つであり、誰もがアクセスできるのではなく、一部の人だけがアクセスできるようにします。
攻撃
明文テキストの秘密を検索
VCS(githubなど)へのアクセスがある場合、各リポジトリの各ブランチの.circleci/config.yml
ファイルをチェックし、そこに保存されている潜在的な明文テキストの秘密を検索します。
Secret Env Vars&コンテキストの列挙
コードをチェックすると、各.circleci/config.yml
ファイルで使用されているすべての秘密の名前を見つけることができます。また、これらのファイルからコンテキストの名前を取得するか、Webコンソールで確認できます:https://app.circleci.com/settings/organization/github/<org_name>/contexts。
プロジェクトの秘密を外部流出
プロジェクトとコンテキストのすべての秘密を外部流出するには、github組織全体の1つのリポジトリに書き込みアクセスが必要です(そしてあなたのアカウントはデフォルトで誰もがすべてのコンテキストにアクセスできるようにする必要があります)。
"Import Variables"機能を使用すると、他のプロジェクトからこのプロジェクトに変数をインポートできます。したがって、攻撃者はすべてのリポジトリからすべてのプロジェクト変数をインポートし、それらを一緒に外部流出することができます。
すべてのプロジェクトの秘密は常にジョブの環境に設定されているため、envを呼び出してそれをbase64で難読化するだけで、秘密がワークフローのWebログコンソールに外部流出します:
もし webコンソールにアクセスできない が リポジトリにアクセスでき 、CircleCIが使用されていることを知っている場合は、単に 1分ごとにトリガーされるワークフロー を 作成して、シークレットを外部アドレスに持ち出すことができます:
コンテキストのシークレットを外部に流出させる
コンテキスト名を指定する必要があります(これによりプロジェクトのシークレットも外部に流出します):
もしWebコンソールにアクセスできないが、リポジトリにアクセスでき、CircleCIが使用されていることを知っている場合、1分ごとにトリガーされるワークフローを変更して、シークレットを外部アドレスに送信することができます。
新しい.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
予期しないプロジェクトの隠しブランチにクロンジョブを作成して、毎日すべてのコンテキスト環境変数を漏洩させることが可能です。
または、既知のジョブをブランチに作成/変更して、毎日すべてのコンテキストとプロジェクトのシークレットを漏洩させることが可能です。
GitHubの所有者であれば、未検証のorbを許可し、ジョブでバックドアとして構成することが可能です。
特定のタスクでコマンドインジェクションの脆弱性を見つけ、その値を変更してシークレットを注入することが可能です。
Last updated