Linux Privilege Escalation
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Informazioni di Sistema
Informazioni OS
Iniziamo a ottenere alcune conoscenze sul sistema operativo in esecuzione
Path
Se hai permessi di scrittura su qualsiasi cartella all'interno della variabile PATH
potresti essere in grado di dirottare alcune librerie o binari:
Env info
Informazioni interessanti, password o chiavi API nelle variabili d'ambiente?
Kernel exploits
Controlla la versione del kernel e se ci sono exploit che possono essere utilizzati per elevare i privilegi.
Puoi trovare un buon elenco di kernel vulnerabili e alcuni compiled exploits già qui: https://github.com/lucyoa/kernel-exploits e exploitdb sploits. Altri siti dove puoi trovare alcuni compiled exploits: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack
Per estrarre tutte le versioni vulnerabili del kernel da quel sito puoi fare:
Strumenti che potrebbero aiutare a cercare exploit del kernel sono:
linux-exploit-suggester.sh linux-exploit-suggester2.pl linuxprivchecker.py (eseguire NEL vittima, controlla solo exploit per kernel 2.x)
Cerca sempre la versione del kernel su Google, forse la tua versione del kernel è scritta in qualche exploit del kernel e allora sarai sicuro che questo exploit è valido.
CVE-2016-5195 (DirtyCow)
Escalation dei privilegi di Linux - Linux Kernel <= 3.19.0-73.8
Versione di Sudo
Basato sulle versioni vulnerabili di sudo che appaiono in:
Puoi controllare se la versione di sudo è vulnerabile utilizzando questo grep.
sudo < v1.28
Da @sickrov
Dmesg signature verification failed
Controlla smasher2 box di HTB per un esempio di come questa vulnerabilità potrebbe essere sfruttata
Maggiore enumerazione del sistema
Enumerare le possibili difese
AppArmor
Grsecurity
PaX
Execshield
SElinux
ASLR
Docker Breakout
Se sei all'interno di un container docker, puoi provare a fuggire da esso:
Docker SecurityDrives
Controlla cosa è montato e smontato, dove e perché. Se qualcosa è smontato, potresti provare a montarlo e controllare informazioni private.
Software utile
Enumerare i binari utili
Controlla anche se è installato un compilatore. Questo è utile se hai bisogno di utilizzare qualche exploit del kernel poiché è consigliato compilarlo nella macchina in cui lo utilizzerai (o in una simile).
Software Vulnerabile Installato
Controlla la versione dei pacchetti e dei servizi installati. Potrebbe esserci qualche vecchia versione di Nagios (ad esempio) che potrebbe essere sfruttata per l'escalation dei privilegi... Si consiglia di controllare manualmente la versione del software installato più sospetto.
Se hai accesso SSH alla macchina, puoi anche utilizzare openVAS per controllare se ci sono software obsoleti e vulnerabili installati all'interno della macchina.
Tieni presente che questi comandi mostreranno molte informazioni che saranno per lo più inutili, quindi è consigliato utilizzare alcune applicazioni come OpenVAS o simili che verificheranno se qualche versione del software installato è vulnerabile a exploit noti
Processi
Dai un'occhiata a quali processi vengono eseguiti e controlla se qualche processo ha più privilegi di quanto dovrebbe (magari un tomcat eseguito da root?)
Controlla sempre la presenza di [debugger electron/cef/chromium] in esecuzione, potresti abusarne per elevare i privilegi](electron-cef-chromium-debugger-abuse.md). Linpeas li rileva controllando il parametro --inspect
all'interno della riga di comando del processo.
Controlla anche i tuoi privilegi sui binari dei processi, forse puoi sovrascrivere qualcuno.
Monitoraggio dei processi
Puoi utilizzare strumenti come pspy per monitorare i processi. Questo può essere molto utile per identificare processi vulnerabili eseguiti frequentemente o quando viene soddisfatto un insieme di requisiti.
Memoria del processo
Alcuni servizi di un server salvano le credenziali in chiaro all'interno della memoria. Normalmente avrai bisogno di privilegi di root per leggere la memoria dei processi che appartengono ad altri utenti, quindi questo è solitamente più utile quando sei già root e vuoi scoprire ulteriori credenziali. Tuttavia, ricorda che come utente normale puoi leggere la memoria dei processi che possiedi.
Nota che oggigiorno la maggior parte delle macchine non consente ptrace per impostazione predefinita, il che significa che non puoi dumpare altri processi che appartengono al tuo utente non privilegiato.
Il file /proc/sys/kernel/yama/ptrace_scope controlla l'accessibilità di ptrace:
kernel.yama.ptrace_scope = 0: tutti i processi possono essere debugged, purché abbiano lo stesso uid. Questo è il modo classico in cui funzionava il ptracing.
kernel.yama.ptrace_scope = 1: solo un processo padre può essere debugged.
kernel.yama.ptrace_scope = 2: solo l'amministratore può utilizzare ptrace, poiché richiede la capacità CAP_SYS_PTRACE.
kernel.yama.ptrace_scope = 3: Nessun processo può essere tracciato con ptrace. Una volta impostato, è necessario un riavvio per abilitare nuovamente il ptracing.
GDB
Se hai accesso alla memoria di un servizio FTP (ad esempio) potresti ottenere l'Heap e cercare all'interno delle sue credenziali.
Script GDB
/proc/$pid/maps & /proc/$pid/mem
Per un dato ID di processo, maps mostra come la memoria è mappata all'interno dello spazio degli indirizzi virtuali di quel processo; mostra anche le permissive di ciascuna regione mappata. Il mem pseudo file espone la memoria dei processi stessi. Dal file maps sappiamo quali regioni di memoria sono leggibili e i loro offset. Utilizziamo queste informazioni per cercare nel file mem e dumpare tutte le regioni leggibili in un file.
/dev/mem
/dev/mem
fornisce accesso alla memoria fisica del sistema, non alla memoria virtuale. Lo spazio degli indirizzi virtuali del kernel può essere accessibile utilizzando /dev/kmem.
Tipicamente, /dev/mem
è leggibile solo da root e dal gruppo kmem.
ProcDump per linux
ProcDump è una reinterpretazione per Linux del classico strumento ProcDump della suite di strumenti Sysinternals per Windows. Ottienilo su https://github.com/Sysinternals/ProcDump-for-Linux
Strumenti
Per dumpare la memoria di un processo puoi usare:
https://github.com/hajzer/bash-memory-dump (root) - _Puoi rimuovere manualmente i requisiti di root e dumpare il processo di tua proprietà
Script A.5 da https://www.delaat.net/rp/2016-2017/p97/report.pdf (è richiesto root)
Credenziali dalla Memoria del Processo
Esempio manuale
Se trovi che il processo dell'autenticatore è in esecuzione:
Puoi eseguire il dump del processo (vedi le sezioni precedenti per trovare diversi modi per eseguire il dump della memoria di un processo) e cercare le credenziali all'interno della memoria:
mimipenguin
Lo strumento https://github.com/huntergregal/mimipenguin ruberà le credenziali in chiaro dalla memoria e da alcuni file ben noti. Richiede privilegi di root per funzionare correttamente.
Password GDM (Kali Desktop, Debian Desktop)
gdm-password
Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop)
gnome-keyring-daemon
LightDM (Ubuntu Desktop)
lightdm
VSFTPd (Connessioni FTP Attive)
vsftpd
Apache2 (Sessioni HTTP Basic Auth Attive)
apache2
OpenSSH (Sessioni SSH Attive - Uso di Sudo)
sshd:
Search Regexes/truffleproc
Scheduled/Cron jobs
Controlla se qualche lavoro programmato è vulnerabile. Forse puoi approfittare di uno script eseguito da root (vulnerabilità wildcard? può modificare file utilizzati da root? usare symlink? creare file specifici nella directory utilizzata da root?).
Cron path
Ad esempio, all'interno di /etc/crontab puoi trovare il PATH: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
(Nota come l'utente "user" abbia privilegi di scrittura su /home/user)
Se all'interno di questo crontab l'utente root cerca di eseguire qualche comando o script senza impostare il path. Ad esempio: * * * * root overwrite.sh Allora, puoi ottenere una shell root usando:
Cron usando uno script con un carattere jolly (Wildcard Injection)
Se uno script eseguito da root ha un “*” all'interno di un comando, potresti sfruttarlo per fare cose inaspettate (come privesc). Esempio:
Se il carattere jolly è preceduto da un percorso come /some/path/* , non è vulnerabile (anche ./* non lo è).
Leggi la pagina seguente per ulteriori trucchi di sfruttamento dei caratteri jolly:
Wildcards Spare tricksSovrascrittura dello script cron e symlink
Se puoi modificare uno script cron eseguito da root, puoi ottenere una shell molto facilmente:
Se lo script eseguito da root utilizza una directory a cui hai accesso completo, potrebbe essere utile eliminare quella cartella e creare una cartella symlink a un'altra che serve uno script controllato da te.
Lavori cron frequenti
Puoi monitorare i processi per cercare processi che vengono eseguiti ogni 1, 2 o 5 minuti. Forse puoi approfittarne e aumentare i privilegi.
Ad esempio, per monitorare ogni 0,1s per 1 minuto, ordinare per comandi meno eseguiti e eliminare i comandi che sono stati eseguiti di più, puoi fare:
Puoi anche usare pspy (questo monitorerà e elencherà ogni processo che inizia).
Cron job invisibili
È possibile creare un cronjob mettendo un ritorno a capo dopo un commento (senza carattere di nuova linea), e il cron job funzionerà. Esempio (nota il carattere di ritorno a capo):
Servizi
File .service scrivibili
Controlla se puoi scrivere qualsiasi file .service
, se puoi, potresti modificarlo in modo che esegua il tuo backdoor quando il servizio viene avviato, riavviato o interrotto (forse dovrai aspettare fino a quando la macchina non viene riavviata).
Ad esempio, crea il tuo backdoor all'interno del file .service con ExecStart=/tmp/script.sh
Binaries di servizio scrivibili
Tieni presente che se hai permessi di scrittura sui binary eseguiti dai servizi, puoi cambiarli con backdoor in modo che quando i servizi vengono rieseguiti, le backdoor verranno eseguite.
systemd PATH - Percorsi relativi
Puoi vedere il PATH utilizzato da systemd con:
Se scopri che puoi scrivere in una delle cartelle del percorso, potresti essere in grado di escalare i privilegi. Devi cercare percorsi relativi utilizzati nei file di configurazione dei servizi come:
Poi, crea un eseguibile con lo stesso nome del binario del percorso relativo all'interno della cartella PATH di systemd in cui puoi scrivere, e quando il servizio viene chiesto di eseguire l'azione vulnerabile (Start, Stop, Reload), il tuo backdoor verrà eseguito (gli utenti non privilegiati di solito non possono avviare/arrestare servizi, ma controlla se puoi usare sudo -l
).
Scopri di più sui servizi con man systemd.service
.
Timer
I Timer sono file di unità systemd il cui nome termina con **.timer**
che controllano i file **.service**
o eventi. I Timer possono essere utilizzati come alternativa a cron poiché hanno supporto integrato per eventi di tempo del calendario e eventi di tempo monotono e possono essere eseguiti in modo asincrono.
Puoi enumerare tutti i timer con:
Writable timers
Se puoi modificare un timer, puoi farlo eseguire alcune istanze di systemd.unit (come un .service
o un .target
)
Nella documentazione puoi leggere cosa è l'Unit:
L'unità da attivare quando questo timer scade. L'argomento è un nome di unità, il cui suffisso non è ".timer". Se non specificato, questo valore predefinito è un servizio che ha lo stesso nome dell'unità timer, tranne per il suffisso. (Vedi sopra.) Si raccomanda che il nome dell'unità che viene attivata e il nome dell'unità del timer siano nominati in modo identico, tranne per il suffisso.
Pertanto, per abusare di questo permesso dovresti:
Trovare qualche unità systemd (come un
.service
) che sta eseguendo un binario scrivibileTrovare qualche unità systemd che sta eseguendo un percorso relativo e hai privilegi di scrittura sul PATH di systemd (per impersonare quell'eseguibile)
Scopri di più sui timer con man systemd.timer
.
Abilitare il Timer
Per abilitare un timer hai bisogno di privilegi di root ed eseguire:
Nota che il timer è attivato creando un symlink ad esso in /etc/systemd/system/<WantedBy_section>.wants/<name>.timer
Sockets
I Unix Domain Sockets (UDS) abilitano la comunicazione tra processi sulla stessa o su macchine diverse all'interno di modelli client-server. Utilizzano file descrittori Unix standard per la comunicazione inter-computer e sono configurati tramite file .socket
.
I sockets possono essere configurati utilizzando file .socket
.
Scopri di più sui sockets con man systemd.socket
. All'interno di questo file, possono essere configurati diversi parametri interessanti:
ListenStream
,ListenDatagram
,ListenSequentialPacket
,ListenFIFO
,ListenSpecial
,ListenNetlink
,ListenMessageQueue
,ListenUSBFunction
: Queste opzioni sono diverse ma viene utilizzato un riepilogo per indicare dove ascolterà il socket (il percorso del file socket AF_UNIX, l'IPv4/6 e/o il numero di porta da ascoltare, ecc.)Accept
: Accetta un argomento booleano. Se vero, una istanza di servizio viene generata per ogni connessione in arrivo e solo il socket di connessione viene passato ad essa. Se falso, tutti i socket di ascolto stessi sono passati all'unità di servizio avviata, e solo un'unità di servizio viene generata per tutte le connessioni. Questo valore viene ignorato per i socket datagram e le FIFO dove un'unica unità di servizio gestisce incondizionatamente tutto il traffico in arrivo. Di default è falso. Per motivi di prestazioni, si raccomanda di scrivere nuovi demoni solo in un modo adatto perAccept=no
.ExecStartPre
,ExecStartPost
: Accetta una o più righe di comando, che vengono eseguite prima o dopo che i sockets/FIFO di ascolto siano creati e legati, rispettivamente. Il primo token della riga di comando deve essere un nome di file assoluto, seguito da argomenti per il processo.ExecStopPre
,ExecStopPost
: Comandi aggiuntivi che vengono eseguiti prima o dopo che i sockets/FIFO di ascolto siano chiusi e rimossi, rispettivamente.Service
: Specifica il nome dell'unità di servizio da attivare sul traffico in arrivo. Questa impostazione è consentita solo per i sockets con Accept=no. Di default è il servizio che porta lo stesso nome del socket (con il suffisso sostituito). Nella maggior parte dei casi, non dovrebbe essere necessario utilizzare questa opzione.
File .socket scrivibili
Se trovi un file .socket
scrivibile puoi aggiungere all'inizio della sezione [Socket]
qualcosa come: ExecStartPre=/home/kali/sys/backdoor
e la backdoor verrà eseguita prima che il socket venga creato. Pertanto, probabilmente dovrai aspettare fino a quando la macchina non verrà riavviata.
&#xNAN;Nota che il sistema deve utilizzare quella configurazione del file socket o la backdoor non verrà eseguita
Sockets scrivibili
Se identifichi un socket scrivibile (ora stiamo parlando di Unix Sockets e non dei file di configurazione .socket
), allora puoi comunicare con quel socket e forse sfruttare una vulnerabilità.
Enumerare i Unix Sockets
Connessione grezza
Esempio di sfruttamento:
Socket Command InjectionSockets HTTP
Nota che potrebbero esserci alcuni sockets in ascolto per richieste HTTP (non sto parlando di file .socket ma dei file che fungono da sockets unix). Puoi controllare questo con:
Se il socket risponde con una richiesta HTTP, allora puoi comunicare con esso e forse sfruttare qualche vulnerabilità.
Socket Docker Scrivibile
Il socket Docker, spesso trovato in /var/run/docker.sock
, è un file critico che dovrebbe essere protetto. Per impostazione predefinita, è scrivibile dall'utente root
e dai membri del gruppo docker
. Possedere l'accesso in scrittura a questo socket può portare a un'escalation dei privilegi. Ecco una panoramica di come ciò può essere fatto e metodi alternativi se il Docker CLI non è disponibile.
Escalation dei Privilegi con Docker CLI
Se hai accesso in scrittura al socket Docker, puoi aumentare i privilegi utilizzando i seguenti comandi:
Questi comandi ti consentono di eseguire un container con accesso a livello root al file system dell'host.
Utilizzando direttamente l'API Docker
Nei casi in cui il Docker CLI non sia disponibile, il socket Docker può comunque essere manipolato utilizzando l'API Docker e i comandi curl
.
Elenca le immagini Docker: Recupera l'elenco delle immagini disponibili.
Crea un container: Invia una richiesta per creare un container che monta la directory root del sistema host.
Avvia il container appena creato:
Collegati al container: Usa
socat
per stabilire una connessione al container, abilitando l'esecuzione di comandi al suo interno.
Dopo aver impostato la connessione socat
, puoi eseguire comandi direttamente nel container con accesso a livello root al file system dell'host.
Altri
Nota che se hai permessi di scrittura sul socket docker perché sei all'interno del gruppo docker
hai più modi per elevare i privilegi. Se l'API docker sta ascoltando su una porta puoi anche essere in grado di comprometterla.
Controlla altri modi per uscire da docker o abusarne per elevare i privilegi in:
Docker SecurityElevazione dei privilegi di Containerd (ctr)
Se scopri di poter utilizzare il comando ctr
leggi la pagina seguente poiché potresti essere in grado di abusarne per elevare i privilegi:
Elevazione dei privilegi di RunC
Se scopri di poter utilizzare il comando runc
leggi la pagina seguente poiché potresti essere in grado di abusarne per elevare i privilegi:
D-Bus
D-Bus è un sofisticato sistema di comunicazione inter-processo (IPC) che consente alle applicazioni di interagire e condividere dati in modo efficiente. Progettato tenendo presente il moderno sistema Linux, offre un robusto framework per diverse forme di comunicazione tra applicazioni.
Il sistema è versatile, supportando IPC di base che migliora lo scambio di dati tra processi, simile a socket di dominio UNIX migliorati. Inoltre, aiuta a trasmettere eventi o segnali, favorendo un'integrazione senza soluzione di continuità tra i componenti del sistema. Ad esempio, un segnale da un demone Bluetooth riguardo a una chiamata in arrivo può indurre un lettore musicale a silenziarsi, migliorando l'esperienza dell'utente. Inoltre, D-Bus supporta un sistema di oggetti remoti, semplificando le richieste di servizio e le invocazioni di metodo tra le applicazioni, snellendo processi che erano tradizionalmente complessi.
D-Bus opera su un modello di autorizzazione/negazione, gestendo i permessi dei messaggi (chiamate di metodo, emissioni di segnali, ecc.) in base all'effetto cumulativo delle regole di policy corrispondenti. Queste politiche specificano le interazioni con il bus, consentendo potenzialmente l'elevazione dei privilegi attraverso lo sfruttamento di questi permessi.
Un esempio di tale politica in /etc/dbus-1/system.d/wpa_supplicant.conf
è fornito, dettagliando i permessi per l'utente root di possedere, inviare e ricevere messaggi da fi.w1.wpa_supplicant1
.
Le politiche senza un utente o gruppo specificato si applicano universalmente, mentre le politiche di contesto "predefinite" si applicano a tutti non coperti da altre politiche specifiche.
Impara come enumerare e sfruttare una comunicazione D-Bus qui:
D-Bus Enumeration & Command Injection Privilege EscalationRete
È sempre interessante enumerare la rete e capire la posizione della macchina.
Enumerazione generica
Open ports
Controlla sempre i servizi di rete in esecuzione sulla macchina con cui non sei stato in grado di interagire prima di accedervi:
Sniffing
Controlla se puoi sniffare il traffico. Se puoi, potresti essere in grado di acquisire alcune credenziali.
Utenti
Enumerazione Generica
Controlla chi sei, quali privilegi hai, quali utenti sono nei sistemi, quali possono accedere e quali hanno privilegi di root:
Big UID
Alcune versioni di Linux sono state colpite da un bug che consente agli utenti con UID > INT_MAX di elevare i privilegi. Maggiori informazioni: qui, qui e qui.
Sfruttalo usando: systemd-run -t /bin/bash
Groups
Controlla se sei un membro di qualche gruppo che potrebbe concederti privilegi di root:
Interesting Groups - Linux PrivescClipboard
Controlla se c'è qualcosa di interessante all'interno degli appunti (se possibile)
Politica delle Password
Password noti
Se conosci qualche password dell'ambiente cerca di accedere come ogni utente utilizzando la password.
Su Brute
Se non ti dispiace fare molto rumore e i binari su
e timeout
sono presenti sul computer, puoi provare a forzare l'accesso agli utenti usando su-bruteforce.
Linpeas con il parametro -a
prova anche a forzare l'accesso agli utenti.
Abusi di PATH scrivibile
$PATH
Se scopri che puoi scrivere all'interno di qualche cartella del $PATH potresti essere in grado di elevare i privilegi creando una backdoor all'interno della cartella scrivibile con il nome di qualche comando che verrà eseguito da un altro utente (idealmente root) e che non è caricato da una cartella che si trova prima della tua cartella scrivibile in $PATH.
SUDO e SUID
Potresti essere autorizzato a eseguire qualche comando usando sudo o potrebbero avere il bit suid. Controllalo usando:
Alcuni comandi inaspettati ti consentono di leggere e/o scrivere file o persino eseguire un comando. Ad esempio:
NOPASSWD
La configurazione di Sudo potrebbe consentire a un utente di eseguire alcuni comandi con i privilegi di un altro utente senza conoscere la password.
In questo esempio, l'utente demo
può eseguire vim
come root
, ora è banale ottenere una shell aggiungendo una chiave ssh nella directory root o chiamando sh
.
SETENV
Questa direttiva consente all'utente di impostare una variabile di ambiente durante l'esecuzione di qualcosa:
Questo esempio, basato sulla macchina HTB Admirer, era vulnerabile all'hijacking di PYTHONPATH per caricare una libreria python arbitraria mentre si eseguiva lo script come root:
Sudo execution bypassing paths
Salta per leggere altri file o usa symlinks. Ad esempio nel file sudoers: hacker10 ALL= (root) /bin/less /var/log/*
Se viene utilizzato un wildcard (*), è ancora più facile:
Contromisure: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/
Comando Sudo/Binario SUID senza percorso del comando
Se il permesso sudo è dato a un singolo comando senza specificare il percorso: hacker10 ALL= (root) less puoi sfruttarlo cambiando la variabile PATH
Questa tecnica può essere utilizzata anche se un suid binary esegue un altro comando senza specificare il percorso (controlla sempre con strings il contenuto di un strano SUID binary).
Esempi di payload da eseguire.
SUID binary con percorso del comando
Se il suid binary esegue un altro comando specificando il percorso, allora puoi provare a esportare una funzione chiamata come il comando che il file suid sta chiamando.
Ad esempio, se un binary suid chiama /usr/sbin/service apache2 start devi provare a creare la funzione ed esportarla:
Poi, quando chiami il binario suid, questa funzione verrà eseguita
LD_PRELOAD & LD_LIBRARY_PATH
La variabile di ambiente LD_PRELOAD viene utilizzata per specificare una o più librerie condivise (.so file) da caricare dal loader prima di tutte le altre, inclusa la libreria C standard (libc.so
). Questo processo è noto come preloading di una libreria.
Tuttavia, per mantenere la sicurezza del sistema e prevenire che questa funzionalità venga sfruttata, in particolare con eseguibili suid/sgid, il sistema impone determinate condizioni:
Il loader ignora LD_PRELOAD per gli eseguibili in cui l'ID utente reale (ruid) non corrisponde all'ID utente efficace (euid).
Per gli eseguibili con suid/sgid, solo le librerie nei percorsi standard che sono anche suid/sgid vengono preloaded.
L'escalation dei privilegi può verificarsi se hai la possibilità di eseguire comandi con sudo
e l'output di sudo -l
include l'affermazione env_keep+=LD_PRELOAD. Questa configurazione consente alla variabile di ambiente LD_PRELOAD di persistere e di essere riconosciuta anche quando i comandi vengono eseguiti con sudo
, portando potenzialmente all'esecuzione di codice arbitrario con privilegi elevati.
Salva come /tmp/pe.c
Poi compilalo usando:
Finalmente, escalare i privilegi eseguendo
Un privesc simile può essere abusato se l'attaccante controlla la variabile di ambiente LD_LIBRARY_PATH perché controlla il percorso in cui verranno cercate le librerie.
SUID Binary – .so injection
Quando si incontra un binario con permessi SUID che sembra insolito, è buona pratica verificare se sta caricando correttamente i file .so. Questo può essere controllato eseguendo il seguente comando:
Per esempio, incontrare un errore come "open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (Nessun file o directory di questo tipo)" suggerisce un potenziale per l'exploitation.
Per sfruttare questo, si procederebbe creando un file C, ad esempio "/path/to/.config/libcalc.c", contenente il seguente codice:
Questo codice, una volta compilato ed eseguito, mira ad elevare i privilegi manipolando i permessi dei file ed eseguendo una shell con privilegi elevati.
Compila il file C sopra in un file oggetto condiviso (.so) con:
Infine, l'esecuzione del binario SUID interessato dovrebbe attivare l'exploit, consentendo un potenziale compromesso del sistema.
Hijacking di Oggetti Condivisi
Ora che abbiamo trovato un binario SUID che carica una libreria da una cartella in cui possiamo scrivere, creiamo la libreria in quella cartella con il nome necessario:
Se ricevi un errore come
that means that the library you have generated need to have a function called a_function_name
.
GTFOBins
GTFOBins è un elenco curato di binari Unix che possono essere sfruttati da un attaccante per bypassare le restrizioni di sicurezza locali. GTFOArgs è lo stesso ma per i casi in cui puoi iniettare solo argomenti in un comando.
Il progetto raccoglie funzioni legittime di binari Unix che possono essere abusate per uscire da shell ristrette, elevare o mantenere privilegi elevati, trasferire file, generare shell bind e reverse, e facilitare altre attività post-exploitation.
gdb -nx -ex '!sh' -ex quit sudo mysql -e '! /bin/sh' strace -o /dev/null /bin/sh sudo awk 'BEGIN {system("/bin/sh")}'
FallOfSudo
Se puoi accedere a sudo -l
puoi usare lo strumento FallOfSudo per controllare se trova come sfruttare qualsiasi regola sudo.
Reusing Sudo Tokens
Nei casi in cui hai accesso a sudo ma non la password, puoi elevare i privilegi aspettando l'esecuzione di un comando sudo e poi dirottando il token di sessione.
Requisiti per elevare i privilegi:
Hai già una shell come utente "sampleuser"
"sampleuser" ha usato
sudo
per eseguire qualcosa negli ultimi 15 minuti (per impostazione predefinita, questa è la durata del token sudo che ci consente di usaresudo
senza inserire alcuna password)cat /proc/sys/kernel/yama/ptrace_scope
è 0gdb
è accessibile (puoi essere in grado di caricarlo)
(Puoi abilitare temporaneamente ptrace_scope
con echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
o modificarlo permanentemente in /etc/sysctl.d/10-ptrace.conf
impostando kernel.yama.ptrace_scope = 0
)
Se tutti questi requisiti sono soddisfatti, puoi elevare i privilegi usando: https://github.com/nongiach/sudo_inject
Il primo exploit (
exploit.sh
) creerà il binarioactivate_sudo_token
in /tmp. Puoi usarlo per attivare il token sudo nella tua sessione (non otterrai automaticamente una shell root, faisudo su
):
Il secondo exploit (
exploit_v2.sh
) creerà una shell sh in /tmp possessa da root con setuid
Il terzo exploit (
exploit_v3.sh
) creerà un file sudoers che rende i token sudo eterni e consente a tutti gli utenti di utilizzare sudo
/var/run/sudo/ts/<Username>
Se hai permessi di scrittura nella cartella o su uno dei file creati all'interno della cartella, puoi utilizzare il binario write_sudo_token per creare un token sudo per un utente e un PID. Ad esempio, se puoi sovrascrivere il file /var/run/sudo/ts/sampleuser e hai una shell come quell'utente con PID 1234, puoi ottenere privilegi sudo senza bisogno di conoscere la password eseguendo:
/etc/sudoers, /etc/sudoers.d
Il file /etc/sudoers
e i file all'interno di /etc/sudoers.d
configurano chi può usare sudo
e come. Questi file di default possono essere letti solo dall'utente root e dal gruppo root.
Se puoi leggere questo file potresti essere in grado di ottenere alcune informazioni interessanti, e se puoi scrivere qualsiasi file sarai in grado di escalare privilegi.
Se puoi scrivere, puoi abusare di questo permesso.
Un altro modo per abusare di questi permessi:
DOAS
Ci sono alcune alternative al binario sudo
come doas
per OpenBSD, ricorda di controllare la sua configurazione in /etc/doas.conf
Sudo Hijacking
Se sai che un utente di solito si connette a una macchina e utilizza sudo
per elevare i privilegi e hai ottenuto una shell all'interno di quel contesto utente, puoi creare un nuovo eseguibile sudo che eseguirà il tuo codice come root e poi il comando dell'utente. Poi, modifica il $PATH del contesto utente (ad esempio aggiungendo il nuovo percorso in .bash_profile) in modo che quando l'utente esegue sudo, il tuo eseguibile sudo venga eseguito.
Nota che se l'utente utilizza una shell diversa (non bash) dovrai modificare altri file per aggiungere il nuovo percorso. Ad esempio, sudo-piggyback modifica ~/.bashrc
, ~/.zshrc
, ~/.bash_profile
. Puoi trovare un altro esempio in bashdoor.py
O eseguendo qualcosa come:
Shared Library
ld.so
Il file /etc/ld.so.conf
indica da dove provengono i file di configurazione caricati. Tipicamente, questo file contiene il seguente percorso: include /etc/ld.so.conf.d/*.conf
Ciò significa che i file di configurazione da /etc/ld.so.conf.d/*.conf
verranno letti. Questi file di configurazione puntano ad altre cartelle dove le librerie verranno cercate. Ad esempio, il contenuto di /etc/ld.so.conf.d/libc.conf
è /usr/local/lib
. Questo significa che il sistema cercherà le librerie all'interno di /usr/local/lib
.
Se per qualche motivo un utente ha permessi di scrittura su uno dei percorsi indicati: /etc/ld.so.conf
, /etc/ld.so.conf.d/
, qualsiasi file all'interno di /etc/ld.so.conf.d/
o qualsiasi cartella all'interno del file di configurazione in /etc/ld.so.conf.d/*.conf
, potrebbe essere in grado di elevare i privilegi.
Dai un'occhiata a come sfruttare questa misconfigurazione nella pagina seguente:
RPATH
Copiando la lib in /var/tmp/flag15/
, verrà utilizzata dal programma in questo luogo come specificato nella variabile RPATH
.
Poi crea una libreria maligna in /var/tmp
con gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6
Capacità
Le capacità di Linux forniscono un sottoinsieme dei privilegi di root disponibili a un processo. Questo rompe efficacemente i privilegi di root in unità più piccole e distintive. Ognuna di queste unità può quindi essere concessa indipendentemente ai processi. In questo modo, l'insieme completo di privilegi è ridotto, diminuendo i rischi di sfruttamento. Leggi la pagina seguente per scoprire di più sulle capacità e su come abusarne:
Linux CapabilitiesPermessi delle directory
In una directory, il bit per "eseguire" implica che l'utente interessato può "cd" nella cartella. Il bit "leggi" implica che l'utente può elencare i file, e il bit "scrivi" implica che l'utente può cancellare e creare nuovi file.
ACL
Le Liste di Controllo degli Accessi (ACL) rappresentano il secondo livello di permessi discrezionali, capaci di sovrascrivere i tradizionali permessi ugo/rwx. Questi permessi migliorano il controllo sull'accesso ai file o alle directory consentendo o negando diritti a utenti specifici che non sono i proprietari o parte del gruppo. Questo livello di granularità garantisce una gestione dell'accesso più precisa. Ulteriori dettagli possono essere trovati qui.
Dai all'utente "kali" permessi di lettura e scrittura su un file:
Ottieni file con ACL specifiche dal sistema:
Open shell sessions
In vecchie versioni puoi dirottare alcune sessioni shell di un altro utente (root). Nelle versioni più recenti sarai in grado di connetterti solo alle sessioni screen del tuo utente. Tuttavia, potresti trovare informazioni interessanti all'interno della sessione.
screen sessions hijacking
Elenca le sessioni screen
Collegati a una sessione
dirottamento delle sessioni tmux
Questo era un problema con vecchie versioni di tmux. Non sono riuscito a dirottare una sessione tmux (v2.1) creata da root come utente non privilegiato.
Elenca le sessioni tmux
Collegati a una sessione
Controlla Valentine box from HTB per un esempio.
SSH
Debian OpenSSL Predictable PRNG - CVE-2008-0166
Tutti le chiavi SSL e SSH generate su sistemi basati su Debian (Ubuntu, Kubuntu, ecc) tra settembre 2006 e il 13 maggio 2008 potrebbero essere affette da questo bug. Questo bug è causato quando si crea una nuova chiave ssh in quei sistemi operativi, poiché erano possibili solo 32.768 variazioni. Questo significa che tutte le possibilità possono essere calcolate e avendo la chiave pubblica ssh puoi cercare la corrispondente chiave privata. Puoi trovare le possibilità calcolate qui: https://github.com/g0tmi1k/debian-ssh
Valori di configurazione SSH interessanti
PasswordAuthentication: Specifica se l'autenticazione tramite password è consentita. Il valore predefinito è
no
.PubkeyAuthentication: Specifica se l'autenticazione tramite chiave pubblica è consentita. Il valore predefinito è
yes
.PermitEmptyPasswords: Quando l'autenticazione tramite password è consentita, specifica se il server consente l'accesso a account con stringhe di password vuote. Il valore predefinito è
no
.
PermitRootLogin
Specifica se root può accedere utilizzando ssh, il valore predefinito è no
. Valori possibili:
yes
: root può accedere utilizzando password e chiave privatawithout-password
oprohibit-password
: root può accedere solo con una chiave privataforced-commands-only
: Root può accedere solo utilizzando la chiave privata e se le opzioni dei comandi sono specificateno
: no
AuthorizedKeysFile
Specifica i file che contengono le chiavi pubbliche che possono essere utilizzate per l'autenticazione dell'utente. Può contenere token come %h
, che verrà sostituito dalla directory home. Puoi indicare percorsi assoluti (che iniziano con /
) o percorsi relativi dalla home dell'utente. Ad esempio:
Quella configurazione indicherà che se provi a effettuare il login con la chiave privata dell'utente "testusername", ssh confronterà la chiave pubblica della tua chiave con quelle situate in /home/testusername/.ssh/authorized_keys
e /home/testusername/access
ForwardAgent/AllowAgentForwarding
Il forwarding dell'agente SSH ti consente di utilizzare le tue chiavi SSH locali invece di lasciare le chiavi (senza passphrase!) sul tuo server. Quindi, sarai in grado di saltare via ssh a un host e da lì saltare a un altro host utilizzando la chiave situata nel tuo host iniziale.
Devi impostare questa opzione in $HOME/.ssh.config
in questo modo:
Nota che se Host
è *
, ogni volta che l'utente passa a un'altra macchina, quell'host sarà in grado di accedere alle chiavi (il che è un problema di sicurezza).
Il file /etc/ssh_config
può sovrascrivere queste opzioni e consentire o negare questa configurazione.
Il file /etc/sshd_config
può consentire o negare il forwarding dell'agent ssh con la parola chiave AllowAgentForwarding
(il valore predefinito è consentito).
Se scopri che il Forward Agent è configurato in un ambiente, leggi la seguente pagina in quanto potresti essere in grado di abusarne per escalare privilegi:
SSH Forward Agent exploitationFile Interessanti
File di profilo
Il file /etc/profile
e i file sotto /etc/profile.d/
sono script che vengono eseguiti quando un utente avvia una nuova shell. Pertanto, se puoi scrivere o modificare uno di essi, puoi escalare privilegi.
Se viene trovato uno strano script di profilo, dovresti controllarlo per dettagli sensibili.
File Passwd/Shadow
A seconda del sistema operativo, i file /etc/passwd
e /etc/shadow
potrebbero avere un nome diverso o potrebbe esserci un backup. Pertanto, è consigliato trovare tutti e controllare se puoi leggerli per vedere se ci sono hash all'interno dei file:
In alcune occasioni puoi trovare password hashes all'interno del file /etc/passwd
(o equivalente)
Writable /etc/passwd
Prima, genera una password con uno dei seguenti comandi.
Poi aggiungi l'utente hacker
e aggiungi la password generata.
E.g: hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash
Puoi ora utilizzare il comando su
con hacker:hacker
In alternativa, puoi utilizzare le seguenti righe per aggiungere un utente fittizio senza una password. ATTENZIONE: potresti degradare la sicurezza attuale della macchina.
NOTE: Su piattaforme BSD, /etc/passwd
si trova in /etc/pwd.db
e /etc/master.passwd
, inoltre /etc/shadow
è rinominato in /etc/spwd.db
.
Dovresti controllare se puoi scrivere in alcuni file sensibili. Ad esempio, puoi scrivere in qualche file di configurazione del servizio?
Ad esempio, se la macchina sta eseguendo un server tomcat e puoi modificare il file di configurazione del servizio Tomcat all'interno di /etc/systemd/, allora puoi modificare le righe:
Il tuo backdoor verrà eseguito la prossima volta che tomcat verrà avviato.
Controlla le Cartelle
Le seguenti cartelle potrebbero contenere backup o informazioni interessanti: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Probabilmente non sarai in grado di leggere l'ultima, ma prova)
Posizioni strane/File di proprietà
File modificati negli ultimi minuti
File DB Sqlite
*_history, .sudo_as_admin_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml file
File nascosti
Script/Binaries nel PATH
File web
Backup
File noti contenenti password
Leggi il codice di linPEAS, cerca diversi file possibili che potrebbero contenere password. Un altro strumento interessante che puoi usare per farlo è: LaZagne che è un'applicazione open source utilizzata per recuperare molte password memorizzate su un computer locale per Windows, Linux e Mac.
Log
Se puoi leggere i log, potresti essere in grado di trovare informazioni interessanti/confidenziali al loro interno. Più strano è il log, più interessante sarà (probabilmente). Inoltre, alcuni log di audit "mal" configurati (backdoored?) potrebbero permetterti di registrare password all'interno dei log di audit come spiegato in questo post: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/.
Per leggere i log il gruppo adm sarà davvero utile.
File di shell
Generic Creds Search/Regex
Dovresti anche controllare i file che contengono la parola "password" nel suo nome o all'interno del contenuto, e controllare anche per IP ed email all'interno dei log, o regex di hash. Non elencherò qui come fare tutto questo, ma se sei interessato puoi controllare gli ultimi controlli che linpeas esegue.
Writable files
Python library hijacking
Se sai da dove verrà eseguito uno script python e puoi scrivere all'interno di quella cartella o puoi modificare le librerie python, puoi modificare la libreria OS e backdoorarla (se puoi scrivere dove verrà eseguito lo script python, copia e incolla la libreria os.py).
Per backdoorare la libreria basta aggiungere alla fine della libreria os.py la seguente riga (cambia IP e PORT):
Logrotate exploitation
Una vulnerabilità in logrotate
consente agli utenti con permessi di scrittura su un file di log o le sue directory genitore di potenzialmente ottenere privilegi elevati. Questo perché logrotate
, spesso in esecuzione come root, può essere manipolato per eseguire file arbitrari, specialmente in directory come /etc/bash_completion.d/. È importante controllare i permessi non solo in /var/log ma anche in qualsiasi directory in cui viene applicata la rotazione dei log.
Questa vulnerabilità colpisce logrotate
versione 3.18.0
e versioni precedenti
Informazioni più dettagliate sulla vulnerabilità possono essere trovate su questa pagina: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.
Puoi sfruttare questa vulnerabilità con logrotten.
Questa vulnerabilità è molto simile a CVE-2016-1247 (log di nginx), quindi ogni volta che scopri di poter alterare i log, controlla chi gestisce quei log e verifica se puoi elevare i privilegi sostituendo i log con symlink.
/etc/sysconfig/network-scripts/ (Centos/Redhat)
Riferimento vulnerabilità: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f
Se, per qualsiasi motivo, un utente è in grado di scrivere uno script ifcf-<whatever>
in /etc/sysconfig/network-scripts o può modificare uno esistente, allora il tuo sistema è compromesso.
Gli script di rete, ifcg-eth0 per esempio, sono utilizzati per le connessioni di rete. Sembrano esattamente come file .INI. Tuttavia, sono ~sourced~ su Linux dal Network Manager (dispatcher.d).
Nel mio caso, il NAME=
attribuito in questi script di rete non è gestito correttamente. Se hai spazio bianco/vuoto nel nome, il sistema tenta di eseguire la parte dopo lo spazio bianco/vuoto. Questo significa che tutto dopo il primo spazio vuoto viene eseguito come root.
Per esempio: /etc/sysconfig/network-scripts/ifcfg-1337
init, init.d, systemd e rc.d
La directory /etc/init.d
è la casa di script per System V init (SysVinit), il classico sistema di gestione dei servizi Linux. Include script per avviare
, fermare
, riavviare
e talvolta ricaricare
i servizi. Questi possono essere eseguiti direttamente o tramite collegamenti simbolici trovati in /etc/rc?.d/
. Un percorso alternativo nei sistemi Redhat è /etc/rc.d/init.d
.
D'altra parte, /etc/init
è associato a Upstart, un sistema di gestione dei servizi più recente introdotto da Ubuntu, che utilizza file di configurazione per i compiti di gestione dei servizi. Nonostante la transizione a Upstart, gli script SysVinit sono ancora utilizzati insieme alle configurazioni di Upstart grazie a un layer di compatibilità in Upstart.
systemd emerge come un moderno gestore di inizializzazione e servizi, offrendo funzionalità avanzate come l'avvio di demoni su richiesta, la gestione dell'automount e gli snapshot dello stato del sistema. Organizza i file in /usr/lib/systemd/
per i pacchetti di distribuzione e /etc/systemd/system/
per le modifiche degli amministratori, semplificando il processo di amministrazione del sistema.
Altri Trucchi
Escalation dei privilegi NFS
NFS no_root_squash/no_all_squash misconfiguration PEUscire da Shells ristrette
Escaping from JailsCisco - vmanage
Cisco - vmanageProtezioni di Sicurezza del Kernel
Maggiori aiuti
Strumenti di Privesc Linux/Unix
Miglior strumento per cercare vettori di escalation dei privilegi locali Linux: LinPEAS
LinEnum: https://github.com/rebootuser/LinEnum(-t option) Enumy: https://github.com/luke-goddard/enumy Unix Privesc Check: http://pentestmonkey.net/tools/audit/unix-privesc-check Linux Priv Checker: www.securitysift.com/download/linuxprivchecker.py BeeRoot: https://github.com/AlessandroZ/BeRoot/tree/master/Linux Kernelpop: Enumerare le vulnerabilità del kernel in linux e MAC https://github.com/spencerdodd/kernelpop Mestaploit: multi/recon/local_exploit_suggester Linux Exploit Suggester: https://github.com/mzet-/linux-exploit-suggester EvilAbigail (accesso fisico): https://github.com/GDSSecurity/EvilAbigail Raccolta di più script: https://github.com/1N3/PrivEsc
Riferimenti
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