Cron Job Abuse
Les cron jobs peuvent également être configurés pour s'exécuter une seule fois (par ex. au démarrage). Ils sont généralement utilisés pour des tâches d'administration telles que les sauvegardes, le nettoyage de répertoires, etc. La commande crontab permet de créer un fichier cron qui sera exécuté par le démon cron selon l'ordonnancement spécifié. Lorsqu'il est créé, le fichier cron est placé dans /var/spool/cron pour l'utilisateur concerné. Chaque entrée dans un fichier crontab nécessite six éléments dans l'ordre suivant : minutes, heures, jours, mois, jours de la semaine, commande. Par exemple, l'entrée 0 */12 * * * /home/admin/backup.sh s'exécutera toutes les 12 heures.
🔎 Droits et risques
Le crontab de root est presque toujours modifiable uniquement par root ou un utilisateur disposant de privilèges sudo complets ; cependant, il peut toujours être abusé. On peut trouver un script world-writable exécuté par root et, même si l'on ne peut pas lire le crontab pour connaître la planification exacte, on peut souvent deviner la fréquence d'exécution (par ex. un script de backup qui crée un .tar.gz toutes les 12 heures). Dans ce cas, il est possible d'ajouter une commande à la fin du script (par ex. un one-liner de reverse shell) et celle-ci s'exécutera lors de la prochaine exécution du cron job.
Certaines applications créent des fichiers cron dans /etc/cron.d et ceux-ci peuvent être mal configurés pour permettre à un utilisateur non-root de les modifier.
🧭 Rechercher des fichiers/modifiables intéressants
Commencez par lister les fichiers et répertoires accessibles en écriture par n'importe qui :
# Rechercher fichiers world-writable
find / -path /proc -prune -o -type f -perm -o+w 2>/dev/null
/etc/cron.daily/backup
/dmz-backups/backup.sh
/proc
/sys/fs/cgroup/memory/init.scope/cgroup.event_control
[...]
/home/backupsvc/backup.shExemple concret présent sur la machine cible (commande ci‑dessus) :
/dmz-backups/backup.shapparaît comme fichier modifiable et/etc/cron.daily/backupégalement.
🛠️ Examiner un répertoire de backup suspect
Vérifiez le répertoire pour repérer des fichiers créés fréquemment (indices d'une tâche planifiée) :
Observation : de nombreux fichiers d'archive (
www-backup-...tgz) semblent être générés à intervalles réguliers très rapprochés — potentielle erreur de planification (ex. cron configuré toutes les 3 minutes au lieu de toutes les 3 heures). De plus,backup.shest world-writable et appartient àroot— condition idéale pour un détournement.
🔍 Confirmer les tâches cron — utilisation de pspy
On peut confirmer l'exécution des cron jobs sans privilèges root en utilisant pspy, un outil qui scrute procfs et affiche les commandes/exécutions système observées.
Avec pspy, on peut repérer des lignes indiquant que
cronexécute/dmz-backups/backup.shet quetarest appelé pour archiver/var/www/html.
🧾 Inspecter le script de backup
Affichez le contenu du script pour comprendre son fonctionnement :
Contenu typique du script :
Le script définit un répertoire source et destination, construit un nom de fichier basé sur la date/heure, puis archive le répertoire web.
🪄 Détournement — ajouter un reverse shell (exemple pédagogique)
Si le script est modifiable par un utilisateur non privilégié et s'exécute en tant que root, on peut ajouter une ligne à la fin du script pour obtenir une connexion shell en tant que root lorsque la tâche s'exécute. Toujours faire une copie du script avant modification pour éviter d'endommager le fiabilité du système :
Script modifié (extrait) :
📡 Mise en place d'une écoute locale (sur l'attaquant)
Sur votre machine d'attaque, préparez une écoute à l'aide de netcat pour recevoir la connexion :
Ensuite, attendez que le cron job s'exécute — si le script est lancé en tant que root, la connexion vous donnera un shell root.
⚠️ Notes de sécurité et bonnes pratiques
Ne modifiez pas les scripts en production sans autorisation. Les exemples ci‑dessus sont à usage pédagogique uniquement.
Toujours effectuer une copie de sauvegarde du script avant toute modification.
Vérifiez la fréquence d'exécution des cron jobs (
crontab -l, fichiers dans/etc/cron.d,/etc/cron.daily, etc.) pour détecter des périodicités anormalement courtes.Restreindre les permissions des scripts exécutés par
root: ils ne doivent pas être world-writable.Surveiller et auditer
/etc/cron.det les crontabs des services pour détecter des configurations dangereuses.
📚 Ressources utiles
SSH to 10.129.67.227 (ACADEMY-LPE-NIX02) with user "htb-student" and password "Academy_LLPE!"
Connect to the target system and escalate privileges by abusing the misconfigured cron job. Submit the contents of the flag.txt file in the /root/cron_abuse directory.
Nous nous connectons dans un premier temps à notre cible via ssh :
Une fois connectés, nous analysons les sifférents fichier présents dans les crontab :
Nous pouvons alors observer la présence de deux fichier .sh, autrement dit, ce sont des script executés que nous pouvons modifier afin d'obtenir un accès distant via un shell à notre cible :
Voici le contenu modifié de backup.sh :
Nous ouvrons alors un port en écoute sur notre poste attaquant et attendons l'execution de la crontab afin d'obtenir un reverse shell :
Une fois le reverse shell obtenu, nous pouvons rechercher le flag :
Nous obtenons donc le flag associé à ce cours :
Last updated