Escalada a root en Ubuntu: técnicas, riesgos y seguridad

Si trabajas con Ubuntu a diario, tarde o temprano te toparás con la necesidad de conseguir privilegios de root para administrar el sistema: instalar paquetes, tocar servicios, modificar configuraciones delicadas o recuperar una máquina rota. Escalar a root en Ubuntu no es solo saber teclear sudo, sino entender bien qué implica, qué riesgos tiene y qué técnicas se usan (tanto legítimas como ofensivas) para llegar a ese nivel de acceso tan delicado.

En este artículo vamos a ver de forma muy completa cómo funciona el usuario root en Ubuntu, cómo y cuándo conviene usar sudo, qué peligros tiene manejarte como superusuario y, sobre todo, qué métodos reales de escalada de privilegios en Linux y en Ubuntu se utilizan en administración, pruebas de penetración y entornos corporativos: exploits de kernel, configuraciones de sudo, SUID, capacidades, cron, PATH, NFS, perfiles de AppArmor y vulnerabilidades recientes como CrackArmor o CVE‑2026‑3888.

Qué significa ser root en Ubuntu y por qué es diferente a otras distros

En cualquier sistema GNU/Linux, la cuenta root es el usuario con UID 0 y control absoluto del sistema operativo. Puede leer y escribir en cualquier archivo, arrancar o detener servicios, cargar módulos del kernel, modificar permisos, crear usuarios, montar sistemas de archivos o borrar ficheros críticos sin ninguna barrera técnica.

Ubuntu, sin embargo, adopta una filosofía de seguridad muy marcada: la cuenta root existe pero no se usa para iniciar sesión directamente por defecto. Tras una instalación estándar de Ubuntu Desktop o Server, no tienes contraseña de root configurada y no puedes entrar como root ni en la TTY ni en la interfaz gráfica, ni tampoco vía SSH.

En lugar de eso, Ubuntu apuesta por el uso del comando sudo (superuser do) como capa de seguridad. Cualquier usuario que pertenezca al grupo sudo puede ejecutar comandos concretos con privilegios de root, autenticándose con su propia contraseña. De esta forma se limita el tiempo efectivo en el que hay permisos máximos y se reduce la superficie de ataque directa sobre la cuenta más poderosa del sistema.

Esta política tiene una ventaja clave: queda trazabilidad. Cada comando ejecutado con sudo se registra en ficheros como /var/log/auth.log o en el journal de systemd, anotando quién ejecutó qué y cuándo, algo fundamental en entornos con varios administradores o con obligaciones de auditoría.

Riesgos reales de usar root sin cuidado en Ubuntu

Manejarse como root sin respetar unas mínimas buenas prácticas es una receta perfecta para el desastre. El problema principal no es tanto la complejidad técnica como el hecho de que cualquier error, por tonto que parezca, tiene impacto global sobre el sistema.

Uno de los peligros más obvios es la eliminación accidental de archivos de sistema. Un simple fallo de teclado en un comando rm o mv puede terminar borrando directorios completos, cambiando rutas críticas o destrozando permisos. El clásico ejemplo es un sudo rm -rf / mal escrito o ejecutado en el entorno equivocado, pero en la práctica basta con equivocarse de ruta o de terminal para dejar una máquina inservible.

Igual de grave es ejecutar scripts de procedencia dudosa con privilegios de root. Un script que descargues de Internet, copiado de un foro o un repositorio poco mantenido, puede contener comandos maliciosos (o simplemente mal hechos) que borren datos, instalen malware, modifiquen configuraciones de seguridad o creen puertas traseras. Si se ejecuta como root, no habrá permisos que lo frenen.

También se dispara la exposicíón a ataques: si activas el login directo de root, por ejemplo vía SSH, tu servidor se convierte en un objetivo perfecto para fuerza bruta. Un atacante que consiga la contraseña de root, o que logre una escalada local hasta esa cuenta, tendrá el control pleno del host, con capacidad de unirlo a una botnet, cifrar información o pivotar hacia otros sistemas internos.

Por último, iniciar sesión directamente como root empeora muchísimo la trazabilidad. Todos los comandos aparecen en los logs como ejecutados por root sin diferenciar qué administrador los lanzó, algo que complica la investigación de incidentes, la depuración de cambios problemáticos y el cumplimiento de estándares como ISO 27001 o PCI DSS.

Formas seguras (y no tan seguras) de acceder a root en Ubuntu

La forma recomendada por Ubuntu para obtener privilegios elevados es, con diferencia, usar sudo de manera puntual. Antepones sudo a un comando y este se ejecuta con permisos de root, pidiéndote tu contraseña de usuario si tu sesión lo requiere.

Para tareas rápidas, basta con la sintaxis habitual: sudo comando argumentos. Ejemplos típicos son sudo apt update para actualizar la lista de paquetes, sudo apt install para instalar software, sudo systemctl restart apache2 para reiniciar servicios o sudo nano /etc/ssh/sshd_config para editar archivos de configuración protegidos.

Si necesitas lanzar varios comandos seguidos y no te apetece escribir sudo una y otra vez, puedes obtener una shell de root temporal con sudo -i o sudo su –. Ambas opciones te dejan dentro de un intérprete como root; sudo -i tiende a replicar mejor el entorno completo de inicio de sesión de ese usuario, incluido PATH y variables de entorno, lo que reduce comportamientos raros con ciertos scripts.

Para salir de una shell de root, simplemente escribe exit o pulsa Ctrl+D. Es esencial no dejar sesiones de root abiertas sin supervisión, porque cualquiera con acceso físico o remoto podría aprovecharlas para hacer cambios críticos sin necesidad de autenticarse de nuevo.

Existe, eso sí, la opción de habilitar una contraseña para la cuenta root con sudo passwd root. Pero esto, más que una práctica habitual, es una excepción para casos muy concretos (recuperación de sistemas muy dañados, configuraciones especiales en entornos cerrados, etc.). Activar root con contraseña abre un vector de ataque adicional y suele chocar directamente con las recomendaciones de seguridad de Ubuntu.

Escalada de privilegios: conceptos básicos en Linux y Ubuntu

En pruebas de penetración, en auditorías de seguridad o incluso en laboratorios de aprendizaje, hablar de “escalada a root” en Ubuntu significa, en esencia, pasar de un usuario con pocos privilegios a la cuenta root o, al menos, a permisos equivalentes.

Se distinguen dos tipos principales de escalada de privilegios. Por un lado está la escalada vertical, cuando un atacante o un usuario pasa de una cuenta sin privilegios (por ejemplo, un usuario estándar o de servicio) a una cuenta mucho más poderosa, como root o un administrador del sistema. Por otro lado está la escalada horizontal, en la que permaneces en el mismo nivel de permisos pero accedes a recursos de otro usuario, como leer sus archivos personales o su correo.

La clave para conseguir una escalada de privilegios estable es la enumeración exhaustiva del sistema. Nada de ir a ciegas: hay que recopilar información sobre la versión de la distribución, del kernel, los servicios en ejecución, configuraciones de sudo, archivos SUID, capacidades, trabajos cron, sistemas de archivos disponibles y un largo etcétera.

Entre los comandos básicos de enumeración en un Ubuntu comprometido se usan con frecuencia herramientas como hostname, uname -a, cat /proc/version o cat /etc/issue para identificar sistema y kernel; ps, ss o netstat (aunque esté deprecado) para revisar procesos y conexiones; env para ver variables de entorno; id, cat /etc/passwd y cat /etc/shadow (si es legible) para datos de cuentas; history para revisar historial de comandos; ifconfig o ip a para interfaces de red; y find para localizar archivos y directorios interesantes.

Además de la enumeración manual, existen scripts específicos para automatizar el proceso en Linux que facilitan muchísimo la vida: LinPEAS, LinEnum, Linux Exploit Suggester, Linux Smart Enumeration o Linux Priv Checker, entre muchos otros. Suelen listar vulnerabilidades conocidas del kernel, binarios SUID peligrosos, configuraciones inseguras de sudo e incluso sugerir exploits concretos.

Vulnerabilidades críticas recientes: CrackArmor y CVE‑2026‑3888

En los últimos años se han identificado fallos especialmente peligrosos capaces de permitir una escalada a root en Ubuntu a partir de usuarios sin privilegios. Dos ejemplos relevantes son CrackArmor, un conjunto de vulnerabilidades en AppArmor, y la vulnerabilidad CVE‑2026‑3888 en componentes de administración del sistema.

CrackArmor agrupa varias fallas en la implementación de AppArmor dentro del kernel Linux (no en el diseño del sistema de control de acceso obligatorio), presentes por defecto en distros como Ubuntu, Debian o SUSE. Estas vulnerabilidades permiten a un atacante local sin privilegios evadir políticas de seguridad, romper el aislamiento de contenedores, provocar fallos del kernel y, sobre todo, escalar privilegios hasta root.

El vector principal de CrackArmor pasa por la manipulación de pseudoarchivos bajo /sys/kernel/security/apparmor/ y por el uso de herramientas privilegiadas como proxies (sudo, postfix y otras). Entre las debilidades técnicas se mencionan problemas como confused deputy, use-after-free y bypass de KASLR, que combinados hacen posible cargar o eliminar perfiles de AppArmor, alterar la memoria del kernel y escapar de namespaces en entornos de contenedores.

El impacto estimado es enorme: se calcula que más de 12 millones de sistemas Linux podrían estar afectados, incluyendo servidores empresariales, entornos Kubernetes, cloud pública y dispositivos IoT. Aunque, eso sí, la explotación requiere acceso local previo: no es un fallo remoto, sino un vector post‑explotación prioritario.

La mitigación recomendada pasa por aplicar parches de kernel en cuanto estén disponibles, monitorizar accesos a /sys/kernel/security/apparmor/, revisar el uso de herramientas con privilegios, restringir la creación de user namespaces si no son necesarios y auditar perfiles activos de AppArmor, incrementando el logging y la detección de comportamientos anómalos.

En paralelo, la vulnerabilidad CVE‑2026‑3888 afecta de forma directa al ecosistema Ubuntu, comprometiendo versiones como Ubuntu 20.04 LTS, 22.04 LTS y algunas variantes con soporte comercial. Se trata de un fallo en cómo ciertos servicios del sistema interactúan con archivos temporales y procesos privilegiados, debido a validaciones de permisos insuficientes.

El truco de explotación típico consiste en manipular archivos temporales, enlaces simbólicos o condiciones de carrera para que un proceso con privilegios termine ejecutando comandos del atacante como root. Técnicas como la creación de symlinks maliciosos, el abuso de condiciones de carrera en la gestión de permisos y la inyección de comandos arbitrarios permiten usar a ese proceso privilegiado como trampolín.

Las consecuencias van más allá del host afectado: una vez obtenidos privilegios de administrador en un servidor Ubuntu vulnerable, un atacante podría exfiltrar datos sensibles, comprometer contenedores Docker, extender el ataque a orquestadores como Kubernetes u OpenStack o sabotear servicios muy críticos para el negocio.

Canonical reaccionó liberando parches que refuerzan los mecanismos de comprobación de permisos y el manejo de archivos temporales. Además de aplicar estas actualizaciones con urgencia, es recomendable limitar el acceso local a sistemas críticos, habilitar un monitoreo estricto de operaciones realizadas como root, aislar procesos especialmente sensibles y activar un registro avanzado para detectar posibles intentos de explotación.

En paralelo, y dado que muchas defensas se basan en aislamiento, no está de más revisar mecanismos como contenedores y jaulas: en algunos escenarios una vulnerabilidad puede permitir romper el aislamiento de contenedores o evadir otras medidas, como una jaula chroot, lo que facilita la escalada a root y la persistencia.

Técnicas prácticas de escalada a root en Ubuntu

Más allá de vulnerabilidades específicas, en escenarios de pentesting o laboratorios es habitual aprovechar configuraciones débiles o funcionalidades legítimas mal usadas para escalar privilegios en Ubuntu. Veamos algunas de las técnicas más comunes.

Una de las primeras comprobaciones al obtener un shell con pocos privilegios es revisar qué puedes ejecutar con sudo sin conocer otras contraseñas. El comando sudo -l muestra la lista de programas que el usuario actual está autorizado a ejecutar, a veces con la opción NOPASSWD que permite hacerlo sin que se solicite la contraseña.

Desde ahí, muchas escaladas se apoyan en proyectos como GTFOBins, que documentan cómo convertir ciertos binarios en shells interactivos cuando se ejecutan como root. Ejemplos clásicos son less, find, nano, nmap o incluso editores como vim y view, que gracias a sus funciones internas permiten lanzar /bin/bash con privilegios elevados.

Otra vía importante son los binarios con bit SUID (SetUID) o SetGID habilitado. Se trata de ejecutables que corren con los permisos de su propietario (a menudo root), aunque los lance un usuario normal. En condiciones normales esto se usa para tareas muy específicas, pero si un binario SUID es vulnerable o está mal programado puede convertirse en una autopista a root. Con find / -perm -4000 2>/dev/null, por ejemplo, se puede enumerar rápidamente ejecutables con SUID.

Algo similar ocurre con las capacidades de Linux (capabilities), que permiten otorgar a binarios concretos permisos muy precisos sin darles todo el poder de root. La herramienta getcap -r / 2>/dev/null ayuda a descubrir ejecutables con capacidades asignadas; si alguna de esas capacidades permite, por ejemplo, manipular la red o cargar módulos, puede ser posible abusarla para escalar privilegios.

Los trabajos cron representan otra fuente habitual de problemas. Si un cron job perteneciente a root ejecuta periódicamente un script ubicado en un directorio donde un usuario sin privilegios tiene permisos de escritura, bastará con modificar ese script para que lance una shell root, copie archivos o agregue una cuenta administrativa. Revisar /etc/crontab, /etc/cron.* y crontabs de usuarios ayuda a detectar estas situaciones.

El PATH también puede jugar malas pasadas. Si en el PATH de un proceso que se ejecuta como root hay un directorio escribible por otros usuarios, se puede “secuestrar” el nombre de un binario común (por ejemplo, ls o cp) y colocar un script malicioso en dicho directorio. Al ejecutarse el comando sin ruta absoluta, el sistema podría levantar el script del atacante en lugar del binario legítimo.

Los entornos NFS (Network File System) ofrecen otro ángulo interesante. Si se exportan recursos compartidos con opciones inseguras como no_root_squash, un atacante puede montar el recurso en su propia máquina, crear binarios SUID como root y, al volver al host objetivo, ejecutarlos con permisos elevados. Por eso es tan importante revisar el contenido de /etc/exports y las opciones concretas de cada share.

No hay que olvidar, por último, la importancia de los archivos de configuración y los historiales. Archivos como .bash_history, scripts en /etc, claves SSH en ~/.ssh o configuraciones de servicios web y bases de datos pueden contener credenciales reutilizadas, rutas de scripts privilegiados y accesos a otros sistemas, facilitando movimientos laterales y futuras escaladas.

Kernel y exploits locales: escalada a root por vulnerabilidades

Una vez se tiene claro qué versión de kernel y distribución estás pisando, merece la pena comprobar si existen exploits públicos de escalada local para ese núcleo. Herramientas como Linux Exploit Suggester o búsquedas directas en exploit-db permiten localizar CVE que afecten a versiones concretas del kernel de Ubuntu.

El flujo típico en un escenario controlado suele ser: identificar la versión del kernel con uname -a; buscar la combinación de “Ubuntu versiónKernel CVE” en fuentes de confianza; descargar el exploit en la máquina atacante; transferirlo a la víctima usando, por ejemplo, un servidor HTTP simple en Python; compilarlo allí con gcc y ejecutarlo.

Este tipo de ataques hay que manejarlos con mucho cuidado en entornos reales, porque los exploits de kernel pueden dejar el sistema inestable o provocar un crash total. Además, en escenarios de producción y entornos corporativos es mucho más razonable apostar por la corrección: mantener el kernel actualizado, aplicar parches de Canonical con rapidez y usar herramientas de detección para alertar de intentos de explotación.

En cualquier caso, desde el punto de vista ofensivo y defensivo, los exploits locales de kernel siguen siendo una de las rutas más directas a root en Ubuntu cuando el sistema está desactualizado o carga módulos vulnerables.

En un entorno más amplio, cuando un host Ubuntu comprometido está dentro de un dominio o un entorno híbrido con Active Directory, escalar a root no solo permite controlar ese servidor, sino también captar tráfico, acceder a hashes NTLM, pivotar hacia controladores de dominio y, en general, abrir un abanico enorme de nuevas opciones de ataque o pruebas.

Al final, todo este conjunto de técnicas y vulnerabilidades ilustra por qué la escalada a root en Ubuntu es un tema tan delicado: es imprescindible para administrar y auditar correctamente sistemas Linux, pero también constituye uno de los objetivos prioritarios de cualquier atacante una vez que logra un primer acceso. Conocer a fondo cómo funciona sudo, qué fallos de configuración son peligrosos, qué vulnerabilidades recientes afectan al ecosistema Ubuntu y qué buenas prácticas minimizan riesgos es la mejor forma de moverse con seguridad entre la potencia del usuario root y las exigencias de un entorno actual de ciberseguridad.

Artículo relacionado:

Detectar rootkits con RootkitRevealer: guía práctica y completa

Isaac

Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.