Pikaboo, HackTheBox Walk-through

In this post we walk through steps of a HackTheBox machine “Pikaboo”. This machine is UNIX based machine and according to HTB users hardness is hard. We considered that the step-by-step solution of this machine is helpful for pen testers. So let’s start…

NMAP

Nmap results are shown below. Three ports are open 21 ftp, 22 ssh and 80 HTTP.

21/tcp open ftp vsftpd 3.0.3
22/tcp open ssh OpenSSH 7.9p1p1 Debian 10+deb10u2 (protocol 2.0)
80/tcp open http nginx 1.14.2

ENUMERATION

Looks like we have 3 ports FTP,SSH and HTTP. Let’s check FTP for anonymous login.

Not much at the web page but there is a “Contact” page, however not much there as well. We cannot submit the form. Then we have another page called “Admin” which page requires basic authentication for logging in. Default credentials and brute force should not work as this is hard box so let’s think something other than that. Clicking cancel on the basic authentication dialogue box gives us something interesting.

In the image, you can see that it is saying it is using an Apache server on port 81 so there are two interesting things first is why port 81 instead of standard port 80 and another is Nmap says it’s Nginx not Apache so there must be some sort of traffic forwarding and reverse proxy running on the back-end. Now to the port 81 part as Nginx is running on port 80 that is why Apache is on port 81 as both should be hosted on the same machine (we can also use the “Wappalyzer plugin”, we see that this web app is running on Nginx 1.14.3.). After checking versions for exploitation, we saw that the machine is running the latest versions of both Apache and Nginx, but we found this article that specified that there could be path traversal due to misconfigured alias in Nginx. So we thought to give it a try as it is pretty easy just go to the endpoint which asks for the credentials and then use ../ and then go to the desired directory.

It seems that we have found few directories most of them don’t look interesting but server-status which is mostly forbidden is now giving a 200 status code so let’s check that out.

Now we know we can access admin_staging endpoint using this trick. Visiting that point it looks like this.

Now we finally have the admin dashboard or that is what I am assuming at the moment.

When we look at the URL, it looks fishy as it just directly calling the PHP page so there could be potential LFI there. so lets FUZZ for that as this box doesn’t have rate limiting and fuzzing is extremely fast so it would be just a couple of seconds.

Looks like we have access to the logs so if we would have tried to find this LFI manually we wouldn’t be successful until and unless you are genius and remembered that we have FTP also. But let’s be honest everyone tries /etc/passwd to check.

Anyways now we have the FTP log file so the first thing that came to my mind was FTP-log poisoning so if you don’t know what it is, it is basically just the injecting PHP code in the FTP log and then later make the web server to execute that piece of code with the help of LFI. If you wanna learn more about it you can refer to the following article.

FTP Log Poisoning Through LFI

EXPLOITATION

Looking at the logs we can also find the username but let’s go for LFI. We got the log file. Now let’s try and get a reverse shell from that. And then we get a reverse shell that is shown in the below pic.

Now you can get user.txt in /home/pwnmeow. Let’s check for all the running services on the box. Looks like we have LDAP running on the box.

Looking for interesting things we checked /opt directory and found the under construction version of pokeapi so there could be a hard-coded credentials in it as developers might have left it as it is still not fully implemented. So let’s try and grep for passwords from the files.

We can see LDAP creds and we know the LDAP is running on local host, so I decided to enumerate it with credentials we found.

Looking at the LDAP dump we can see the creds for the user pwnmeow. After decoding the code with base64, we got the cleartext password which is “ _G0tT4_C4tcH_’3m_4lL!_ “.

We have the password for the user pwnmeow but we cannot get into pwnmeow user with the “su” command, and you can’t use the credentials to get in with SSH. So from the beginning, we know that FTP also has the user pwnmeow from the logs that we saw from local file inclusion so let’s try this cred in here.

PRIVILEGE ESCALATION

First let’s enumerate further and see if there is any running cron job.

Looks like we have a script that is been executed as root every single second. So let’s look into the script.

Looks like it is just a simple bash script to run another script /usr/local/bin/csvupdate with the filename as the parameter for the files in FTP and now as we have access to FTP we might be able to exploit it. So let’s look at the /usr/local/bin/csvupdate file.

After analysis, the Perl script, it takes the file name as an argument. Looking for the vulnerability in Perl file open( ). We search for some exploits and we found these articles.

https://stackoverflow.com/questions/26614348/perl-open-injection-prevention

https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88890543

The exploit basically is that if the filename starts with ‘|’ then the rest of file name will be executed as command rather than the file name itself so I build up a payload for that.