HTB — Backdoor

wordpress | LFI | pid’s | gdbserver | misconfiguration | screen

Vinicius Scallop
stolabs
10 min readSep 13, 2022

--

Backdoor is an easy hackthebox machine, the foothold involves findind a wordpress plugin that has a directory traversal vulnerability to read system files, with lfi you can read pid’s from /proc directory and find out that there is an unknown port running gdbserver, that we can exploit to get a reverse shell. For privilege escalation you could exploit a misconfiguration and be able to list and join in the root screen session.

Enumeration

Nmap

I will start by doing a full portscan with nmap to see which services and ports are open.

After the nmap, 3 ports were found open, these being 22 (SSH), 80 (HTTP) and 1337 (not sure what kind of service it is). Analyzing the nmap output, we see that port 22 is an Ubuntu server, so this box is an linux machine, and on port 80 we have an apache on version 2.4.41, we also have a http-generator header telling us that it is a wordpress on version 5.8.1.

Port 1337 — ??

Nmap was not able to describe what kind of service runs on port 1337, but we can try connecting with netcat and get some clue what it is.

I tried to connect and find out what was going on, but got no response back, so let’s move on.

Port 80 — HTTP

Port 80 is a standard wordpress template with some redirect links in the menu tab.

After hovering on the Home menu option, it shows us that the link redirects to backdoor.htb, which is a vhost, so i will add it to my hosts file.

On the blog tab there’s a “Hello World!” post by the admin user, which can be useful information later.

Whenever there is an application running wordpress, i have the habit of checking the /wp-content/plugins/ directory to see if there are any plugins being used, i also use wpscan, a tool that will do the enumeration in an automated way, searching for plugins, themes, users, etc.

Manually enumerating first, we can see that the application is using the ebook-download plugin.

Running wpscan with the -e ap option, we indicate that we want to enumerate all plugins, as it is a ctf box we can run it with the — plugins-detection option in aggressive which will bruteforce the plugins.

wpscan also has a nice feature using the — random-user-agent parameter that will use a random user-agent header for each request being made. This option is very useful, since by sending a considerable number of requests the application may have a block rule via the user-agent. In this case, there is no need to use this option since there’s no firewall or WAF on the box.

Shell as User

Exploit eBook-download plugin

After wpscan finished running, it found 2 plugins being used, askimet and again ebook-download. Not only did it find the plugin, it also tells us that the plugin is in an outdated version and has directory listing. Since it is an outdated version, we can search for vulnerabilities in this plugin on google.

The first result is an exploitdb directory traversal PoC in the /wp-content/plugins/ebook-download/filedownload.php endpoint. So i will test it and see if we can download wp-config.php file.

After downloading and reading the file, there are wordpress credentials, but when testing them in the application, it was not possible to log in with them, i also tried different usernames like administrator, admin, root, but no one with success.

After trying to read different files from the machine like /etc/apache2/sites-enabled/000-default.conf to check for vhost, the /etc/passwd file which there is a user called user on the machine, but we cant read any files from his home.

Reading the /proc pid’s command lines

After some time trying to read files with the lfi, i realized that port 1337 can be a valuable information at this point. So i decided to start enumerating the /proc directory to see what processes are running on the machine and try to figure out what kind of service is running on this port.

As you can see, i used my machine as an example to show what /proc looks like, each number represents a running process, which is known as pid or proccess id.

There is a file called cmdline that shows the command line according to the pid informed, in the example below i used the path /proc/self/cmdline, which in this case /proc/self represents the current process that im running in, if you need to see the command line of other processes, you must change the /proc/self directory to the desired pid directory. For example: /proc/1/cmdline.

As we can see, the command line of the process that i’m running in is /usr/bin/apache2-kstart.

Since we don’t know how many pid’s may be running, i will start by making a oneline script to dump the command line of the pid’s from 0 to 1000, also i will format the output better so we can read only the desired output. In the end it will look something like this:

Before you dump all the pid’s, i highly recommend creating a directory to store all the pid files, otherwise your workpspace might be a bit dirty

After a few minutes, we will have dumped the first 1001 pids, but reading them 1 by 1 would be unproductive, so i will make another oneline script to show the output of each pid based on its size. To do this we can use the command find by passing the parameter -size, which will filter by size in bytes, and then cat the variable $i, which will show each file that is larger than the bytes entered. In the end it will look something like this:

As we can see , it has only printed the pids with bytes greater than 25, taking a look, most of them are default services, however, there are 2 of these that are interesting at first glance, these being services running in a while loop.

The first one, does a command “su user”, which indicates that he is running the code with the user user, and passes the command “cd /home/user/” and then the command “gdbserver — once 0.0.0.0:1337 /bin/true” which will run gdbserver in loopback on port 1337, so now we already know what runs on port 1337.

The second command, does a 1 second sleep command, then use find in /var/run/screen/S-root/ with the parameteres -empty and -exec, -empty will check if the file is empty, and -exec will execute the screen binary with the parameters -dmS which will detach the root user session.

So now that we know what is running on port 1337, we can search for exploits for gdbserver.

The first result found was this exploit-db written in python and that allows RCE, at the very beginning, it tells us that before running the exploit we need to generate the payload with msfvenom, then start netcat, and then we can run the exploit with the .bin we created.

Instead os running this exploit, i will exploit this gdbserver manually, to show what the exploitation process looks like.

Exploit gdbserver

Searching how to exploit this gdbserver manually, i found a manual on hacktricks with a step by step guide.

Hacktricks guide:https://book.hacktricks.xyz/network-services-pentesting/pentesting-remote-gdbserver

In this hacktricks step by step, after generating the elf backdoor with msfvenom, we have to give execute permissions to file.

Next step is start debugging the file on our machine with the gdb.

Then connect to the machine’s gdbserver on port 1337 using the target extended-remote command.

After connecting we can upload our generated backdoor in /tmp directory.

And finally set the remote debugging target to the file we uploaded and run.

Now if we check te netcat server, we got a reverse shell.

Shell as root

Full TTY

I will upgrade my shell to have things like auto complete, screen cleanup, use cli text editors, etc. If you want more information on how to upgrade your shell, i always provide this step by step from hacktricks:

https://book.hacktricks.xyz/generic-methodologies-and-resources/shells/full-ttys#full-tty

Enumeration

Running the ps -ef command to see what processes are running on the machine, we see the same processes running in loop, previously seen by the lfi.

Screen

Screen was developed by the GNU project team to help take advantage of linux terminal management, it allows you to split a terminal into several sessions, it is also very useful in cases of power failure, where even if your computer shuts down, it keeps the session active when you turn the computer back on, screen is very similar to the popular tmux.

Screen privilege escalation

The screen -ls command is used to list a user’s session.

As seen in the processes, there is a root session running in loop, if we try to list the sessions of the root user, we can prove this.

For some reason, when listing the user session, we need to specify the slash “/” at the end.

If we try to access this session with screen -r command, we can get into the session and have root access on the machine!!

This is because the -r command is for reattach, we could do this using the -x parameter as well.

Screen misconfiguration

On this machine we can list and use sessions from another user, in this case root user, as it is running in the background by the command screen -dmS root.

This is due to a misconfiguration that i will show, we can read the screen configuration file and show you why it allows other users to access other sessions.

As we see in this cron file, it prints some commands to the .screenrc configuration file.

Other misconfigurations that we have detected here are chmod commands being made that give undue permissions to the /var/run/screen and /var/run/screen/S-root directories.

Finally, we can see in the configuration file, the bad settings, which allow more than one user to access that session by the multiuser on command and we can also see that the user user has permissions by the acladd command.

Is important to make it clear that by default screen doesn’t have this misconfiguration, so we conclude that it is something specific and done only on this machine, we can consider it as a ctf-like thing.

--

--

Vinicius Scallop
stolabs

I'm not that special. I’m just anonymous. I’m just alone