Within this post I’ll be doing a write up of the Paper box on HackTheBox, released on 05/02/2022. This write up will be written according to my thought process whilst I was trying to complete the box.
Foothold
Initial reconnaissance
I started off with a simple nmap SYN scan, with service version detection enabled, in order to gather information about the target.
From these results I could tell there was an SSH server running on the target, along with a HTTP server, running on both port 80 and 443 (HTTPS). What’s also interesting is that in the service header for the HTTP service it says ‘centos’, which is a Linux distribution and one I’ve actually seen used on a box before. This was something I decided I’d investigate further later. First, I decided I would attempt to visit the webpage for the server.
HTTP reconnaissance
I realised that it unfortunately wasn’t going to be that easy, I was going to have to work harder in order to get further into this target. However, at the very least from this webpage I was able to tell that the server again was running CentOS, this time specifying version 8. This will come in handy later, I was sure.
So for now I decided to fire up dirbuster and check for any hidden directories on the web server.
At this point I started to get excited, I imagined the results shown here would allow me to dig deeper into the box. To start off with, the cgi-bin directory was unfortunately configured correctly and did not allow me access, with there also being no exploit for cgi-bin in this version of php as far as I was aware. So I instead turned my attention to the more interesting manual directory, loading it up in my browser.
Looking at this page, initially I thought it would help me gather more information about the target, as it could contain information about hidden virtual hosts on the target, or something of the like. However, after combing through it for several minutes I realised this was just the default manual given with the Apache HTTP server and wasn’t going to be very helpful to me. So, I instead turned my attention to the headers being given in response to my queries.
When requesting the manual, the headers were pretty much normal and didn’t provide me with any more information than I currently had. However, when requesting the root directory of the web server, the response headers were more interesting.
To start off with, the HTTP response code was 403 instead of 200, which I found interesting as perhaps it implied the server was choosing to withhold certain information from me in the response. Looking further into the response headers, I also realised that the X-Backend-Server header was set to the value ‘office.paper’. At first I didn’t fully grasp the meaning of this, as I hadn’t seen this header before. However, after some searching online I realised this could be a virtual host configured on the HTTP server and I decided to add it to the entry for the box in my /etc/hosts. Then I tried opening office.paper in my browser and…
Bingo!
Further investigation
It seemed to me at the time that I landed on a wordpress blog being hosted on the machine, so I decided to poke around a bit more and see what I could find.
Eventually I found a comment on one of the posts which was interesting to me, as it mentioned ‘secret content’ being stored in the drafts of the author of the post. This prompted me to take a closer look into the wordpress installation, firstly with a scan using the tool wpsscan.
I found one part of the results particularly interesting, specifically the version number and wpsscan’s description of it being ‘insecure’ and released over 2 years ago. So I decided to search online for any exploits for wordpress version 5.2.3.
Eventually, on exploit-db I found an exploit for this version of wordpress which said
So far we know that adding
?static=1to a wordpress URL should leak its secret content
Naturally, I tried exactly this on the office.paper wordpress blog I discovered earlier, leading to the following output:
Nice, so it seemed that by adding that parameter to the website URL, I was able to view the content of drafts on the site. Very helpful. One particularly interesting part of this draft content is the web link at the bottom. After adding chat.office.paper onto the same /etc/hosts entry and opening the URL, I was greeted with this:
After making an account and poking around a bit, I managed to find a general communication channel, which had the following message:
It seemed that there is a bot that has been custom made for this rocket chat server for the purpose of answering simple queries.
And here it listed the functionality of being able to both read files and list directories. This definitely warranted further investigation.
I attempted to get it to list the root directory the bot was operating from and low and behold, it did so! What’s especially interesting from this output is that it looked exactly like the regular output from the ls command, just piped into a rocket chat message. This got me thinking at the time, is it just taking my input and executing it directly? To test this theory, I decided to try a directory traversal attack against the bot to list the directory up one level.
Great, that worked! I noticed the directory above looked like a user’s home directory and it did actually have the ‘user.txt’ flag inside it.
User
Attempting exploitation
Next I tried to get the contents of the ‘user.txt’ flag. Unfortunately, it looks like the bot is running as a different user, so the file read failed. Next I tried command injection using the ‘;’ operator.
Unfortunately, this didn’t work either, as the bot catches the shell operator and refuses to execute the command. I tried various other operators such as ‘&&’ and ‘||’, but it caught these too. At this point was stuck with the box, until a little while later when I attempted to execute a command using the bot directly.
Brilliant! It seemed incredibly strange to me that the bot caught my previous attempts to inject commands before, but now executes them with a keyword. Oh well.
Understanding the bot
So from here I decided to try and dig a little deeper into how the bot actually worked. I figured the ‘hubot’ directory was as good as any to start in.
Within this directory I could see various folders, but one at peaked my interest was ‘scripts’.
Aha! So it seemed that all of the functionality for the bot was programmed within this folder, including the ‘run’ command guessing from the ‘run.js’ in the folder. I decided to view the contents of run.js to take a closer look.
TOTAL VIOLATION of any and all security!
Yep. Sounded about right. From here I decided to search about ‘hubot’ online in order to find more information about how it functioned and how I could potentially exploit it.
Escalation
Eventually I came across the github page for the project after searching online and discovered that many of the configuration parameters for the bot are stored in the ‘.env’ file in the ‘hubot’ folder.
Therefore I decided to try and view the ‘.env’ file for this bot, maybe it’d give me some useful information?
Sweet, looked like there was a password in there! Maybe I’ll be able to use it on the SSH server I found during my scan? I’ll attempt to login using the ‘dwight’ user, considering they are the person most likely to have deployed the bot considering it’s in their home directory.
There, I managed to login and got the content of ‘user.txt’, so now all I had to do is get root!
Root
I started off my enumeration for root by deploying linpeas onto the target computer and executing it with the ‘-N’ parameter to disable colour, saving the output to a file. After the execution of the script finished, I started parsing through the content of the output and stumbled across this.
It seemed linpeas was claiming that the box is vulnerable to CVE-2021-3560, a polkit privilege escalation exploit which allows creation of additional administrative accounts on the system. After further investigation, I managed to verify that CentOS 8 is indeed vulnerable to this exploit, courtesy of Red Hat.
Therefore, I started looking online for a working script to exploit it. I came across this python script which I thought looked pretty solid, so I gave it a shot on the box, first uploading it to /tmp and then executing it using python. And…
Great, the exploit worked as expected! I got root on the machine and managed to get the contents of the ‘root.txt’ flag, concluding the box.
Mitigations
Within this section I’ll detail reasonable mitigations which could be made to this box in order to mitigate the vulnerabilities I exploited.
HTTP server headers
To start off, I cannot think of any good reason why a server would need to utilise the X-Backend-Server header in production and personally I’d recommend that this header be removed from the server, as the inclusion of it is unnecessary and only increases the attack surface of the box.
Wordpress draft access
The unauthorised draft access bug got fixed in wordpress 5.2.4. The wordpress installation should be updated.
Hubot command execution
For the most part, the bot was very resilient against command injection when concerned with the list and file commands, but considering it had a command dedicated to executing commands on the host system, these measures were practically pointless. The run.js and cmd.js scripts should both be removed from the bot in order to ensure its security.
SSH access
Because the password used for the rocketchat bot login was the same as dwight’s user account password, I was able to get access to the machine. Dwight’s user account password should be changed, along with the rocketchat bot password and they should not be the same.
CVE-2021-3560 exploit (polkit)
This exploit was patched in a newer version of polkit released for CentOS 8. The version of polkit on the box should be updated in order to mitigate against this vulnerability.
Donate
