Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
CircleCI é uma plataforma de Integração Contínua onde você pode definir templates indicando o que deseja que ela faça com algum código e quando fazê-lo. Dessa forma, você pode automatizar testes ou implantações diretamente da sua branch principal do repositório, por exemplo.
CircleCI herda as permissões do github e bitbucket relacionadas à conta que faz login. Nos meus testes, verifiquei que, desde que você tenha permissões de escrita sobre o repositório no github, você poderá gerenciar as configurações do projeto no CircleCI (definir novas chaves ssh, obter chaves de api do projeto, criar novas branches com novas configurações do CircleCI...).
No entanto, você precisa ser um administrador do repositório para converter o repositório em um projeto CircleCI.
De acordo com a documentação, existem diferentes maneiras de carregar valores em variáveis de ambiente dentro de um fluxo de trabalho.
Todo container executado pelo CircleCI sempre terá variáveis de ambiente específicas definidas na documentação como CIRCLE_PR_USERNAME, CIRCLE_PROJECT_REPONAME ou CIRCLE_USERNAME.
Você pode declará-las em texto claro dentro de um comando:
Você pode declará-los em texto claro dentro do run environment:
Você pode declará-los em texto claro dentro do build-job environment:
Você pode declará-los em texto claro dentro do ambiente de um contêiner:
Estes são segredos que só estarão acessíveis pelo projeto (por qualquer branch). Você pode vê-los declarados em https://app.circleci.com/settings/project/github/<org_name>/<repo_name>/environment-variables
A funcionalidade "Importar Variáveis" permite importar variáveis de outros projetos para este.
Estes são segredos que são ampla organização. Por padrão, qualquer repositório poderá acessar qualquer segredo armazenado aqui:
No entanto, observe que um grupo diferente (em vez de Todos os membros) pode ser selecionado para dar acesso aos segredos apenas a pessoas específicas. Esta é atualmente uma das melhores maneiras de aumentar a segurança dos segredos, para não permitir que todos tenham acesso a eles, mas apenas algumas pessoas.
Se você tiver acesso ao VCS (como github), verifique o arquivo .circleci/config.yml de cada repositório em cada branch e busque por potenciais segredos em texto claro armazenados lá.
Verificando o código, você pode encontrar todos os nomes dos segredos que estão sendo usados em cada arquivo .circleci/config.yml. Você também pode obter os nomes dos contextos desses arquivos ou verificá-los no console da web: https://app.circleci.com/settings/organization/github/<org_name>/contexts.
Para exfiltrar TODOS os SEGREDOS do projeto e do contexto, você apenas precisa ter acesso DE ESCRITA a apenas 1 repositório em toda a organização do github (e sua conta deve ter acesso aos contextos, mas por padrão todos podem acessar todos os contextos).
A funcionalidade "Importar Variáveis" permite importar variáveis de outros projetos para este. Portanto, um atacante poderia importar todas as variáveis do projeto de todos os repositórios e então exfiltrar todas elas juntas.
Todos os segredos do projeto sempre são definidos no ambiente dos jobs, então apenas chamando env e ofuscando-o em base64 irá exfiltrar os segredos no console de log da web dos workflows:
Se você não tem acesso ao console da web mas tem acesso ao repositório e sabe que o CircleCI é usado, você pode simplesmente criar um fluxo de trabalho que é disparado a cada minuto e que exfiltra os segredos para um endereço externo:
Você precisa especificar o nome do contexto (isso também irá exfiltrar os segredos do projeto):
Se você não tem acesso ao console da web mas tem acesso ao repositório e sabe que o CircleCI é usado, você pode simplesmente modificar um fluxo de trabalho que é disparado a cada minuto e que exfiltra os segredos para um endereço externo:
Apenas criar um novo .circleci/config.yml em um repositório não é suficiente para acionar uma construção do circleci. Você precisa habilitá-lo como um projeto no console do circleci.
CircleCI oferece a opção de executar suas construções em suas máquinas ou em suas próprias. Por padrão, suas máquinas estão localizadas no GCP, e inicialmente você não conseguirá encontrar nada relevante. No entanto, se uma vítima estiver executando as tarefas em suas próprias máquinas (potencialmente, em um ambiente de nuvem), você pode encontrar um endpoint de metadados da nuvem com informações interessantes.
Observe que nos exemplos anteriores tudo foi lançado dentro de um contêiner docker, mas você também pode pedir para lançar uma máquina VM (que pode ter permissões de nuvem diferentes):
Ou até mesmo um contêiner docker com acesso a um serviço docker remoto:
É possível criar tokens de usuário no CircleCI para acessar os endpoints da API com o acesso dos usuários.
https://app.circleci.com/settings/user/tokens
É possível criar tokens de projetos para acessar o projeto com as permissões dadas ao token.
https://app.circleci.com/settings/project/github/<org>/<repo>/api
É possível adicionar chaves SSH aos projetos.
https://app.circleci.com/settings/project/github/<org>/<repo>/ssh
É possível criar um cron job em uma branch oculta em um projeto inesperado que está vazando todas as variáveis de contexto env todos os dias.
Ou até mesmo criar em uma branch / modificar um job conhecido que irá vazar todo o contexto e os segredos dos projetos todos os dias.
Se você for um proprietário do github, pode permitir orbs não verificados e configurar um em um job como backdoor.
Você pode encontrar uma vulnerabilidade de injeção de comando em alguma tarefa e injetar comandos via um segredo modificando seu valor.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
