Overview

Welcome to Backdoor machine from Hack The Box! This machine contains backdoors which are probably left behind by a previous (imaginary) attacker. Our task was to simply conduct recons, recons and recons until we find those useful software backdoors and root the box.

I. Enumeration & User flag

tl;dr: After some scans, we found a LFI vulnerability in an outdated Wordpress plugin, allowed us to bruteforce /proc directory, then attack the abnormal service on port 1337

1. Initial scan

As per usual, we start with a port scan:

# Nmap 7.92 scan initiated Mon Dec  6 19:33:51 2021 as: nmap -sC -sV -oN nmap.txt 10.10.11.125
Nmap scan report for 10.10.11.125
Host is up (0.51s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 b4:de:43:38:46:57:db:4c:21:3b:69:f3:db:3c:62:88 (RSA)
|   256 aa:c9:fc:21:0f:3e:f4:ec:6b:35:70:26:22:53:ef:66 (ECDSA)
|_  256 d2:8b:e4:ec:07:61:aa:ca:f8:ec:1c:f8:8c:c1:f6:e1 (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-generator: WordPress 5.8.1
|_http-title: Backdoor – Real-Life
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
1337/tcp open  tcpwrapped 

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Dec  6 19:35:00 2021 -- 1 IP address (1 host up) scanned in 68.59 seconds

To sum it up by a meme: port scan result summed up by a meme

In case you haven’t noticed, port 80 was running a Wordpress site with a very specific version. Looking up for exploits of that version, however, yielded no useful result.

Searchsploit result for Wordpress version

Therefore, let’s open it up in a web browser!

port 80 landing page

2. Wordpress Attack

It’s a typical Wordpress site overall - nothing specifically caught my interest, apart from one thing - the comment function.

the comment section in posts

I won’t go into the details, as this attack vector led me nowhere. But in short, I kind of found something like an IDOR vulnerability. The comments, on the other hand, has been carefully pre-processed to strip all possible HTML tags and Javascript away.

While I was beating my head against a wall, a wpscan enumeration I set up earlier returned with some gold mines (You must first have a wpscan API token, or else wpscan won’t tell you anything. A free one is fine).

Basically, there’s a directory listing at /wp-content/plugins.

Directory listing for plugins

Browsing those files got me nowhere, but a quick searchsploit look up did.

Searchsploit result for ebook folder

3. Get in the system

I went with the POC, and it turned out to be a simple directory traversal vulnerability that provided us with reading access to some files.

Directory traversal vulnerability in Wordpress site

The machine was, indeed, vulnerable to this POC, as we were able to read /etc/passwd file with ease.

Use directory traversal to read /etc/passwd file

As you can see, the only real user, apart from root, was user account. However, I couldn’t retrieve the SSH key at /home/user/.ssh/id_rsa - was that because of insufficient privilege, or the file simply wasn’t exist? Also, /home/user/user.txt couldn’t be read as well.

Either way, I got stuck for a great while in this step, not knowing what to do with all low-level file read access in my hand, until I suddenly remembered that everything in Linux are files, even processes.

As such, here’s a way to run ps aux with extra steps on the server.

for i in {0..100000}; do curl "http://backdoor.htb/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=/proc/$i/cmdline" && echo "\n\n\n"; done

Now that I’m writing this write-up, I’ve just realized that it would have been so much easier to fuzz it with wfuzz or any fuzzer. Nonetheless, it worked, and some novel results actually showed up, particularly this one:

/proc/825/cmdline/proc/825/cmdline/proc/825/cmdline/bin/sh -c while true;do su user -c "cd /home/user;gdbserver --once 0.0.0.0:1337 /bin/true;";

Thus, we found out that the strange service running on port 1337 earlier was a gdbserver. What’s left was to exploit it, and you can find a working POC of a RCE vulnerability right on exploit-db!

Upon loggin into the server, we got user.txt flag.

II. Privilege Escalation

tl;dr: Abuse a Setuid binary to get root

Having stablized our shell, now onto the task of escalating to root access.

This is one of the first commands I usually run on a Linux machine after getting a shell:

find / -type f -perm -u=s 2>/dev/null # find all setuid files

Everything looked normal, except this one:

/usr/bin/screen

For those who didn’t know, screen, or GNU screen, is a terminal multiplexer that can detach from and attach to terminal sessions. Once a session is initiated, it will be run with that user’s privilege, and continue running until an user explicitly tell it to exit.

As the screen binary this time is setuid to root, we had the permission to get a root terminal session right off the bat.

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

Simple as that, we owned the box.

Since we put nothing on the server, the house cleaning part was also not necessary.

III. Patch

Dear imaginary sysadmin, please update your softwares and set the right permission for binaries. Thanks for your attention.