CircleCI Security
Last updated
Last updated
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
CircleCI è una piattaforma di Integrazione Continua dove puoi definire modelli che indicano cosa vuoi che faccia con del codice e quando farlo. In questo modo puoi automatizzare i test o le distribuzioni direttamente dal ramo master del tuo repo, per esempio.
CircleCI eredita i permessi da github e bitbucket relativi all'account che accede. Nei miei test ho verificato che finché hai permessi di scrittura sul repo in github, sarai in grado di gestire le impostazioni del progetto in CircleCI (impostare nuove chiavi ssh, ottenere chiavi api del progetto, creare nuovi rami con nuove configurazioni CircleCI...).
Tuttavia, devi essere un admin del repo per convertire il repo in un progetto CircleCI.
Secondo la documentazione ci sono diversi modi per caricare valori nelle variabili di ambiente all'interno di un workflow.
Ogni container eseguito da CircleCI avrà sempre variabili di ambiente specifiche definite nella documentazione come CIRCLE_PR_USERNAME, CIRCLE_PROJECT_REPONAME o CIRCLE_USERNAME.
Puoi dichiararle in testo chiaro all'interno di un comando:
Puoi dichiararli in testo chiaro all'interno dell'ambiente di esecuzione:
Puoi dichiararli in testo chiaro all'interno dell'ambiente build-job:
Puoi dichiararli in testo chiaro all'interno dell'ambiente di un contenitore:
Questi sono segreti che saranno accessibili solo dal progetto (da qualsiasi ramo). Puoi vederli dichiarati in https://app.circleci.com/settings/project/github/<org_name>/<repo_name>/environment-variables
La funzionalità "Importa Variabili" consente di importare variabili da altri progetti a questo.
Questi sono segreti che sono a livello di org. Per default, qualsiasi repo sarà in grado di accedere a qualsiasi segreto memorizzato qui:
Tuttavia, nota che un gruppo diverso (invece di Tutti i membri) può essere selezionato per dare accesso ai segreti solo a persone specifiche. Questo è attualmente uno dei migliori modi per aumentare la sicurezza dei segreti, per non consentire a tutti di accedervi ma solo ad alcune persone.
Se hai accesso al VCS (come github) controlla il file .circleci/config.yml di ogni repo su ogni ramo e cerca potenziali segreti in testo chiaro memorizzati lì.
Controllando il codice puoi trovare tutti i nomi dei segreti che vengono utilizzati in ciascun file .circleci/config.yml. Puoi anche ottenere i nomi dei contesti da quei file o controllarli nella console web: https://app.circleci.com/settings/organization/github/<org_name>/contexts.
Per esfiltrare TUTTI i SECRETI del progetto e del contesto, hai solo bisogno di avere accesso SCRITTURA a solo 1 repo nell'intera org di github (e il tuo account deve avere accesso ai contesti, ma per default tutti possono accedere a ogni contesto).
La funzionalità "Importa Variabili" consente di importare variabili da altri progetti a questo. Pertanto, un attaccante potrebbe importare tutte le variabili del progetto da tutti i repo e poi esfiltrare tutte insieme.
Tutti i segreti del progetto sono sempre impostati nell'env dei lavori, quindi basta chiamare env e offuscarlo in base64 per esfiltrare i segreti nella console del log web dei flussi di lavoro:
Se non hai accesso alla console web ma hai accesso al repo e sai che CircleCI è utilizzato, puoi semplicemente creare un workflow che viene attivato ogni minuto e che esfiltra i segreti a un indirizzo esterno:
Devi specificare il nome del contesto (questo esfiltrerà anche i segreti del progetto):
Se non hai accesso alla console web ma hai accesso al repo e sai che CircleCI è utilizzato, puoi semplicemente modificare un workflow che viene attivato ogni minuto e che esfiltra i segreti a un indirizzo esterno:
Creare un nuovo .circleci/config.yml in un repo non è sufficiente per attivare una build di circleci. Devi abilitarlo come progetto nella console di circleci.
CircleCI ti offre l'opzione di eseguire le tue build sulle loro macchine o sulle tue. Per impostazione predefinita, le loro macchine si trovano in GCP, e inizialmente non sarai in grado di trovare nulla di rilevante. Tuttavia, se una vittima sta eseguendo i compiti sulle proprie macchine (potenzialmente, in un ambiente cloud), potresti trovare un endpoint di metadati cloud con informazioni interessanti.
Nota che negli esempi precedenti è stato lanciato tutto all'interno di un contenitore docker, ma puoi anche richiedere di avviare una macchina VM (che potrebbe avere permessi cloud diversi):
O anche un container docker con accesso a un servizio docker remoto:
È possibile creare token utente in CircleCI per accedere agli endpoint API con l'accesso degli utenti.
https://app.circleci.com/settings/user/tokens
È possibile creare token di progetto per accedere al progetto con i permessi dati al token.
https://app.circleci.com/settings/project/github/<org>/<repo>/api
È possibile aggiungere chiavi SSH ai progetti.
https://app.circleci.com/settings/project/github/<org>/<repo>/ssh
È possibile creare un cron job in un ramo nascosto in un progetto inaspettato che leak tutte le variabili context env ogni giorno.
O addirittura creare in un ramo / modificare un lavoro noto che leak tutti i segreti context e progetti ogni giorno.
Se sei un proprietario di github puoi consentire orbs non verificati e configurarne uno in un lavoro come backdoor.
Puoi trovare una vulnerabilità di command injection in alcuni task e iniettare comandi tramite un segreto modificando il suo valore.
