Escalada de privilegios en Linux: vectores y endurecimiento para defensores

La escalada de privilegios es el momento en que un punto de apoyo limitado en un host Linux se convierte en control total. Para un equipo azul es una de las fases más determinantes de una intrusión: un atacante que aterriza como una cuenta de servicio sin privilegios y luego se convierte en root puede desactivar el registro, instalar persistencia y moverse lateralmente por todo el parque. Este artículo adopta un enfoque de entender para defender. Describimos cómo funciona la escalada a nivel conceptual, mapeamos las superficies que los atacantes sondean y luego dedicamos la mayor parte del tiempo a lo que importa a los defensores: la telemetría que revela los intentos de escalada y el endurecimiento que elimina la oportunidad de raíz.

Qué significa realmente la escalada de privilegios

En Linux, la autoridad se expresa mediante la identidad de usuario y grupo, el UID/GID efectivo con que se ejecuta un proceso y un conjunto de capacidades del núcleo de grano fino. Un proceso normalmente hereda los privilegios de la cuenta que lo lanzó. La escalada de privilegios es cualquier técnica que permite que el código se ejecute con más autoridad de la que se le concedió. Existen dos grandes familias. La escalada vertical pasa de un usuario con pocos privilegios a uno superior, normalmente a root. La escalada horizontal se desplaza lateralmente hacia otro usuario del mismo nivel de privilegio para alcanzar datos o sesiones. Ambas importan, pero la escalada vertical a root es la que más temen los defensores, porque root puede reescribir las reglas del sistema, incluidos los controles destinados a detectarlo.

El modelo mental clave para un defensor es que la escalada rara vez es un único exploit mágico. Casi siempre es el abuso de un mecanismo legítimo configurado con demasiada laxitud: un binario auxiliar con demasiado poder, una tarea programada que corre como usuario privilegiado, una cuenta de servicio que puede editar su propia configuración. Si comprende el mecanismo, puede tanto detectar su abuso como eliminar la configuración laxa.

Cómo funciona la escalada a alto nivel

Un atacante que ha aterrizado en un host realiza reconocimiento local para enumerar lo que la identidad actual puede alcanzar. Busca archivos que pueda escribir y que procesos privilegiados leerán o ejecutarán después, programas que corren con autoridad elevada pero aceptan entradas influidas por el atacante, y software obsoleto con fallos conocidos. La escalada en sí es el momento en que una entrada controlada por el atacante cruza un límite de confianza hacia un contexto privilegiado. Conceptualmente, cada vector es una variación de un mismo tema: una entrada de bajo privilegio que alcanza una ruta de ejecución de alto privilegio. Su tarea defensiva es encontrar esos puentes y eliminarlos o vigilarlos de cerca.

Vectores comunes y la superficie de ataque

El sudo mal configurado es el hallazgo más común en entornos reales. Cuando a una cuenta se le permite ejecutar comandos específicos como root, y uno de esos comandos puede abrir una shell, leer archivos arbitrarios o escribir en rutas sensibles, el límite se derrumba. Los comodines en las reglas de sudoers y las entradas NOPASSWD amplían aún más la superficie.

Los binarios SUID y SGID se ejecutan con los privilegios del propietario del archivo, sin importar quién los lance. Un programa SUID-root legítimo que pueda inducirse a ejecutar otro comando, o a leer y escribir archivos como root, se convierte en una palanca. La preocupación crece cuando binarios propios o de terceros llevan el bit SUID innecesariamente.

Las capacidades excesivas de Linux son un pariente más sutil. Un binario con cap_setuid, cap_dac_override o cap_sys_admin posee una porción del poder de root sin el bit SUID, y son fáciles de pasar por alto en una auditoría que solo revisa los modos de archivo.

Las tareas programadas como los trabajos cron, los temporizadores systemd y los scripts de inicio suelen ejecutarse como usuarios privilegiados. Si algún script que ejecutan, o algún directorio en la ruta hacia ese script, es escribible por un usuario menor, ese usuario puede influir en lo que ejecuta root. Los permisos débiles de archivos y servicios generalizan esto: una unidad de servicio escribible por todos, un archivo de configuración que un servicio lee al arrancar o un directorio de bibliotecas en la ruta de búsqueda de un binario privilegiado son todos puentes de bajo a alto.

La manipulación de PATH y del entorno aprovecha scripts privilegiados que llaman a programas auxiliares por nombre en lugar de por ruta absoluta; si un atacante puede influir en la ruta de búsqueda, el auxiliar se resuelve a su propio binario. Por último, las vulnerabilidades del núcleo y de servicios en software sin parchear dan escalada directa, y las malas configuraciones de contenedores y espacios de nombres, como un contenedor que corre como root con el sistema de archivos del host o el socket de Docker montado, permiten escapar al host.

Detección: la telemetría que revela la escalada

La fuente más valiosa es el marco de auditoría de Linux, auditd. Las reglas que vigilan execve, los cambios en /etc/sudoers y /etc/sudoers.d/, las escrituras bajo /etc/cron.* y /etc/systemd/, y el uso de las llamadas setuid, setreuid y capset convierten la escalada silenciosa en eventos registrados. Etiquete estas reglas con claves para que su SIEM pueda alertar sobre ellas. Una ráfaga repentina de enumeración — muchos eventos execve de id, sudo -l, find / -perm y lecturas de /etc/passwd en segundos — es una fuerte señal de comportamiento incluso antes de la escalada.

El núcleo emite un registro de auditoría cuando setuid eleva el privilegio. Correlacione esa transición a root con una línea base de qué servicios lo hacen legítimamente; un proceso inesperado que da el salto merece investigación inmediata. sudo escribe en el registro de autenticación, así que alerte sobre los fallos, sobre el uso de la ruta NOPASSWD por cuentas que no deberían tenerla y sobre cualquier comando ejecutado como root que luego abra un intérprete de shell. En el lado del EDR, busque cadenas padre-hijo sospechosas, por ejemplo un proceso de servidor web o base de datos que lanza bash, sh, python o nc, y una cuenta de servicio no interactiva que de repente obtiene un TTY interactivo.

La monitorización de integridad de archivos cierra el círculo. Alerte siempre que el bit SUID o SGID aparezca en un binario, siempre que cambien las capacidades de archivo y siempre que se modifiquen archivos de cron, unidades systemd o bibliotecas compartidas fuera de una ventana de cambio. Envíe todo esto de forma centralizada para que un atacante con nivel root que borre los registros locales no pueda eliminar las pruebas que ya generó.

Mitigación y endurecimiento: primero el mínimo privilegio

Cada decisión de endurecimiento fluye del mínimo privilegio. Audite sudoers y elimine los derechos generales: conceda comandos específicos a usuarios específicos, evite NOPASSWD salvo que una automatización de alcance reducido lo requiera, y nunca permita comandos que puedan abrir una shell o leer archivos arbitrarios a menos que esa sea la intención deliberada. Prefiera sudo con restricciones de argumentos antes que conceder una shell root interactiva. Revise estas reglas de forma programada, porque se acumulan con el tiempo como excepciones puntuales que nunca se retiran.

Ejecute los servicios como cuentas dedicadas y sin privilegios, una por servicio, de modo que comprometer una aplicación web no entregue al atacante una shell en la que confíe cualquier otro servicio. Use las directivas de sandboxing de systemd — NoNewPrivileges=yes, ProtectSystem=strict, PrivateTmp=yes y un CapabilityBoundingSet restrictivo — para reducir lo que un servicio comprometido puede hacer incluso antes de considerar la escalada.

Endurecimiento de sistema de archivos, SUID y capacidades

Inventaríe cada binario SUID y SGID de su flota y justifique cada uno. Retire el bit de todo lo que no lo necesite y trate un binario SUID inesperado como un incidente. Monte los sistemas de archivos que contienen datos escribibles por el usuario o temporales — /tmp, /var/tmp, /dev/shm y las particiones de home — con nosuid, nodev y, cuando sea práctico, noexec, para que un archivo SUID plantado simplemente no lleve su privilegio. Audite las capacidades de archivo con herramientas que las listen en todo el árbol, y prefiera las capacidades sobre SUID solo cuando pueda acotarlas estrictamente.

Bloquee los permisos de todo lo que consuma un proceso privilegiado: los directorios de cron, los archivos de unidad de systemd, la configuración de servicios y los directorios en la ruta de búsqueda de bibliotecas y ejecutables de cualquier binario privilegiado no deben ser escribibles por usuarios menores. En los scripts privilegiados, llame siempre a los auxiliares por ruta absoluta y restablezca el entorno, para que la manipulación de PATH no tenga nada a lo que aferrarse.

Núcleo, parcheo y control de acceso obligatorio

El parcheo oportuno elimina las vulnerabilidades del núcleo y de servicios que dan escalada directa; siga su exposición frente a una fuente de vulnerabilidades y priorice todo lo que tenga un fallo público de escalada local de privilegios. Más allá del parcheo, añada capas de control de acceso obligatorio. SELinux en modo enforcing o un perfil de AppArmor bien ajustado confina un proceso a lo que su rol requiere, de modo que incluso una escalada exitosa a root dentro de un dominio confinado no pueda reescribir libremente el sistema. Combine esto con endurecimiento del núcleo como kernel.yama.ptrace_scope, acceso restringido a dmesg y módulos del núcleo no usados desactivados para eliminar clases enteras de técnica.

Errores comunes que los defensores deben evitar

El primer error es tratar el endurecimiento como un proyecto único. Las reglas de sudo, los inventarios de SUID y los trabajos cron se desvían a medida que los sistemas cambian; sin una reauditoría periódica, la superficie vuelve a crecer en silencio. El segundo es vigilar solo firmas de exploits conocidas ignorando el comportamiento — la escalada por mala configuración no produce ninguna firma de exploit, solo una linaje de procesos anómalo y transiciones de privilegio. El tercero es guardar los registros solo en local, que un atacante con nivel root borra; centralice la telemetría para que sobreviva al compromiso del host. El cuarto es olvidar los contenedores: un contenedor que corre como root, recibe --privileged o monta el socket de Docker concede de hecho root en el host, así que aplique la misma disciplina de mínimo privilegio dentro de las imágenes.

Lista de verificación práctica de endurecimiento

Use esto como revisión recurrente. Mínimo privilegio: audite sudoers, elimine reglas generales y NOPASSWD, ejecute cada servicio como su propia cuenta sin privilegios. Sistema de archivos: inventaríe y minimice SUID/SGID, monte las particiones escribibles con nosuid,nodev,noexec, endurezca permisos en rutas de cron, systemd y configuración. Capacidades: audite las capacidades de archivo y elimine las innecesarias. Núcleo: parchee con cadencia, active SELinux o AppArmor en modo enforcing, aplique sysctls de endurecimiento del núcleo. Detección: despliegue reglas de auditd para setuid, sudoers, cron y capset; monitorice el linaje de procesos en el EDR; active la monitorización de integridad de archivos en rutas privilegiadas; envíe todos los registros a un almacén central que el host no alcance. Contenedores: ejecute como no root, elimine capacidades, nunca monte el socket de Docker en cargas no confiables.

Preguntas frecuentes

¿Es seguro eliminar los binarios SUID? Algunos binarios del sistema necesitan genuinamente el bit, como passwd. El enfoque seguro es inventariar cada archivo SUID, asignarlo a una necesidad justificada, retirar el bit de todo lo injustificado y probar primero en un entorno de staging. Un binario SUID inexplicable tiene muchas más probabilidades de haber sido plantado por un atacante que de ser legítimo.

Si ejecuto todo en contenedores, ¿estoy a salvo de la escalada de privilegios? No. Los contenedores son un límite, no una garantía. Un contenedor que corre como root con capacidades excesivas o un socket del host montado suele ser una ruta directa a root en el host. Trate la configuración de contenedores con el mismo rigor de mínimo privilegio que aplica a los hosts, y monitorice también la escalada dentro de los contenedores.

Conclusión

La escalada de privilegios en Linux no suele ser cuestión de exploits exóticos; es la consecuencia predecible de una configuración laxa acumulada — una regla de sudo demasiado amplia, un bit SUID perdido, una ruta de cron escribible, un núcleo sin parchear. Eso es una buena noticia para los defensores, porque significa que la superficie es enumerable y las correcciones son concretas. Combine un mínimo privilegio disciplinado, el endurecimiento del sistema de archivos y de capacidades, el parcheo oportuno y el control de acceso obligatorio para eliminar la oportunidad, y luego añada capas de auditd, monitorización de linaje de procesos en EDR y monitorización centralizada de integridad de archivos para atrapar lo que quede. Revisada con cadencia en lugar de tratarse como algo puntual, esta postura defensiva convierte la escalada de una inevitabilidad silenciosa en un evento ruidoso y detectable.