❌Trick Writeup
Hack the Box Trick machine writeup
Last updated
Hack the Box Trick machine writeup
Last updated
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:
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!
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.
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.
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:
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.
This dashboard had a few interesting features and some XSS vulnerabilities:
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.
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.
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.
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'.
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:
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!
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.
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!
PWNED!!!
