CTF Lab Writeup: ABSOLUTE NANO

PicoCTF Challenge | Difficulty: Beginner-Intermediate | Category: Privilege Escalation

---

1. Executive Summary

Challenge Name: ABSOLUTE NANO
Platform: PicoCTF
Category: Linux Privilege Escalation
Core Vulnerability: Sudo Misconfiguration — Unrestricted write access to /etc/sudoers via nano
Flag: picoCTF{n4n0_411_7h3_w4y_3dc38f6f}

This challenge teaches one of the most fundamental and real-world-relevant privilege escalation techniques in Linux security: abusing misconfigured sudo permissions. The attacker is provided with SSH access to a remote Linux machine as a low-privilege user. The flag is stored in a file readable only by root. However, through careful enumeration of sudo permissions, we discover that nano can be used as root to edit the system's own security policy file — effectively allowing us to grant ourselves unrestricted administrative access.

💡 Big Picture Takeaway: Just because a user is given access to a "simple" tool like a text editor doesn't mean it's safe. If that editor can modify system configuration files, the user effectively has root.

---

2. Reconnaissance & Enumeration

2.1 Establishing the SSH Connection

The challenge provides us with:

• Host: crystal-peak.picoctf.net
• Port: 50662
• User: ctf-player
• Password: e031ef27

We connect using:

ssh -p 50662 [e-mail]

Breaking Down the Command:

Component	Meaning
ssh	Secure Shell — encrypted remote login protocol
-p 50662	Specifies a non-standard port (default SSH is port 22). The challenge uses a custom port because it runs alongside other CTF instances.
[e-mail]	Username ctf-player at the given hostname

🧠 Why SSH and not something else? The challenge explicitly provides SSH credentials. SSH is the standard, secure method for remote Linux shell access. There is no web interface or other service mentioned, so we go directly to the shell.

---

2.2 Initial Directory Enumeration

Once logged in, the very first thing any good penetration tester or CTF player does is understand their immediate environment. We run:

ls -al

Breaking Down the Command:

Flag	Meaning
ls	Lists directory contents
-a	Shows all files, including hidden ones (files starting with .)
-l	Long format — shows permissions, owner, group, size, and modification date

Output:

total 16
drwxr-xr-x 1 ctf-player ctf-player   20 Jun  5 07:48 .
drwxr-xr-x 1 root       root         24 Feb  4 22:26 ..
-rw-r--r-- 1 ctf-player ctf-player  220 Feb 25  2020 .bash_logout
-rw-r--r-- 1 ctf-player ctf-player 3771 Feb 25  2020 .bashrc
drwx------ 2 ctf-player ctf-player   34 Jun  5 07:48 .cache
-rw-r--r-- 1 ctf-player ctf-player  807 Feb  25 2020 .profile
-r--r----- 1 root       root         35 Feb  4 22:26 flag.txt

Analyzing the Output — The Critical Line:

-r--r----- 1 root root 35 Feb 4 22:26 flag.txt

Let's decode those permissions character by character:

- r -- r -- ---
│ │    │    └── Others: NO permissions
│ │    └─────── Group (root): Read only
│ └──────────── Owner (root): Read only
└────────────── Regular file (not a directory)

🚫 What this means for us: Our user ctf-player is neither root nor in the root group. We fall into the "Others" category, which has zero permissions. We cannot cat, less, more, or open flag.txt in any conventional way.

The Road Not Taken:

You might be tempted to try cat flag.txt immediately. Go ahead — it teaches you something. You'll get Permission denied. This confirms we need to escalate our privileges before we can read the file. Brute-forcing the password, looking for SUID binaries, or checking for cron jobs are all valid escalation vectors, but we haven't enumerated our sudo rights yet — which is always the fastest and most targeted check.

---

2.3 Sudo Privilege Enumeration

The single most important enumeration command on a Linux CTF machine (and in real-world penetration testing) is:

sudo -l

Breaking Down the Command:

Component	Meaning
sudo	"Superuser Do" — runs commands with elevated privileges
-l	List — shows what commands the current user is permitted to run via sudo

Output:

Matching Defaults entries for ctf-player on challenge:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

User ctf-player may run the following commands on challenge:
    (ALL) NOPASSWD: /bin/nano /etc/sudoers

This output is the KEY to the entire challenge. Let's dissect it completely:

(ALL) NOPASSWD: /bin/nano /etc/sudoers
 │        │         │           └── The specific FILE nano is allowed to open
 │        │         └────────────── The specific BINARY allowed to run
 │        └──────────────────────── No password required to execute this
 └───────────────────────────────── Can run AS any user (including root)

🔑 Translation: The user ctf-player can run nano as root, without a password, but only to open the file /etc/sudoers.

What is /etc/sudoers?
The /etc/sudoers file is the master security policy document for the Linux sudo system. It defines:

• Which users can run which commands
• Whether a password is required
• Which users they can impersonate

⚠️ The Critical Insight: If you can edit the security policy as root, you can write any rule you want into it — including granting yourself unlimited access. This is like being given a pen and told you can only use it to fill in your name on a legal contract... but then discovering no one is watching what you write.

---

3. Initial Foothold & Privilege Escalation

📝 Note: In this challenge, the initial foothold (SSH access) and privilege escalation are tightly coupled. The "foothold" is the SSH shell, and the escalation happens immediately after through sudo abuse.

3.1 Opening the Sudoers File with Nano

We execute our allowed sudo command:

sudo /bin/nano /etc/sudoers

Why the full path /bin/nano and not just nano?
The sudo rule specifies the exact binary path /bin/nano. Using just nano might resolve to a different path depending on the environment and could be rejected by sudo. Always match the exact path specified in the sudo -l output.

The sudoers file contents we see:

# This file MUST be edited with the 'visudo' command as root.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="..."

# User privilege specification
root    ALL=(ALL:ALL) ALL

🧠 Understanding the existing rule format:

root  ALL=(ALL:ALL)  ALL
 │     │    │    │    └── Can run ALL commands
 │     │    │    └─────── As any GROUP
 │     │    └──────────── As any USER
 │     └───────────────── On ALL hosts
 └─────────────────────── Applied to user: root

---

3.2 Modifying the Sudoers File

Inside the nano editor, we navigate to the bottom of the file using the arrow keys and add the following line:

ctf-player ALL=(ALL:ALL) NOPASSWD: ALL

What this line does:

Component	Meaning
ctf-player	Apply this rule to our current user
ALL=	On all hosts
(ALL:ALL)	Can impersonate any user and any group
NOPASSWD:	No password prompt required
ALL	Permission to run every single command

Saving in Nano:

• Ctrl+O → Write Out (Save). Press Enter to confirm the filename.
• Ctrl+X → Exit the editor and return to the shell.

⚠️ The Road Not Taken — Why Not Use visudo?
The comment at the top of the file warns: "This file MUST be edited with the 'visudo' command as root." The visudo command is the safe way to edit sudoers because it validates the syntax before saving, preventing a broken sudoers file that could lock everyone out of sudo. However, visudo is not what we have permission to run — only nano is. Nano has no syntax validation, so we must be careful to type our rule exactly correctly. In a CTF context, this is fine. In a real system, a typo here could be catastrophic.

---

3.3 Reading the Flag

Now that our user has been granted unrestricted sudo access, we simply run:

sudo cat flag.txt

Breaking Down the Command:

Component	Meaning
sudo	Execute the following command as root
cat	Concatenate and print file contents to the terminal
flag.txt	The target file in the current directory

Output:

picoCTF{n4n0_411_7h3_w4y_3dc38f6f}

Flag captured! ✅

🧠 Decoding the Flag (Fun Leet-Speak Translation):
n4n0_411_7h3_w4y → nano all the way
A clever nod to the challenge's concept — nano was the key to everything.

---

4. Full Exploitation Chain (Visual Summary)

SSH Login (low-privilege shell)
          │
          ▼
    ls -al → flag.txt exists but is ROOT-OWNED
          │
          ▼
    sudo -l → nano allowed on /etc/sudoers as root
          │
          ▼
    sudo /bin/nano /etc/sudoers → Edit security policy
          │
          ▼
    Add: ctf-player ALL=(ALL:ALL) NOPASSWD: ALL
          │
          ▼
    sudo cat flag.txt → FLAG RETRIEVED ✅

---

5. Lessons Learned & Mitigation

5.1 For the Attacker (Offensive Takeaways)

Lesson	Detail
Always run sudo -l first	It is the fastest, quietest privilege escalation check available on Linux
Text editors are dangerous with elevated privileges	nano, vim, vi, emacs — all can read/write arbitrary files and even spawn shells
GTFOBins is your friend	The website gtfobins.github.io catalogs exactly how tools like nano can be abused for privilege escalation
Configuration files = power	Any tool that can write to /etc/sudoers, /etc/passwd, or cron jobs effectively gives root access

---

5.2 For the Defender (Blue Team Mitigations)

Vulnerability 1: Unrestricted Write Access to /etc/sudoers

🔴 The Problem: Granting any user the ability to write to /etc/sudoers — even through a restricted tool — is equivalent to giving them root.

✅ Fix: Never grant write access to /etc/sudoers through sudo. If delegation is needed, use /etc/sudoers.d/ with extremely narrowly scoped rules (specific commands, specific arguments, specific paths). Even then, avoid editors.

# BAD — Never do this
ctf-player ALL=(ALL) NOPASSWD: /bin/nano /etc/sudoers

# BETTER — Only allow a specific, non-destructive read-only action
ctf-player ALL=(ALL) NOPASSWD: /bin/cat /var/log/app.log

---

Vulnerability 2: No Detection/Alerting on Sudoers Modification

🔴 The Problem: Even if this happened on a real system, there was no monitoring to detect the unauthorized change.

✅ Fix (Detection): Implement file integrity monitoring (FIM) on critical files:

# Using auditd to monitor /etc/sudoers for any write operations
auditctl -w /etc/sudoers -p wa -k sudoers_change

This creates an audit log entry any time /etc/sudoers is written (w) or its attributes change (a), tagged with the key sudoers_change for easy log searching.

✅ Fix (Hardening): Use tools like AIDE or Tripwire for file integrity monitoring, or deploy a SIEM (like Splunk or ELK) to alert on unexpected privilege changes.

---

5.3 Key Conceptual Takeaways for Beginners

1. ENUMERATION IS EVERYTHING
   Never skip sudo -l, id, whoami, find / -perm -4000, 
   and cron job checks when you land on a Linux machine.

2. TOOLS ARE NOT INHERENTLY SAFE
   A text editor with root privileges IS a root shell.
   Always think: "What can this tool WRITE to?"

3. THE PRINCIPLE OF LEAST PRIVILEGE
   Users should only have the exact permissions they need — 
   nothing more. This challenge is a perfect example of 
   what happens when this principle is violated.

4. CHECK GTFOBINS
   For any binary you find in sudo -l or with SUID bits,
   check gtfobins.github.io immediately. It will tell you
   exactly how to exploit it.

---

Writeup authored using a systematic, iterative CTF methodology. Every command was justified, every output was analyzed, and every decision was evidence-based.