Labs

Ledgerroot

Repository leakage gives user access, and an unsafe sudo allowance on an interactive binary enables root.

Difficulty: Hard

Ledgerroot felt closer to a real internal environment than a puzzle box. I had to do more triage before the real escalation path became obvious, but the critical issue ended up being a ==red:dangerous sudo allowance==.

!![amber] This box punished assumptions and rewarded reading sudo semantics carefully.

Reconnaissance

nmap -sC -sV -Pn -p- 10.10.11.67 -oN nmap-ledgerroot.txt
Nmap scan report for 10.10.11.67
Host is up (0.12s latency).
Not shown: 65532 closed tcp ports (reset)

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.0p1 Ubuntu 1ubuntu8.6
80/tcp   open  http    nginx 1.22.1
3000/tcp open  http    Golang net/http server (Gitea)

I spent a few minutes checking default credentials on the Git service and got nowhere. Public repositories were the ==amber:better lead==.

I also checked whether the service leaked unauthenticated API metadata:

curl -s http://10.10.11.67:3000/api/v1/version
curl -sI http://10.10.11.67:3000/

That gave version context, but no direct auth bypass, so repo content review remained the best path.

Initial Access (Sanitized)

I reviewed accessible repository content and found deployment notes with sensitive values that mapped to a valid local account. This was the ==blue:foothold pivot==.

curl -s http://10.10.11.67:3000/explore/repos
... one repository exposed CI/deployment notes and credential references ...
devsvc@ledgerroot:~$ whoami
devsvc

After landing, I did a fast host triage to avoid tunnel vision:

id
hostnamectl
ls -lah /home/devsvc

Privilege Escalation (Sanitized but Insightful)

Local checks:

id
sudo -l
uid=1002(devsvc) gid=1002(devsvc) groups=1002(devsvc),27(sudo)

User devsvc may run the following commands on ledgerroot:
    (root) NOPASSWD: /usr/bin/journalctl

This looked restrictive, but interactive sudo-allowed programs can still be dangerous. I initially investigated writable unit files, which was a dead-end. The actual weakness was ==red:command execution boundary leakage== from pager behavior under privileged context.

Conceptually, this is a sudo policy issue: granting an interactive diagnostic tool without tight constraints can expose root-level escape paths.

I validated the dead-end branch before pivoting:

find /etc/systemd/system -maxdepth 2 -type f -writable 2>/dev/null
find /usr/lib/systemd/system -maxdepth 2 -type f -writable 2>/dev/null

No writable units were present for the current user, which reinforced that sudo policy was the true misconfiguration.

Proof (Sanitized)

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

Key Takeaways

  • Sudo rules must account for interactive behavior, not only binary name.
  • Read-only looking diagnostic tools can still break privilege boundaries.
  • If one local path stalls, return to sudo -l and reason from allowed command semantics.
  • Repo hygiene is part of attack surface management.