Linux Capabilities
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON è l'evento di cybersecurity più rilevante in Spagna e uno dei più importanti in Europa. Con la missione di promuovere la conoscenza tecnica, questo congresso è un punto di incontro fervente per professionisti della tecnologia e della cybersecurity in ogni disciplina.\
Linux Capabilities
Le capacità di Linux dividono i privilegi di root in unità più piccole e distinte, consentendo ai processi di avere un sottoinsieme di privilegi. Questo riduce i rischi non concedendo inutilmente pieni privilegi di root.
Il Problema:
Gli utenti normali hanno permessi limitati, influenzando compiti come l'apertura di un socket di rete che richiede accesso root.
Insiemi di Capacità:
Inherited (CapInh):
Scopo: Determina le capacità trasferite dal processo padre.
Funzionalità: Quando viene creato un nuovo processo, eredita le capacità dal suo genitore in questo insieme. Utile per mantenere determinati privilegi attraverso le generazioni di processi.
Restrizioni: Un processo non può acquisire capacità che il suo genitore non possedeva.
Effective (CapEff):
Scopo: Rappresenta le capacità effettive che un processo sta utilizzando in qualsiasi momento.
Funzionalità: È l'insieme di capacità controllato dal kernel per concedere permessi per varie operazioni. Per i file, questo insieme può essere un flag che indica se le capacità consentite del file devono essere considerate effettive.
Significato: L'insieme effettivo è cruciale per i controlli immediati dei privilegi, fungendo da insieme attivo di capacità che un processo può utilizzare.
Permitted (CapPrm):
Scopo: Definisce il massimo insieme di capacità che un processo può possedere.
Funzionalità: Un processo può elevare una capacità dall'insieme permesso al suo insieme effettivo, dandogli la possibilità di utilizzare quella capacità. Può anche rinunciare a capacità dal suo insieme permesso.
Limite: Funziona come un limite superiore per le capacità che un processo può avere, assicurando che un processo non superi il suo ambito di privilegi predefinito.
Bounding (CapBnd):
Scopo: Impone un tetto sulle capacità che un processo può mai acquisire durante il suo ciclo di vita.
Funzionalità: Anche se un processo ha una certa capacità nel suo insieme ereditabile o permesso, non può acquisire quella capacità a meno che non sia anche nell'insieme di bounding.
Caso d'uso: Questo insieme è particolarmente utile per limitare il potenziale di escalation dei privilegi di un processo, aggiungendo un ulteriore livello di sicurezza.
Ambient (CapAmb):
Scopo: Consente a determinate capacità di essere mantenute attraverso una chiamata di sistema
execve
, che normalmente comporterebbe un ripristino completo delle capacità del processo.Funzionalità: Garantisce che i programmi non-SUID che non hanno capacità di file associate possano mantenere determinati privilegi.
Restrizioni: Le capacità in questo insieme sono soggette ai vincoli degli insiemi ereditabili e permessi, assicurando che non superino i privilegi consentiti del processo.
Per ulteriori informazioni controlla:
Capacità dei Processi e dei Binaries
Capacità dei Processi
Per vedere le capacità di un particolare processo, usa il file status nella directory /proc. Poiché fornisce più dettagli, limitiamolo solo alle informazioni relative alle capacità di Linux. Nota che per tutti i processi in esecuzione, le informazioni sulle capacità sono mantenute per thread, mentre per i binaries nel file system sono memorizzate in attributi estesi.
Puoi trovare le capacità definite in /usr/include/linux/capability.h
Puoi trovare le capacità del processo corrente in cat /proc/self/status
o eseguendo capsh --print
e di altri utenti in /proc/<pid>/status
Questo comando dovrebbe restituire 5 righe sulla maggior parte dei sistemi.
CapInh = Capacità ereditate
CapPrm = Capacità consentite
CapEff = Capacità effettive
CapBnd = Insieme di limitazione
CapAmb = Insieme di capacità ambientali
Questi numeri esadecimali non hanno senso. Utilizzando l'utilità capsh possiamo decodificarli nei nomi delle capacità.
Controlliamo ora le capabilities utilizzate da ping
:
Sebbene funzioni, c'è un altro modo più semplice. Per vedere le capacità di un processo in esecuzione, utilizza semplicemente lo strumento getpcaps seguito dal suo ID processo (PID). Puoi anche fornire un elenco di ID processo.
Controlliamo qui le capacità di tcpdump
dopo aver dato al binario sufficienti capacità (cap_net_admin
e cap_net_raw
) per sniffare la rete (tcpdump è in esecuzione nel processo 9562):
Come puoi vedere, le capacità fornite corrispondono ai risultati dei 2 modi per ottenere le capacità di un binario. Lo strumento getpcaps utilizza la chiamata di sistema capget() per interrogare le capacità disponibili per un particolare thread. Questa chiamata di sistema ha solo bisogno di fornire il PID per ottenere ulteriori informazioni.
Capacità dei Binaries
I binaries possono avere capacità che possono essere utilizzate durante l'esecuzione. Ad esempio, è molto comune trovare il binario ping
con la capacità cap_net_raw
:
Puoi cercare i binari con capacità utilizzando:
Dropping capabilities with capsh
Se rimuoviamo le capacità CAP_NET_RAW per ping, allora l'utilità ping non dovrebbe più funzionare.
Oltre all'output di capsh stesso, anche il comando tcpdump dovrebbe sollevare un errore.
/bin/bash: /usr/sbin/tcpdump: Operazione non consentita
L'errore mostra chiaramente che il comando ping non è autorizzato ad aprire un socket ICMP. Ora sappiamo con certezza che questo funziona come previsto.
Rimuovere le capacità
Puoi rimuovere le capacità di un binario con
User Capabilities
Apparentemente è possibile assegnare capacità anche agli utenti. Questo probabilmente significa che ogni processo eseguito dall'utente sarà in grado di utilizzare le capacità degli utenti.
Basato su questo, questo e questo alcuni file devono essere configurati per dare a un utente determinate capacità, ma quello che assegna le capacità a ciascun utente sarà /etc/security/capability.conf
.
Esempio di file:
Capacità dell'Ambiente
Compilando il seguente programma è possibile generare una shell bash all'interno di un ambiente che fornisce capacità.
All'interno del bash eseguito dal binario ambientale compilato è possibile osservare le nuove capacità (un utente normale non avrà alcuna capacità nella sezione "corrente").
Puoi aggiungere solo le capacità che sono presenti sia nel set permesso che in quello ereditabile.
Binaries consapevoli delle capacità/Binaries non consapevoli delle capacità
I binaries consapevoli delle capacità non utilizzeranno le nuove capacità fornite dall'ambiente, tuttavia i binaries non consapevoli delle capacità le utilizzeranno poiché non le rifiuteranno. Questo rende i binaries non consapevoli delle capacità vulnerabili all'interno di un ambiente speciale che concede capacità ai binaries.
Capacità del servizio
Per impostazione predefinita, un servizio in esecuzione come root avrà assegnate tutte le capacità, e in alcune occasioni questo può essere pericoloso. Pertanto, un file di configurazione del servizio consente di specificare le capacità che si desidera che abbia, e l'utente che dovrebbe eseguire il servizio per evitare di eseguire un servizio con privilegi non necessari:
Capabilities in Docker Containers
Per impostazione predefinita, Docker assegna alcune capacità ai contenitori. È molto facile controllare quali sono queste capacità eseguendo:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON è l'evento di cybersecurity più rilevante in Spagna e uno dei più importanti in Europa. Con la missione di promuovere la conoscenza tecnica, questo congresso è un punto di incontro vivace per professionisti della tecnologia e della cybersecurity in ogni disciplina.
Privesc/Container Escape
Le capacità sono utili quando vuoi limitare i tuoi stessi processi dopo aver eseguito operazioni privilegiate (ad es. dopo aver impostato chroot e collegato a un socket). Tuttavia, possono essere sfruttate passando loro comandi o argomenti malevoli che vengono poi eseguiti come root.
Puoi forzare le capacità sui programmi usando setcap
, e interrogarle usando getcap
:
Il +ep
significa che stai aggiungendo la capacità (“-” la rimuoverebbe) come Efficace e Permessa.
Per identificare i programmi in un sistema o in una cartella con capacità:
Esempio di sfruttamento
Nell'esempio seguente, il binario /usr/bin/python2.6
è stato trovato vulnerabile a privesc:
Capabilities necessarie per tcpdump
per consentire a qualsiasi utente di sniffare pacchetti:
Il caso speciale delle capacità "vuote"
Dal documento: Nota che è possibile assegnare set di capacità vuoti a un file di programma, e quindi è possibile creare un programma set-user-ID-root che cambia il set-user-ID effettivo e salvato del processo che esegue il programma a 0, ma non conferisce alcuna capacità a quel processo. O, in altre parole, se hai un binario che:
non è di proprietà di root
non ha bit
SUID
/SGID
impostatiha set di capacità vuoti (ad es.:
getcap myelf
restituiscemyelf =ep
)
allora quel binario verrà eseguito come root.
CAP_SYS_ADMIN
CAP_SYS_ADMIN
è una capacità Linux altamente potente, spesso equiparata a un livello quasi root a causa dei suoi ampi privilegi amministrativi, come il montaggio di dispositivi o la manipolazione delle funzionalità del kernel. Sebbene sia indispensabile per i container che simulano interi sistemi, CAP_SYS_ADMIN
presenta sfide di sicurezza significative, specialmente negli ambienti containerizzati, a causa del suo potenziale per l'escalation dei privilegi e il compromesso del sistema. Pertanto, il suo utilizzo richiede valutazioni di sicurezza rigorose e una gestione cauta, con una forte preferenza per la rimozione di questa capacità nei container specifici per le applicazioni per aderire al principio del minimo privilegio e ridurre la superficie di attacco.
Esempio con binario
Utilizzando python, puoi montare un file passwd modificato sopra il vero file passwd:
E infine montare il file passwd
modificato su /etc/passwd
:
E sarai in grado di su
come root utilizzando la password "password".
Esempio con ambiente (Docker breakout)
Puoi controllare le capacità abilitate all'interno del contenitore docker usando:
Dentro l'output precedente puoi vedere che la capacità SYS_ADMIN è abilitata.
Mount
Questo consente al container docker di montare il disco host e accedervi liberamente:
Accesso completo
Nel metodo precedente siamo riusciti ad accedere al disco dell'host docker. Nel caso in cui tu trovi che l'host sta eseguendo un server ssh, potresti creare un utente all'interno del disco dell'host docker e accedervi tramite SSH:
CAP_SYS_PTRACE
Questo significa che puoi sfuggire al container iniettando un shellcode all'interno di un processo in esecuzione all'interno dell'host. Per accedere ai processi in esecuzione all'interno dell'host, il container deve essere eseguito almeno con --pid=host
.
CAP_SYS_PTRACE
concede la possibilità di utilizzare le funzionalità di debug e tracciamento delle chiamate di sistema fornite da ptrace(2)
e chiamate di attacco alla memoria incrociata come process_vm_readv(2)
e process_vm_writev(2)
. Sebbene sia potente per scopi diagnostici e di monitoraggio, se CAP_SYS_PTRACE
è abilitato senza misure restrittive come un filtro seccomp su ptrace(2)
, può compromettere significativamente la sicurezza del sistema. In particolare, può essere sfruttato per eludere altre restrizioni di sicurezza, in particolare quelle imposte da seccomp, come dimostrato da prove di concetto (PoC) come questa.
Esempio con binario (python)
Esempio con binario (gdb)
gdb
con capacità ptrace
:
Crea uno shellcode con msfvenom da iniettare in memoria tramite gdb
Debugga un processo root con gdb e copia-incolla le righe gdb generate in precedenza:
Esempio con ambiente (Docker breakout) - Un altro abuso di gdb
Se GDB è installato (o puoi installarlo con apk add gdb
o apt install gdb
per esempio) puoi debuggare un processo dall'host e farlo chiamare la funzione system
. (Questa tecnica richiede anche la capacità SYS_ADMIN
).
Non sarai in grado di vedere l'output del comando eseguito, ma verrà eseguito da quel processo (quindi ottieni una rev shell).
Se ricevi l'errore "Nessun simbolo "system" nel contesto attuale.", controlla l'esempio precedente che carica uno shellcode in un programma tramite gdb.
Esempio con ambiente (Docker breakout) - Iniezione di Shellcode
Puoi controllare le capacità abilitate all'interno del container docker usando:
List processi in esecuzione nell'host ps -eaf
Ottieni l'architettura
uname -m
Trova un shellcode per l'architettura (https://www.exploit-db.com/exploits/41128)
Trova un programma per iniettare il shellcode nella memoria di un processo (https://github.com/0x00pf/0x00sec_code/blob/master/mem_inject/infect.c)
Modifica il shellcode all'interno del programma e compila
gcc inject.c -o inject
Inietta e prendi la tua shell:
./inject 299; nc 172.17.0.1 5600
CAP_SYS_MODULE
CAP_SYS_MODULE
consente a un processo di caricare e scaricare moduli del kernel (init_module(2)
, finit_module(2)
e delete_module(2)
chiamate di sistema), offrendo accesso diretto alle operazioni fondamentali del kernel. Questa capacità presenta rischi critici per la sicurezza, poiché consente l'escalation dei privilegi e il compromesso totale del sistema permettendo modifiche al kernel, eludendo così tutti i meccanismi di sicurezza di Linux, inclusi i Linux Security Modules e l'isolamento dei container.
Questo significa che puoi inserire/rimuovere moduli del kernel nel/dal kernel della macchina host.
Esempio con binario
Nell'esempio seguente il binario python
ha questa capacità.
Per impostazione predefinita, il comando modprobe
controlla l'elenco delle dipendenze e i file di mappatura nella directory /lib/modules/$(uname -r)
.
Per sfruttare questo, creiamo una cartella falsa lib/modules:
Poi compila il modulo del kernel che puoi trovare 2 esempi qui sotto e copialo in questa cartella:
Infine, esegui il codice python necessario per caricare questo modulo del kernel:
Esempio 2 con binario
Nell'esempio seguente, il binario kmod
ha questa capacità.
Il che significa che è possibile utilizzare il comando insmod
per inserire un modulo del kernel. Segui l'esempio qui sotto per ottenere una reverse shell abusando di questo privilegio.
Esempio con ambiente (Docker breakout)
Puoi controllare le capacità abilitate all'interno del contenitore docker usando:
Dentro dell'output precedente puoi vedere che la capacità SYS_MODULE è abilitata.
Crea il modulo del kernel che eseguirà una reverse shell e il Makefile per compilarlo:
Il carattere vuoto prima di ogni parola make nel Makefile deve essere una tabulazione, non spazi!
Esegui make
per compilarlo.
Infine, avvia nc
all'interno di una shell e carica il modulo da un'altra e catturerai la shell nel processo nc:
Il codice di questa tecnica è stato copiato dal laboratorio di "Abusing SYS_MODULE Capability" da https://www.pentesteracademy.com/
Un altro esempio di questa tecnica può essere trovato in https://www.cyberark.com/resources/threat-research-blog/how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host
CAP_DAC_READ_SEARCH
CAP_DAC_READ_SEARCH consente a un processo di bypassare i permessi per la lettura dei file e per la lettura e l'esecuzione delle directory. Il suo utilizzo principale è per la ricerca o la lettura di file. Tuttavia, consente anche a un processo di utilizzare la funzione open_by_handle_at(2)
, che può accedere a qualsiasi file, inclusi quelli al di fuori dello spazio dei nomi di montaggio del processo. L'identificatore utilizzato in open_by_handle_at(2)
dovrebbe essere un identificatore non trasparente ottenuto tramite name_to_handle_at(2)
, ma può includere informazioni sensibili come i numeri degli inode che sono vulnerabili a manomissioni. Il potenziale di sfruttamento di questa capacità, in particolare nel contesto dei contenitori Docker, è stato dimostrato da Sebastian Krahmer con l'exploit shocker, come analizzato qui. Questo significa che puoi bypassare i controlli dei permessi di lettura dei file e i controlli dei permessi di lettura/esecuzione delle directory.
Esempio con binario
Il binario sarà in grado di leggere qualsiasi file. Quindi, se un file come tar ha questa capacità, sarà in grado di leggere il file shadow:
Esempio con binary2
In questo caso supponiamo che il binario python
abbia questa capacità. Per elencare i file di root potresti fare:
E per leggere un file potresti fare:
Esempio nell'ambiente (Docker breakout)
Puoi controllare le capacità abilitate all'interno del container docker usando:
Dentro l'output precedente puoi vedere che la capacità DAC_READ_SEARCH è abilitata. Di conseguenza, il container può debuggare i processi.
Puoi imparare come funziona il seguente exploit in https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3 ma in sintesi CAP_DAC_READ_SEARCH non solo ci consente di attraversare il file system senza controlli di autorizzazione, ma rimuove anche esplicitamente eventuali controlli su open_by_handle_at(2) e potrebbe consentire al nostro processo di accedere a file sensibili aperti da altri processi.
L'exploit originale che sfrutta queste autorizzazioni per leggere file dall'host può essere trovato qui: http://stealth.openwall.net/xSports/shocker.c, il seguente è una versione modificata che ti consente di indicare il file che desideri leggere come primo argomento e di scaricarlo in un file.
L'exploit deve trovare un puntatore a qualcosa montato sull'host. L'exploit originale utilizzava il file /.dockerinit e questa versione modificata utilizza /etc/hostname. Se l'exploit non funziona, potrebbe essere necessario impostare un file diverso. Per trovare un file montato nell'host, esegui semplicemente il comando mount:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F197708944-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FE5VfhVAq0qYsgU9deMR8%252Fuploads%252Fgit-blob-e8bf27d92631c9009d2613b4bac9f501b6290062%252Fimage%2520%28407%29%2520%281%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=52f58166&sv=1)
Il codice di questa tecnica è stato copiato dal laboratorio di "Abusing DAC_READ_SEARCH Capability" da https://www.pentesteracademy.com/
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON è l'evento di cybersecurity più rilevante in Spagna e uno dei più importanti in Europa. Con la missione di promuovere la conoscenza tecnica, questo congresso è un punto di incontro vivace per professionisti della tecnologia e della cybersecurity in ogni disciplina.
CAP_DAC_OVERRIDE
Questo significa che puoi bypassare i controlli dei permessi di scrittura su qualsiasi file, quindi puoi scrivere qualsiasi file.
Ci sono molti file che puoi sovrascrivere per elevare i privilegi, puoi prendere spunti da qui.
Esempio con binario
In questo esempio vim ha questa capacità, quindi puoi modificare qualsiasi file come passwd, sudoers o shadow:
Esempio con binario 2
In questo esempio, il binario python
avrà questa capacità. Potresti usare python per sovrascrivere qualsiasi file:
Esempio con ambiente + CAP_DAC_READ_SEARCH (Docker breakout)
Puoi controllare le capacità abilitate all'interno del contenitore docker usando:
Prima di tutto, leggi la sezione precedente che abusa della capacità DAC_READ_SEARCH per leggere file arbitrari dell'host e compila l'exploit. Poi, compila la seguente versione dell'exploit shocker che ti permetterà di scrivere file arbitrari all'interno del filesystem degli host:
Per scappare dal container docker, potresti scaricare i file /etc/shadow
e /etc/passwd
dall'host, aggiungere a essi un nuovo utente e usare shocker_write
per sovrascriverli. Poi, accedere tramite ssh.
Il codice di questa tecnica è stato copiato dal laboratorio di "Abusing DAC_OVERRIDE Capability" da https://www.pentesteracademy.com
CAP_CHOWN
Questo significa che è possibile cambiare la proprietà di qualsiasi file.
Esempio con binario
Supponiamo che il python
binario abbia questa capacità, puoi cambiare il proprietario del file shadow, cambiare la password di root e ottenere privilegi elevati:
O con il ruby
binario che ha questa capacità:
CAP_FOWNER
Questo significa che è possibile modificare i permessi di qualsiasi file.
Esempio con binario
Se python ha questa capacità, puoi modificare i permessi del file shadow, cambiare la password di root e aumentare i privilegi:
CAP_SETUID
Questo significa che è possibile impostare l'ID utente efficace del processo creato.
Esempio con binario
Se python ha questa capability, puoi abusarne molto facilmente per elevare i privilegi a root:
Un altro modo:
CAP_SETGID
Questo significa che è possibile impostare l'ID di gruppo efficace del processo creato.
Ci sono molti file che puoi sovrascrivere per aumentare i privilegi, puoi prendere spunti da qui.
Esempio con binario
In questo caso dovresti cercare file interessanti che un gruppo può leggere perché puoi impersonare qualsiasi gruppo:
Una volta trovato un file che puoi sfruttare (tramite lettura o scrittura) per elevare i privilegi, puoi ottenere una shell impersonando il gruppo interessante con:
In questo caso il gruppo shadow è stato impersonato, quindi puoi leggere il file /etc/shadow
:
Se docker è installato, puoi impostare il gruppo docker e abusarne per comunicare con il docker socket e aumentare i privilegi.
CAP_SETFCAP
Questo significa che è possibile impostare capacità su file e processi
Esempio con binario
Se python ha questa capacità, puoi abusarne molto facilmente per aumentare i privilegi a root:
Nota che se imposti una nuova capacità al binario con CAP_SETFCAP, perderai questa capacità.
Una volta che hai la capacità SETUID puoi andare alla sua sezione per vedere come elevare i privilegi.
Esempio con ambiente (Docker breakout)
Per impostazione predefinita, la capacità CAP_SETFCAP è assegnata al processo all'interno del contenitore in Docker. Puoi verificarlo facendo qualcosa come:
Questa capacità consente di dare qualsiasi altra capacità ai binari, quindi potremmo pensare a sfuggire dal contenitore abusando di una delle altre violazioni di capacità menzionate in questa pagina. Tuttavia, se provi a dare ad esempio le capacità CAP_SYS_ADMIN e CAP_SYS_PTRACE al binario gdb, scoprirai che puoi darle, ma il binario non sarà in grado di eseguire dopo questo:
From the docs: Permitted: Questo è un sottoinsieme limitante per le capacità effettive che il thread può assumere. È anche un sottoinsieme limitante per le capacità che possono essere aggiunte al set ereditabile da un thread che non ha la capacità CAP_SETPCAP nel suo set effettivo. Sembra che le capacità Permitted limitino quelle che possono essere utilizzate. Tuttavia, Docker concede anche il CAP_SETPCAP per impostazione predefinita, quindi potresti essere in grado di impostare nuove capacità all'interno di quelle ereditabili. Tuttavia, nella documentazione di questa capacità: CAP_SETPCAP : […] aggiungi qualsiasi capacità dal set di bounding del thread chiamante al suo set ereditabile. Sembra che possiamo solo aggiungere al set ereditabile capacità dal set di bounding. Ciò significa che non possiamo mettere nuove capacità come CAP_SYS_ADMIN o CAP_SYS_PTRACE nel set ereditato per escalare i privilegi.
CAP_SYS_RAWIO
CAP_SYS_RAWIO fornisce una serie di operazioni sensibili tra cui l'accesso a /dev/mem
, /dev/kmem
o /proc/kcore
, modificare mmap_min_addr
, accedere alle chiamate di sistema ioperm(2)
e iopl(2)
, e vari comandi del disco. L'FIBMAP ioctl(2)
è anche abilitato tramite questa capacità, il che ha causato problemi in passato. Secondo la pagina man, questo consente anche al detentore di descrittivamente eseguire una serie di operazioni specifiche per dispositivo su altri dispositivi
.
Questo può essere utile per l'escalation dei privilegi e il breakout di Docker.
CAP_KILL
Questo significa che è possibile uccidere qualsiasi processo.
Esempio con binario
Supponiamo che il python
binario abbia questa capacità. Se potessi anche modificare alcune configurazioni di servizio o socket (o qualsiasi file di configurazione relativo a un servizio), potresti inserire una backdoor, e poi uccidere il processo relativo a quel servizio e aspettare che il nuovo file di configurazione venga eseguito con la tua backdoor.
Privesc con kill
Se hai capacità di kill e c'è un programma node in esecuzione come root (o come un altro utente) potresti probabilmente inviargli il segnale SIGUSR1 e farlo aprire il debugger node a cui puoi connetterti.
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON è l'evento di cybersecurity più rilevante in Spagna e uno dei più importanti in Europa. Con la missione di promuovere la conoscenza tecnica, questo congresso è un punto di incontro vivace per professionisti della tecnologia e della cybersecurity in ogni disciplina.
CAP_NET_BIND_SERVICE
Questo significa che è possibile ascoltare su qualsiasi porta (anche su quelle privilegiate). Non puoi elevare i privilegi direttamente con questa capacità.
Esempio con binario
Se python
ha questa capacità, sarà in grado di ascoltare su qualsiasi porta e persino connettersi da essa a qualsiasi altra porta (alcuni servizi richiedono connessioni da porte privilegiate specifiche)
CAP_NET_RAW
CAP_NET_RAW la capacità consente ai processi di creare socket RAW e PACKET, permettendo loro di generare e inviare pacchetti di rete arbitrari. Questo può portare a rischi per la sicurezza in ambienti containerizzati, come spoofing dei pacchetti, iniezione di traffico e bypass dei controlli di accesso alla rete. Attori malintenzionati potrebbero sfruttare questo per interferire con il routing dei container o compromettere la sicurezza della rete host, specialmente senza adeguate protezioni del firewall. Inoltre, CAP_NET_RAW è cruciale per i container privilegiati per supportare operazioni come ping tramite richieste ICMP RAW.
Questo significa che è possibile sniffare il traffico. Non puoi elevare i privilegi direttamente con questa capacità.
Esempio con binario
Se il binario tcpdump
ha questa capacità, sarai in grado di usarlo per catturare informazioni di rete.
Nota che se l'ambiente sta dando questa capacità, potresti anche usare tcpdump
per sniffare il traffico.
Esempio con binario 2
Il seguente esempio è codice python2
che può essere utile per intercettare il traffico dell'interfaccia "lo" (localhost). Il codice proviene dal laboratorio "The Basics: CAP-NET_BIND + NET_RAW" da https://attackdefense.pentesteracademy.com/
CAP_NET_ADMIN + CAP_NET_RAW
CAP_NET_ADMIN la capacità concede al detentore il potere di modificare le configurazioni di rete, inclusi le impostazioni del firewall, le tabelle di routing, i permessi dei socket e le impostazioni delle interfacce di rete all'interno degli spazi dei nomi di rete esposti. Abilita anche l'attivazione della modalità promiscuo sulle interfacce di rete, consentendo l'analisi dei pacchetti attraverso gli spazi dei nomi.
Esempio con binario
Supponiamo che il binario python abbia queste capacità.
CAP_LINUX_IMMUTABLE
Questo significa che è possibile modificare gli attributi dell'inode. Non puoi elevare i privilegi direttamente con questa capacità.
Esempio con binario
Se scopri che un file è immutabile e python ha questa capacità, puoi rimuovere l'attributo immutabile e rendere il file modificabile:
Nota che di solito questo attributo immutabile viene impostato e rimosso utilizzando:
CAP_SYS_CHROOT
CAP_SYS_CHROOT consente l'esecuzione della chiamata di sistema chroot(2)
, che può potenzialmente permettere l'uscita dagli ambienti chroot(2)
attraverso vulnerabilità note:
CAP_SYS_BOOT
CAP_SYS_BOOT non solo consente l'esecuzione della chiamata di sistema reboot(2)
per i riavvii di sistema, inclusi comandi specifici come LINUX_REBOOT_CMD_RESTART2
adattati per determinate piattaforme hardware, ma consente anche l'uso di kexec_load(2)
e, a partire da Linux 3.17, kexec_file_load(2)
per caricare nuovi o firmati kernel di crash rispettivamente.
CAP_SYSLOG
CAP_SYSLOG è stato separato dal più ampio CAP_SYS_ADMIN in Linux 2.6.37, concedendo specificamente la possibilità di utilizzare la chiamata syslog(2)
. Questa capacità consente di visualizzare gli indirizzi del kernel tramite /proc
e interfacce simili quando l'impostazione kptr_restrict
è a 1, che controlla l'esposizione degli indirizzi del kernel. Dalla versione Linux 2.6.39, il valore predefinito per kptr_restrict
è 0, il che significa che gli indirizzi del kernel sono esposti, sebbene molte distribuzioni impostino questo valore a 1 (nascondere gli indirizzi tranne che per uid 0) o 2 (nascondere sempre gli indirizzi) per motivi di sicurezza.
Inoltre, CAP_SYSLOG consente di accedere all'output di dmesg
quando dmesg_restrict
è impostato a 1. Nonostante queste modifiche, CAP_SYS_ADMIN mantiene la capacità di eseguire operazioni syslog
a causa di precedenti storici.
CAP_MKNOD
CAP_MKNOD estende la funzionalità della chiamata di sistema mknod
oltre alla creazione di file regolari, FIFO (pipe nominate) o socket di dominio UNIX. Consente specificamente la creazione di file speciali, che includono:
S_IFCHR: File speciali di carattere, che sono dispositivi come terminali.
S_IFBLK: File speciali a blocchi, che sono dispositivi come dischi.
Questa capacità è essenziale per i processi che richiedono la possibilità di creare file di dispositivo, facilitando l'interazione diretta con l'hardware tramite dispositivi a carattere o a blocchi.
È una capacità predefinita di docker (https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19).
Questa capacità consente di effettuare escalation di privilegi (attraverso la lettura completa del disco) sull'host, a queste condizioni:
Avere accesso iniziale all'host (Non privilegiato).
Avere accesso iniziale al container (Privilegiato (EUID 0), e
CAP_MKNOD
effettivo).L'host e il container devono condividere lo stesso namespace utente.
Passaggi per Creare e Accedere a un Dispositivo a Blocco in un Container:
Sull'Host come Utente Standard:
Determina il tuo ID utente attuale con
id
, ad esempio,uid=1000(standarduser)
.Identifica il dispositivo target, ad esempio,
/dev/sdb
.
Dentro il Container come
root
:
Di nuovo sull'Host:
Questo approccio consente all'utente standard di accedere e potenzialmente leggere dati da /dev/sdb
attraverso il contenitore, sfruttando gli spazi dei nomi utente condivisi e i permessi impostati sul dispositivo.
CAP_SETPCAP
CAP_SETPCAP consente a un processo di modificare i set di capacità di un altro processo, permettendo l'aggiunta o la rimozione di capacità dai set effettivi, ereditabili e permessi. Tuttavia, un processo può modificare solo le capacità che possiede nel proprio set permesso, garantendo che non possa elevare i privilegi di un altro processo oltre il proprio. Aggiornamenti recenti del kernel hanno inasprito queste regole, limitando CAP_SETPCAP
a ridurre solo le capacità all'interno del proprio set permesso o di quello dei suoi discendenti, con l'obiettivo di mitigare i rischi per la sicurezza. L'uso richiede di avere CAP_SETPCAP
nel set effettivo e le capacità target nel set permesso, utilizzando capset()
per le modifiche. Questo riassume la funzione principale e le limitazioni di CAP_SETPCAP
, evidenziando il suo ruolo nella gestione dei privilegi e nel miglioramento della sicurezza.
CAP_SETPCAP
è una capacità di Linux che consente a un processo di modificare i set di capacità di un altro processo. Concede la possibilità di aggiungere o rimuovere capacità dai set di capacità effettivi, ereditabili e permessi di altri processi. Tuttavia, ci sono alcune restrizioni su come questa capacità può essere utilizzata.
Un processo con CAP_SETPCAP
può solo concedere o rimuovere capacità che sono nel proprio set di capacità permesso. In altre parole, un processo non può concedere una capacità a un altro processo se non possiede quella capacità. Questa restrizione impedisce a un processo di elevare i privilegi di un altro processo oltre il proprio livello di privilegio.
Inoltre, nelle versioni recenti del kernel, la capacità CAP_SETPCAP
è stata ulteriormente ristretta. Non consente più a un processo di modificare arbitrariamente i set di capacità di altri processi. Invece, consente solo a un processo di ridurre le capacità nel proprio set di capacità permesso o nel set di capacità permesso dei suoi discendenti. Questa modifica è stata introdotta per ridurre i potenziali rischi per la sicurezza associati alla capacità.
Per utilizzare CAP_SETPCAP
in modo efficace, è necessario avere la capacità nel proprio set di capacità effettivo e le capacità target nel proprio set di capacità permesso. È quindi possibile utilizzare la chiamata di sistema capset()
per modificare i set di capacità di altri processi.
In sintesi, CAP_SETPCAP
consente a un processo di modificare i set di capacità di altri processi, ma non può concedere capacità che non possiede. Inoltre, a causa di preoccupazioni per la sicurezza, la sua funzionalità è stata limitata nelle versioni recenti del kernel per consentire solo la riduzione delle capacità nel proprio set di capacità permesso o nei set di capacità permessi dei suoi discendenti.
Riferimenti
La maggior parte di questi esempi è stata presa da alcuni laboratori di https://attackdefense.pentesteracademy.com/, quindi se vuoi praticare queste tecniche di privesc ti consiglio questi laboratori.
Altri riferimenti:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON è l'evento di cybersecurity più rilevante in Spagna e uno dei più importanti in Europa. Con la missione di promuovere la conoscenza tecnica, questo congresso è un punto di incontro fervente per professionisti della tecnologia e della cybersecurity in ogni disciplina.
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica Hacking GCP:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated