Labs

Clockforge

A credential leak leads to user access, followed by cron exploitation through writable script permissions.

Difficulty: Medium

Clockforge was one of those labs where nothing looked dramatic, but the operating model was fragile. The root cause was not a single exploit bug, it was ==red:bad ownership around scheduled jobs==.

!![amber] This one was all about permissions discipline, not fancy exploitation.

Reconnaissance

nmap -sC -sV -Pn -p- 10.10.11.53 -oN nmap-clockforge.txt
Nmap scan report for 10.10.11.53
Host is up (0.09s latency).
Not shown: 65533 closed tcp ports (reset)

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.4p1 Debian 5+deb11u3
80/tcp open  http    Apache httpd 2.4.54 ((Debian))

Web content looked fairly static. I almost moved on, but a ==amber:hidden VCS path== appeared during enumeration.

Before going deeper, I confirmed there were no obvious file upload or debug endpoints:

curl -i http://10.10.11.53/
curl -i http://10.10.11.53/server-status

/server-status was properly denied, so I kept focus on the leaked repository.

Initial Access (Sanitized)

gobuster dir -u http://10.10.11.53 -w /usr/share/wordlists/dirb/common.txt -x txt,bak,git
/.git/HEAD            (Status: 200)
/assets/              (Status: 301)
/notes.txt            (Status: 200)

After rebuilding repository history from exposed metadata, I recovered credentials that worked over SSH. That was the ==blue:initial access pivot==.

otto@clockforge:~$ whoami
otto

I immediately checked user context and writable paths:

id
find /opt -maxdepth 3 -type f -writable 2>/dev/null

That quickly highlighted the backup script path later used for escalation.

Privilege Escalation (Sanitized but Insightful)

I checked sudo -l first, then moved to scheduled tasks.

sudo -l
cat /etc/crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

* * * * * root /opt/backup/rotate.sh

Then I validated permissions and groups:

ls -l /opt/backup/rotate.sh
id
-rwxrwxr-x 1 root devops 412 Jan 12 09:14 /opt/backup/rotate.sh
uid=1001(otto) gid=1001(otto) groups=1001(otto),1002(devops)

This is exploitable because root runs the script every minute, but the current user can modify it through devops group write access. At first I thought this might be a dead-end if cron was disabled, but process checks confirmed cron was active.

!![red] Root cron + writable script is a direct privilege boundary break.

The escalation itself was performed by modifying the trusted script in a controlled way and waiting for execution.

I also verified the scheduler state to avoid assuming timing behavior:

ps aux | grep -E "cron|crond" | grep -v grep
systemctl status cron --no-pager

With cron active and script write access confirmed, the privileged execution path was reliable.

Proof (Sanitized)

whoami
root
cat /root/root.txt
flag output intentionally omitted to preserve the lab challenge

Key Takeaways

  • Cron plus writable script ownership is a critical privilege boundary failure.
  • Group permissions can be enough for full compromise.
  • sudo -l being clean does not reduce the need for cron checks.
  • Fast wins often come from ownership and execution flow, not memory corruption.