De user a Root || Hágalo usted mismo!

Que tan serio es que un usuario en Linux escale privilegios?. Es realmente tan fácil?.

La respuesta corta es: Depende!. Si si, es una respuesta tibia, pero sip, depende.

• Depende que tan viejo y cuantas vulnerabilidades tenga el sistema operativo
• Depende que tantos permisos de binarios haya configurado el administrador
• Depende que tan serio haya sido el admin
• Depende cuántas manos hayan tocado el sistema
• etc

Ese «etc» lo podemos averiguar con algunos comandos y eso es con lo que vamos a jugar hoy.

Siguiendo con los laboratorios para enteder un poco los ataques en nuestra era hoy vamos a revisar algunos comandos/técnicas básicas para escalar privilegios en un sistema operativo Linux no tan bien configurado y administrador.

Como funcionan los permisos en Linux?

En Linux, los permisos determinan quién puede realizar qué acciones sobre un archivo o directorio. Se basan en una estructura de tres niveles de usuarios y tres tipos de permisos básicos.

Los Tres Niveles de Usuarios (¿A quién se le aplica?)

Cada archivo o directorio pertenece a un usuario y a un grupo específicos. Los permisos se dividen en tres categorías:

• Propietario (u – User): El usuario que creó el archivo (o a quien se le asignó la propiedad).
• Grupo (g – Group): Un conjunto de usuarios que comparten los permisos asignados a ese grupo.
• Otros (o – Others): Todos los demás usuarios del sistema que no son el propietario ni pertenecen al grupo.

2. Los Tres Tipos de Permisos Básicos (¿Qué pueden hacer?)

Esto seguro ya lo conoces y lo has visto o trabajado en la consola, pero hay casos en los que estos permisos no alcanzan y es necesario autorizar de alguna otra manera.

Permisos Especiales en Linux: SUID, SGID y Sticky Bit

Además de los permisos básicos (r, w, x), Linux cuenta con tres permisos especiales diseñados para situaciones en las que los permisos estándar se quedan cortos.

1. SUID (Set User ID)

Cuando se aplica el permiso SUID a un archivo ejecutable, cualquier usuario que lo ejecute lo hará con los privilegios del propietario del archivo, no con sus propios privilegios. (Seguro ya estas viendo lo complicado que puede ser esto en temas de seguridad)

• ¿Para qué sirve? Permite a usuarios normales realizar tareas que requieren privilegios elevados (como la ejecución de comandos root) de forma «controlada».
• Ejemplo clásico: El comando /usr/bin/passwd. Un usuario común necesita modificar el archivo /etc/shadow para cambiar su contraseña (archivo que solo root puede editar). Con SUID, passwd se ejecuta temporalmente como root.

Cuando haces un ls -l: Reemplaza la x del propietario por una s (o S si no tenía permiso de ejecución).

Cómo asignarlo:

• Modo simbólico: chmod u+s archivo
• Modo numérico (En octal 4000): chmod 4755 archivo

2. SGID (Set Group ID)

El SGID funciona de manera diferente según si se aplica a un archivo o a un directorio:

• En archivos ejecutables: El programa se ejecuta con los permisos del grupo propietario del archivo.
• En directorios (Su uso principal): Todo archivo o subdirectorio creado dentro de él heredará automáticamente el grupo propietario del directorio padre, en lugar del grupo primario del usuario que lo creó.
• ¿Para qué sirve? Es fundamental en carpetas compartidas entre equipos de trabajo, asegurando que todos los archivos creados pertenezcan al mismo grupo colaborativo.

Cómo lo ves cuando haces un ls -l: Reemplaza la x del grupo por una s (o S si no tenía permiso de ejecución).

Cómo asignarlo:

• Modo simbólico: chmod g+s directorio
• Modo numérico (En octal 2000): chmod 2775 directorio

3. Sticky Bit (Bit de Persistencia)

El Sticky Bit se aplica principalmente a directorios compartidos donde varios usuarios tienen permisos de escritura (w).

• ¿Para qué sirve? Evita que un usuario elimine o altere los archivos de otro dentro del mismo directorio. Aunque un usuario tenga permiso de escritura en la carpeta, solo el propietario del archivo (o root) puede borrar o renombrar su propio archivo.
• Ejemplo clásico: El directorio temporal /tmp. Todos los usuarios del sistema pueden crear y editar archivos allí, pero nadie puede borrar los archivos de otros.

En ls -l: Reemplaza la x de otros por una t (o T si otros no tenían permiso de ejecución).

Sudoers y Capabilites

Pero ahí no termina todo, también existen otros tipos de permisos que seguro los usas a diario en tu ubuntu.

sudoers: /etc/sudoers define quién puede correr qué como otro usuario. Una regla
demasiado amplia ( user ALL=(ALL) NOPASSWD: /usr/bin/vim ) es una puerta por si todavía no lo notaste en tu sistema.

capabilities: fragmentan los poderes de root en piezas ( cap_setuid , cap_net_raw ).
Una capability colgada del binario equivocado equivale a root parcial.

Y acá viene lo interesante. Sino fuiste lo suficiente cuidadoso al otorgar estos permisos especiales a algún binario en particular puede que hayas dado un permiso que un atacate pueda explotar.

Existe un catalogo en interntet de como explotar cada uno de estos permisos en casi cualquier binario en Linux.

La falla. No está en los mecanismos, sino en configuraciones que le dan a un binario «inocente» más poder del necesario. Muchos binarios tienen funciones secundarias (ejecutar comandos, abrir un shell, leer archivos arbitrarios) que, con SUID o vía sudo, se
vuelven escalada. Ese catálogo es GTFOBins.

https://gtfobins.org

LAB – Manos a la obra

Para probar como sería la explotación de estos permisos mal otorgados vamos primer a crear nuestro «Sistema Vulnerable».

En mi caso es Debian13. Voy a darle permisos a dos ejecutables que seguro están en casi todos los sistemas.

# Como root, al preparar el lab
# SUID en find = clásico de GTFOBins
chmod u+s /usr/bin/find

# capability peligrosa
#Copio python3 a tmp para poder trabajarlo sin problemas de permisos o seguridad
cp /usr/bin/python3 /tmp/python3
/usr/sbin/setcap cap_setuid=ep /tmp/python3

Nos conectamos con un usuario normal(operador) por ssh a nuestro equipo:

Primero vamos con la técnica que usamos todos en los CTF, LinPEAS!.

La página del proyecto es: https://github.com/peass-ng/PEASS-ng/tree/master/linPEAS

Y para ejecutarlo en nuestro linux, como usuario normal usamos: From public github

curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh

LinPEAS ya está haciendo su magia.

También obviamente podemos hacerlo a mano, que es más sencillo y como corresponde:

# o a mano: buscar binarios SUID
find / -perm -4000 -type f 2>/dev/null

Ahora buscamos en GTFObins como explotarlo.

Nos dá el comando exacto para convertirnos en root y lo probamos así tal cual

Tadaaaaaaaa! El -p mantiene los privilegios elevados. Cada binario SUID de más es una vía
potencial, y linpeas automatiza encontrar cuál.

Detección y defensa.

• Auditoría: listá y justificá cada binario SUID ( find / -perm -4000 ). Lo que no tenga razón de existir, se le saca el bit.
• sudo mínimo: reglas específicas, nunca ALL , evitar NOPASSWD , y cuidado con binarios que permiten escapar a un shell.
• capabilities: revisá con getcap -r / 2>/dev/null .
• Contención: AppArmor/SELinux limitan qué puede hacer un proceso aunque escale, y
• auditd registra el uso de binarios sensibles.

Lo mismo funciona con capabilities mal asignadas

Conclusiones

Es muy importante entender que la escalada de privilegios en linux no siempre depende de una vulnerabilidad o de un rootkit. Configurar mal o dar permisos innecesarios puede derivar en una escalación de privilegios y un compromiso de un sistema completo.

Es super común que al fallar una ejecución o algún proceso el administrador juegue con: chmod -R 777 o un chown super permisivo. La pereza como provocador de errores no es algo fuera de lo común.

«Este trabajo sería genial si no fuera por los putos clientes». — Randal Graves