Skip to content

En un host Linux encuentras un archivo escribible por todos, propiedad de root y con el bit SUID activado. ¿Cuál es el riesgo y tu acción?

Respuesta breve

Un binario SUID-root se ejecuta con privilegios de root, y si es escribible por todos un atacante puede reemplazarlo o modificarlo para ejecutar código arbitrario como root — una vía clásica de escalada de privilegios local. Retira el bit SUID, corrige el propietario y los permisos, e investiga cómo apareció esta mala configuración, ya que puede indicar un compromiso. Cifrar el archivo deja intacta la ruta ejecutable, y renombrarlo solo traslada el problema sin eliminar la escalada. Ninguna de estas opciones aborda la causa raíz.

Un binario SUID (Set User ID) se ejecuta con los privilegios de su propietario, no del usuario que lo lanzó. Cuando el propietario es root, todo el código que ese binario ejecuta corre como root. Eso es aceptable para un pequeño conjunto de herramientas del sistema cuidadosamente auditadas. Se vuelve catastrófico en el momento en que el archivo es además escribible por todos.

Por qué esto es escalada de privilegios

Si un archivo es -rwsrwxrwx root root, cualquier usuario local puede sobrescribir su contenido. Un atacante simplemente reemplaza el binario (o, en el caso de un script, lo edita) con una carga útil de su elección — un shell, un comando que añade una clave SSH a ~/.ssh/authorized_keys, o una conexión inversa. La próxima vez que se ejecute con el bit SUID, esa carga útil se ejecuta como root. El atacante ha pasado de un shell sin privilegios al control total como root sin explotar ningún error de corrupción de memoria. Es una de las primitivas de escalada de privilegios local más fiables en Linux.

La acción correcta

  • Retira el bit SUID (chmod u-s) salvo que sea genuinamente necesario.
  • Corrige el propietario y los permisos para que el archivo no sea escribible por grupo ni por otros (chmod o-w,g-w).
  • Investiga la causa raíz. Un archivo SUID propiedad de root y escribible por todos rara vez aparece por accidente. Comprueba la integridad de los paquetes, los cambios recientes, y si un atacante lo creó como puerta trasera o mecanismo de persistencia. Trátalo como un posible indicador de compromiso, no como un simple problema de higiene.

Por qué fallan los distractores

  • «Sin riesgo» es sencillamente falso — es una vía de escalada de manual y refleja una peligrosa falta de criterio.
  • Cifrar el archivo no impide que se ejecute como SUID-root, y un atacante aún puede reemplazarlo; no has resuelto nada.
  • Renombrarlo deja el mismo binario SUID escribible en disco bajo un nuevo nombre, igual de explotable para la escalada.

Qué está evaluando el entrevistador

Si comprendes realmente cómo funciona el SUID, sabes conectar «escribible por todos + SUID-root» con la ejecución de código arbitrario como root, y pasas instintivamente de corregir el archivo a preguntarte cómo llegó ahí — el reflejo de respuesta a incidentes que distingue a un ingeniero de nivel medio de uno junior.

Posibles preguntas de seguimiento

  • ¿Cómo enumerarías todos los binarios SUID/SGID de un host, y cuáles son los esperados?
  • Si este binario no fuera escribible pero fuera una entrada conocida de GTFOBins, ¿en qué se diferenciaría la escalada?
  • ¿Qué controles de registro o de integridad habrían detectado antes el cambio de permisos?

Fuentes

Certificaciones

Consigue 100 preguntas de entrevista de ciberseguridad + respuestas

Déjanos tu correo y te enviaremos el pack en PDF gratuito y el mazo de flashcards.

Sin spam. Cancela tu suscripción cuando quieras.