Tienes una shell con pocos privilegios en una máquina Linux. Explícame cómo escalarías a root.
Respuesta breve
Enumera primero: privilegios actuales, derechos de sudo, binarios SUID/SGID, tareas cron, archivos escribibles en el PATH, versión del kernel y credenciales almacenadas. Luego explota la ruta más sencilla y fiable — a menudo una regla de sudo mal configurada o un GTFOBin SUID — antes de recurrir a un exploit del kernel.
La escalada de privilegios consiste en convertir un punto de apoyo en control. En Linux, la estrategia ganadora es enumeración disciplinada primero, explotación después — la mayoría de las máquinas caen por una mala configuración, no por un 0-day.
Enumera el entorno
Empieza por entender quién eres y qué te rodea:
- Identidad y sudo:
id,sudo -l. Una sola regla de sudo mal configurada (especialmenteNOPASSWD) suele ser toda la respuesta. - Binarios SUID/SGID:
find / -perm -4000 -type f 2>/dev/null. Un binario SUID capaz de lanzar una shell o leer archivos arbitrarios es una vía directa — GTFOBins cataloga exactamente cómo abusar de los más comunes comofind,vim,nmapocp. - Tareas programadas: tareas cron (
/etc/crontab, directorios de cron) que se ejecutan como root y hacen referencia a un script en el que puedes escribir. - Rutas escribibles: archivos en el PATH de root, scripts escribibles por todos, permisos débiles en archivos sensibles.
- Credenciales: archivos de configuración, archivos de historial, claves
.ssh, contraseñas de base de datos reutilizadas para root. - Versión del kernel y del SO:
uname -a— relevante si nada más da resultado.
Herramientas como LinPEAS o linux-smart-enumeration automatizan este barrido, pero deberías entender cada comprobación a mano.
Explota la ruta más fiable
Una vez que tengas candidatos, elige la más fiable y de menor riesgo. Una regla de sudo como (ALL) NOPASSWD: /usr/bin/tar te permite abusar de la opción --checkpoint-action de tar para ejecutar comandos como root — limpio y repetible. Un script de cron escribible te da root en el siguiente tick.
Por qué los exploits del kernel son un último recurso
Los exploits del kernel (Dirty COW, Dirty Pipe, etc.) pueden tumbar la máquina, son específicos de la versión y son ruidosos. En un compromiso real, tumbar un servidor de producción es un incidente grave. Por eso solo recurres a ellos cuando las malas configuraciones no dan resultado.
Qué buscan los entrevistadores
Una metodología, no un exploit memorizado. Quieren oír «enumerar, luego tomar la victoria fiable más segura», con ejemplos concretos (sudo -l, SUID + GTFOBins) y la conciencia de que los exploits del kernel conllevan un riesgo real de estabilidad.
Posibles preguntas de seguimiento
- ¿Por qué prefieres una mala configuración de sudo o SUID a un exploit del kernel?
- ¿Cómo ayudaría GTFOBins una vez que encuentres un binario SUID como find o vim?
- ¿Qué te permite hacer una entrada como '(ALL) NOPASSWD: /usr/bin/tar'?