cron, systemd y mecanismos de persistencia

1Por qué importa

Cuando alguien consigue ejecutar como root, su siguiente problema es que ese acceso es frágil: un reinicio, una sesión cerrada, un proceso que muere, y lo pierde. La solución que busca es persistencia: un sitio desde el que su código vuelva a arrancar solo. Las tareas programadas son el sitio ideal, porque su razón de existir es precisamente ejecutarse solas y de forma repetida. Una línea en /etc/cron.d o una unit de systemd le devuelve el acceso en cada ciclo, sin que tenga que volver a entrar.

Pero el problema empieza mucho antes del atacante, en el despliegue. Una tarea de root que ejecuta un script escribible por un usuario cualquiera es una escalada de privilegios esperando a ocurrir: ese usuario reescribe el script y, en el siguiente ciclo, root ejecuta lo que él quiera. Lo mismo con el directorio que contiene el script, o con el propio archivo de la tarea. La lección de diseño es que todo lo que una tarea privilegiada ejecuta forma parte de su frontera de confianza, y esa frontera se define con permisos, en el momento de configurar, no cuando ya hay un incidente.

2Conceptos

3Explicación profunda

cron ejecuta comandos a horas fijas. Cada usuario tiene su crontab (crontab -l), y el sistema tiene los suyos: /etc/crontab y los fragmentos de /etc/cron.d. La diferencia clave de las tareas del sistema es que declaran con qué usuario se ejecutan. Una línea en /etc/cron.d/backup como 0 * * * * root /opt/tareas/backup.sh dice: cada hora, como root, ejecuta ese script. Todo el peso de seguridad recae en ese script y en dónde vive: si /opt/tareas/backup.sh es escribible por un usuario cualquiera, ese usuario controla lo que root ejecutará. No importa que el archivo de cron.d sea perfecto; lo que se ejecuta es el script.

Los permisos que hay que mirar son tres, y la gente suele mirar solo el primero. Uno, el script: no debe ser escribible por otros (nada de 666 ni 777). Dos, el directorio que lo contiene: si el directorio es escribible, da igual el permiso del archivo, porque un usuario puede borrarlo y poner otro en su lugar —borrar es un permiso del directorio, como viste en la lección de permisos—. Tres, el archivo de la tarea (/etc/cron.d/… o la unit): si es escribible, se cambia el comando entero. Los tres tienen que ser propiedad de root y cerrados a la escritura ajena.

systemd reemplaza a cron en la mayoría de sistemas modernos y traslada el mismo problema a otros archivos. Una unit .service tiene una línea ExecStart= con el binario o script a ejecutar, y un .timer la dispara según OnCalendar=. Las mismas preguntas: ¿es la unit escribible por un usuario sin privilegios? ¿lo es el binario al que apunta ExecStart? ¿lo es su directorio? Un ExecStart=/opt/app/run.sh donde run.sh es escribible por otros es exactamente el mismo fallo que en cron. Y como systemd arranca las units al inicio y las reinicia, un servicio comprometido es una persistencia especialmente cómoda para un atacante.

La otra cara de systemd es que trae herramientas de confinamiento que cron no tenía. Una unit puede declarar User= para no correr como root, NoNewPrivileges=yes para que el proceso no pueda ganar privilegios, ProtectSystem=strict para montar el sistema de solo lectura, ProtectHome=yes, PrivateTmp=yes y muchas más. Bien usadas, convierten un servicio en algo que, aunque se comprometa, casi no puede tocar nada. Esa es la forma moderna de aplicar mínimo privilegio a una tarea: no solo permisos de archivo correctos, sino un servicio confinado por el propio systemd.

4Ejemplo sencillo

# Una nota pegada en la nevera que alguien cumple cada mañana

En la nevera hay una nota (la tarea): "cada manana, el conserje
(root) hace lo que diga este papel".

Si el papel esta en un cajon cerrado que solo el conserje abre
(script de root, no escribible por otros), bien: hace lo previsto.

Si el papel esta pegado en un tablon publico (script world-writable),
cualquiera tacha la instruccion y escribe otra. Manana el conserje,
con sus llaves, cumplira la instruccion NUEVA sin dudar.

Y como lo hace CADA manana, quien cambio el papel no necesita volver:
la nota se ejecuta sola, para siempre. Eso es persistencia.

5Ejemplo técnico

Los sitios donde viven las tareas, y qué mirar en cada uno:

El inventario que hay que saber correr. Lista las tareas y, sobre todo, comprueba los permisos de lo que ejecutan:

# tareas de cron del sistema y sus scripts
cat /etc/crontab /etc/cron.d/* 2>/dev/null

# timers activos de systemd y la unit que disparan
systemctl list-timers --all

# lo que de verdad importa: ¿algo que ejecuta root es escribible por otros?
find /etc/cron.d /opt /usr/local -perm -0002 -type f 2>/dev/null

6Diagrama

flowchart LR
    U[becario · sin privilegios] -->|reescribe| S[backup.sh · 0777]
    C[cron de root · cada ciclo] -->|lee| S
    C -->|ejecuta como root| P{{persistencia}}

7Código

Asegurar una tarea es dejar sus tres piezas en manos de root y cerradas a la escritura ajena, y confinar el servicio si es systemd. Primero, los permisos:

# el script, el directorio y el archivo de la tarea: root y sin escritura ajena
chown root:root /opt/tareas /opt/tareas/backup.sh /etc/cron.d/backup
chmod 0755 /opt/tareas
chmod 0755 /opt/tareas/backup.sh
chmod 0644 /etc/cron.d/backup

Y, en systemd, una unit confinada. Estas directivas hacen que aunque el servicio se comprometa, apenas pueda tocar el sistema:

# /etc/systemd/system/backup.service
[Service]
ExecStart=/opt/tareas/backup.sh
User=servicio
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/backups

NoNewPrivileges=yes impide que el proceso gane privilegios (por SUID, por ejemplo); ProtectSystem=strict monta casi todo de solo lectura y solo deja escribir en ReadWritePaths. Es mínimo privilegio aplicado a una tarea: corre como un usuario acotado y solo puede tocar lo que necesita.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

[Service]
ExecStart=/opt/tareas/backup.sh
User=servicio
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/backups

echo 'id -un > /tmp/quien_ejecuta' >> /opt/tareas/backup.sh
# espera <=15s
ls -l /tmp/quien_ejecuta   # dueño: root
cat  /tmp/quien_ejecuta    # root

# debe fallar ahora: si escribe, la defensa no sirvio
echo malicia >> /opt/tareas/backup.sh 2>/dev/null \
  && echo "FALLA: aun escribe" || echo "OK: sin escritura"

13Preguntas de comprensión

14Reto adicional

# archivos de tarea escribibles por otros
find /etc/crontab /etc/cron.d -perm -0002 -type f 2>/dev/null

# scripts y directorios bajo rutas de servicio, escribibles por otros
find /opt /usr/local/bin -perm -0002 \( -type f -o -type d \) 2>/dev/null

15Resumen

16Mis notas

17Recursos