❌Trick Writeup

Hack the Box Trick machine writeup

Hello, and welcome back. After a long break from writing up Hack the Box machines, mostly because of school, I have returned. For this one we are going to be covering the Trick machine.

Now, as always, we start with a simple nmap scan of the machine:

$ nmap -sV -sC -v 10.10.11.166
...
Nmap scan report for 10.10.11.166
Host is up (0.022s latency).
Not shown: 996 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey: 
|   2048 61:ff:29:3b:36:bd:9d:ac:fb:de:1f:56:88:4c:ae:2d (RSA)
|   256 9e:cd:f2:40:61:96:ea:21:a6:ce:26:02:af:75:9a:78 (ECDSA)
|_  256 72:93:f9:11:58:de:34:ad:12:b5:4b:4a:73:64:b9:70 (ED25519)
25/tcp open  smtp    Postfix smtpd
|_smtp-commands: debian.localdomain, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, SMTPUTF8, CHUNKING, 
53/tcp open  domain  ISC BIND 9.11.5-P4-5.1+deb10u7 (Debian Linux)
| dns-nsid: 
|_  bind.version: 9.11.5-P4-5.1+deb10u7-Debian
80/tcp open  http    nginx 1.14.2
|_http-server-header: nginx/1.14.2
|_http-title: Coming Soon - Start Bootstrap Theme
Service Info: Host:  debian.localdomain; OS: Linux; CPE: cpe:/o:linux:linux_kernel

With these results we can see something interesting, the machine has DNS setup on it. Strange but right off the bat, before even visiting the site on port 80, I tried a DNS zone transfer on the machine... and it worked!

Hack the Box machine domain names are always <machineName>.htb

We can see that we have a new subdomain here, preprod-payroll.trick.htb, without even having to bruteforce it.

Now it was time to actually check out the website. I went ahead and checked just the default site first to see what it was.

The website homepage

There wasn't much here. The form didn't do anything and there were no additional directories that could be found with feroxbuster. This meant it was time for me to move on for now and check out this subdomain we had found.

The preprod-payroll subdomain login page

Once on the site we are taken to a login page, shown above. Interesting, this login page is actually interacting with something on the backend because we can see our requests going through Burpsuite. Just out of habit I put in the classic SQL injection syntax to bypass login forms: ' or 1=1 -- And it worked! It just logged me right it.

I think the challenge author was showing why you should not expose preprod, or pre-production, applications to the internet that have not gone through any vetting or testing process yet.

Along with this SQL injection vulnerability I was able to find that you can bypass the login page if you call the dashboard directly and ignore the HTTP 302 redirect code. This can be done automatically in Burpsuite using this match and replace rule:

Burpsuite match and replace rule to bypass 302 redirect

Well, now with two ways into the system, but only one getting us in authenticated (the SQLi) I was able to see what we now had access to.

The dashboard for preprod-payroll

This dashboard had a few interesting features and some XSS vulnerabilities:

Stored XSS

but we needed more than that, we need a way to get RCE on the system.

I was not finding much on the dashboard so I started up feroxbuster and let it run for a minute while I explored the site further. When I came back to view the current results it had found some interesting files that I should checkout.

The first was users.php. On this page we were able to see the username of the administrator account, good to note as it could be reused elsewhere. Along with that we can see in the page source that there is an endpoint named manage_user.php that takes a url argument of id.

The users.php page and the source showing the manage_user.php endpoint

I went to Burp and tried to hit this endpoint in repeater to see in detail what happened. For the ID argument I provided '1' because from the users.php page we can see that is associated with the administrator account.

The response from the manage_user.php endpoint

We can see in the response that it actually contains what seems to be the password for the account, or a really unique placeholder.

Now that I had a password and username I tried to login via SSH but... nothing :(. This prompted me to continue looking around the site for more information or attack paths. I really got stuck here until after alot of searching around I decided to run some more recon via bruteforce.

Side Note

So after completing this machine a friend and I talked over it and I realized I had missed something big. Because I had bypassed the login using SQLi I could have gone further and gotten the password out of the database using SQLmap. It was an oversight on my part but we still got there in the end.

Now back to the writeup...

Because the first subdomain we found was 'preprod-payroll' I figured to try searching for common subdomains with 'preprod-' appended to it. For this I used ffuf and actually got a hit back rather quick for 'preprod-marketing'.

Using ffuf to find subdomains with 'preprod-' appended

I immediately went and added this subdomain to my /etc/hosts file so that I could view it in my browser. This site, once loaded, was using a argument for page that would render the file being passed. This was an immediate red flag for me and I went and bruteforced it with payloads from an LFI wordlist and eventually got a hit with:

http://preprod-marketing.trick.htb/index.php?page=....//....//....//etc/passwd

We now had a path traversal vulnerability!

From reading the contents of /etc/passwd we could see there is a user named 'michael' and their home directory is at the default /home/michael/. From here I went ahead and checked if there was an ssh private key I could access for this account, and there was! Located at '/home/michael/.ssh/id_rsa'. We now could login as michael via SSH!

Shell as michael via SSH using id_rsa

From here we can have a look around. One of the first things to do when checking for a privilege escalation is to run sudo -l. When running this on the trick machine we can see that we can run /etc/init.d/fail2ban restart with NOPASSWD.

Interesting... This is a tool that a lot of defenders use and why would restarting it be the cause of a priv esc. I had to look further.

After a little googling around I found this article which showed how we could abuse fail2ban configurations to privilege escalate. Now this is why we are allowed to restart it as root. You need to restart fail2ban for the configuration changes to take effect.

One of the techniques mentioned in the article I linked is to change what the action performed when banning an IP address is. We can do this because we have write access to the directory '/etc/fail2ban/action.d/' and in this directory we can change the file '/etc/fail2ban/action.d/iptables-multiport.conf' to execute a reverse shell when it goes to "ban" and IP address.

Setting the actionban to a reverse shell back to myself

Now with the action set I could restart fail2ban and fail three login attempts and I should get a reverse shell back as root, because fail2ban is running as root.

After setting up a listener with pwncat-cs and bruteforcing the login with hydra I got a shell back!

Getting shell back as root (Top right)

root shell!

PWNED!!!