chrono picoCTF 2023 Solution

Description

1. Step 1Read the crontab

   Observation

   The name points straight at cron, the Linux task scheduler, so the flag is likely in a crontab. /etc/crontab is the system-wide one, readable by any user, and the first place to look.

   After SSH-ing in, check the main system crontab. The flag is embedded directly in a cron job entry in /etc/crontab. Running cat /etc/crontab displays all scheduled jobs, and the flag is printed right there as a scheduled job comment or command.

   bash

   cat /etc/crontab

   Copied!

   Expected output

   picoCTF{Sch3DUL7NG_T45K3_L1NUX_...}

   For the broader Linux enumeration toolkit (find, ls, cat, grep, sudo -l, getcap), see Linux CLI for CTF.

   What didn't work first

   Tried: Running crontab -l to list cron jobs instead of reading /etc/crontab directly

   crontab -l shows only the jobs registered to the current unprivileged user, which here means an empty list. The flag is in the system-wide crontab at /etc/crontab, owned by root and read with cat rather than the per-user command.

   Tried: Searching /etc/cron.d/ and /var/spool/cron/crontabs/ for the flag before checking /etc/crontab

   Those directories hold supplemental and per-user crontabs, worth inspecting during privilege escalation. Here the flag sits directly in the main system crontab. Starting there is shortest, because that one file carries all system-level scheduled jobs on most Debian-based installs.

   Learn more

   Cron is the Unix task scheduler. It reads crontab files - plain text tables where each line specifies a time pattern and a command - and runs those commands at the scheduled times. System-wide crontabs live in /etc/cron.d/, /etc/crontab, and the /etc/cron.{hourly,daily,weekly,monthly} directories; per-user ones are stored in /var/spool/cron/crontabs/.

   In CTF forensics and privilege-escalation scenarios, cron is worth examining because: (1) scripts invoked by root cron jobs may be writable by a lower-privileged user, allowing code execution as root; (2) cron jobs often log artifacts (temporary files, output files) that contain sensitive data; (3) poorly written cron scripts can expose credentials or intermediate results in world-readable locations - exactly as happened here, where the flag sits in the main system crontab at /etc/crontab.

   Use crontab -l to list the current user's jobs and cat /etc/crontab to inspect system jobs. Tools like pspy can monitor process creation in real time to catch cron jobs that run without appearing in static files.

   The crontab time format has five fields before the command: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7, where both 0 and 7 represent Sunday). Wildcards (*) match every value; step values (*/5) run every fifth unit; ranges (1-5) specify spans. The shorthand @reboot runs a command once at startup - a common persistence mechanism in Linux malware because it survives reboots without modifying any obvious system files.

   In CTF privilege escalation, a writable cron script executed by root is a reliable escalation path. If a root cron job calls /tmp/cleanup.sh and the current user can write to /tmp/, replacing that script with a reverse shell or SUID-setting command gives root access on the next cron trigger. The tool LinPEAS automatically checks for writable cron scripts as part of its privilege escalation audit.

Flag

The flag appears directly inside the main system crontab file at /etc/crontab. The trailing hex suffix is generated per instance.