AppArmor
PreviousAbusing Docker Socket for Privilege EscalationNextAuthZ& AuthN - Docker Access Authorization Plugin
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AppArmor è un miglioramento del kernel progettato per limitare le risorse disponibili ai programmi attraverso profili per programma, implementando efficacemente il Controllo di Accesso Obbligatorio (MAC) legando gli attributi di controllo accessi direttamente ai programmi invece che agli utenti. Questo sistema opera caricando profili nel kernel, di solito durante l'avvio, e questi profili determinano quali risorse un programma può accedere, come connessioni di rete, accesso a socket raw e permessi di file.
Ci sono due modalità operative per i profili di AppArmor:
Modalità di Enforcement: Questa modalità applica attivamente le politiche definite all'interno del profilo, bloccando le azioni che violano queste politiche e registrando eventuali tentativi di violarle attraverso sistemi come syslog o auditd.
Modalità di Complain: A differenza della modalità di enforcement, la modalità di complain non blocca le azioni che vanno contro le politiche del profilo. Invece, registra questi tentativi come violazioni delle politiche senza applicare restrizioni.
Modulo del Kernel: Responsabile dell'applicazione delle politiche.
Politiche: Specificano le regole e le restrizioni per il comportamento dei programmi e l'accesso alle risorse.
Parser: Carica le politiche nel kernel per l'applicazione o la segnalazione.
Utilità: Questi sono programmi in modalità utente che forniscono un'interfaccia per interagire e gestire AppArmor.
I profili di AppArmor sono solitamente salvati in /etc/apparmor.d/
Con sudo aa-status sarai in grado di elencare i binari che sono limitati da qualche profilo. Se puoi cambiare il carattere "/" con un punto nel percorso di ciascun binario elencato, otterrai il nome del profilo di AppArmor all'interno della cartella menzionata.
Ad esempio, un profilo di apparmor per /usr/bin/man si troverà in /etc/apparmor.d/usr.bin.man
Per indicare l'eseguibile interessato, sono consentiti percorsi assoluti e caratteri jolly per specificare i file.
Per indicare l'accesso che il binario avrà su file, possono essere utilizzati i seguenti controlli di accesso:
r (lettura)
w (scrittura)
m (mappa di memoria come eseguibile)
k (blocco file)
l (creazione di hard link)
ix (eseguire un altro programma con la nuova politica ereditata)
Px (eseguire sotto un altro profilo, dopo aver ripulito l'ambiente)
Cx (eseguire sotto un profilo figlio, dopo aver ripulito l'ambiente)
Ux (eseguire senza restrizioni, dopo aver ripulito l'ambiente)
Le variabili possono essere definite nei profili e possono essere manipolate dall'esterno del profilo. Ad esempio: @{PROC} e @{HOME} (aggiungere #include <tunables/global> al file del profilo)
Le regole di negazione sono supportate per sovrascrivere le regole di autorizzazione.
Per iniziare facilmente a creare un profilo, apparmor può aiutarti. È possibile far ispezionare ad apparmor le azioni eseguite da un binario e poi decidere quali azioni vuoi consentire o negare. Devi solo eseguire:
Poi, in una console diversa, esegui tutte le azioni che il binario eseguirà di solito:
Poi, nella prima console premi "s" e poi nelle azioni registrate indica se vuoi ignorare, consentire o altro. Quando hai finito premi "f" e il nuovo profilo sarà creato in /etc/apparmor.d/path.to.binary
Utilizzando i tasti freccia puoi selezionare cosa vuoi consentire/negare/altro
Puoi anche creare un modello di un profilo apparmor di un binario con:
Nota che per impostazione predefinita in un profilo creato nulla è consentito, quindi tutto è negato. Dovrai aggiungere righe come /etc/passwd r, per consentire la lettura binaria di /etc/passwd, ad esempio.
Puoi quindi applicare il nuovo profilo con
Il seguente strumento leggerà i log e chiederà all'utente se desidera consentire alcune delle azioni vietate rilevate:
Utilizzando i tasti freccia puoi selezionare cosa vuoi consentire/negare/qualunque cosa
Esempio di log AUDIT e DENIED da /var/log/audit/audit.log dell'eseguibile service_bin:
Puoi anche ottenere queste informazioni utilizzando:
Nota come il profilo docker-profile di docker venga caricato per impostazione predefinita:
Per impostazione predefinita, il profilo docker-default di Apparmor è generato da https://github.com/moby/moby/tree/master/profiles/apparmor
Riepilogo del profilo docker-default:
Accesso a tutte le reti
Nessuna capacità è definita (Tuttavia, alcune capacità deriveranno dall'inclusione di regole di base, ad es. #include <abstractions/base>)
Scrivere in qualsiasi file di /proc è non consentito
Altre sottodirectory/file di /proc e /sys hanno accesso negato in lettura/scrittura/blocco/link/esecuzione
Montaggio è non consentito
Ptrace può essere eseguito solo su un processo che è confinato dallo stesso profilo apparmor
Una volta che esegui un container docker, dovresti vedere il seguente output:
Nota che apparmor bloccherà anche i privilegi delle capacità concessi al container per impostazione predefinita. Ad esempio, sarà in grado di bloccare il permesso di scrivere all'interno di /proc anche se la capacità SYS_ADMIN è concessa perché per impostazione predefinita il profilo apparmor di docker nega questo accesso:
Devi disabilitare apparmor per bypassare le sue restrizioni:
Nota che per impostazione predefinita AppArmor vietera' anche al container di montare cartelle dall'interno anche con la capacità SYS_ADMIN.
Nota che puoi aggiungere/rimuovere capacità al container docker (questo sarà comunque limitato da metodi di protezione come AppArmor e Seccomp):
--cap-add=SYS_ADMIN dà la capacità SYS_ADMIN
--cap-add=ALL dà tutte le capacità
--cap-drop=ALL --cap-add=SYS_PTRACE rimuove tutte le capacità e dà solo SYS_PTRACE
Di solito, quando scopri di avere una capacità privilegiata disponibile all'interno di un container docker ma che una parte dell'exploit non funziona, questo sarà perché apparmor di docker lo impedirà.
(Esempio da qui)
Per illustrare la funzionalità di AppArmor, ho creato un nuovo profilo Docker “mydocker” con la seguente riga aggiunta:
Per attivare il profilo, dobbiamo fare quanto segue:
Per elencare i profili, possiamo eseguire il seguente comando. Il comando qui sotto sta elencando il mio nuovo profilo AppArmor.
Come mostrato di seguito, otteniamo un errore quando cerchiamo di modificare “/etc/” poiché il profilo AppArmor impedisce l'accesso in scrittura a “/etc”.
Puoi scoprire quale profilo apparmor sta eseguendo un container usando:
Poi, puoi eseguire la seguente riga per trovare il profilo esatto in uso:
In the weird case you can modificare il profilo docker di apparmor e ricaricarlo. Potresti rimuovere le restrizioni e "bypassarle".
AppArmor è basato su percorso, questo significa che anche se potrebbe essere protetto file all'interno di una directory come /proc, se puoi configurare come il container verrà eseguito, potresti montare la directory proc dell'host all'interno di /host/proc e non sarà più protetta da AppArmor.
In questo bug puoi vedere un esempio di come anche se stai impedendo a perl di essere eseguito con determinate risorse, se crei semplicemente uno script shell specificando nella prima riga #!/usr/bin/perl e esegui il file direttamente, sarai in grado di eseguire qualsiasi cosa tu voglia. E.g.:
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
