chrono picoCTF 2023 Solution

Description

1. Step 1

   Read the crontab

   Observation

   I noticed the challenge name 'chrono' directly references cron, the Linux task scheduler, which suggested the flag would be stored inside a crontab file; /etc/crontab is the system-wide crontab readable by any user and the most direct place to check first.

   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 only shows jobs registered to the current unprivileged user (picoplayer), which returns an empty list or 'no crontab for picoplayer'. The flag is stored in the system-wide crontab at /etc/crontab, which is owned by root and must be read with cat /etc/crontab rather than the per-user crontab 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, respectively. While they are worth inspecting in privilege-escalation scenarios, the flag in this challenge is embedded directly in the main system crontab at /etc/crontab. Starting with cat /etc/crontab is the shortest path because that single file contains 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.