041#:HTB - Help
Today is a big day for me as I just finished the OSCP PEN-200 coursework, save for the Trying Harder challenges at the end. I have been getting antsy feeling like I hadn’t properly hacked anything in a while. When I logged into Hack the Box tonight, I discovered it’s been a whopping four months since my last activity.
That changes tonight though. The plan is to work my way through a significant portion of TJ Null’s OSCP prep list before tackling the Trying Harder labs. Tonight, I will be knocking the digital dust of my kali vm with the room Help by cymtrick.
We have a few things to explore, but I start by running a gobuster scan and exploring the site in my browser. Gobuster immediately fails and the site won’t load. In my browser, I changed to the other port we saw, 3000, and this time it loads.
The clue here tells us we can find credentials if we use the right query, but I’m not totally sure what that means. Nmap shows node.js express running on port 3000, so I googled “node.js express query” and began reading. Not sure what to do with this yet though. I make note of the shiv user and get a gobuster scan running against it at port 3000 this time.
This didn’t throw errors, but it didn’t find anything either. After looking around a little more, I added help.htb to my /etc/hosts file and tried to navigate to the site again.
That’s good, so I got another gobuster scan running which gave us better results this time.
We don’t have access to the /javascript directory so I move on /support. This reveals a helpdesk portal we can start exploring.
I start clicking around and got another gobuster scan going, this time against /support. I checked the source code for what version of HelpDeskZ is running but no luck. I tried making a test ticket and uploaded a text file. I opened burpsuite and captured the request to the knowledge search bar.
I’m coming up empty handed after poking around more, so despite lacking a version number I check searchsploit for anything on HelpDeskZ.
I attempted the file upload vuln here a few times and it seems like it may have worked.
I had used pentest monkey’s php reverse shell here, but when I try to visit the link it found I don’t catch the shell. I thought maybe a webshell would work, but this fails too. I am hitting my first wall, so I review what I know so far.
I keep coming back to the hint found in the message to Shiv. I tried a couple more gobuster scans without luck. Spent more time looking into node.js express queries. Not making progress though. Reading over the exploit again, I realized I used it wrong so I try again but this time by uploading the payload to the ticket portal first.
We see that I got an error that my file type isn’t accepted. I tried running the exploit again just in case, but no luck. I tried a few file upload bypass techniques also didn’t work. I went back to researching HelpDeskZ and looking over the exploit.
After a hitting dead ends for a bit, I peaked at this article by Mandohacker that showed them using the exploit against the /support/uploads/tickets. It’s not clear how they knew to use that path, and other articles I checked didn’t say either. That is unfortunate, but we will press on.
This worked and we catch our revshell. I stabilized my shell before starting to explore. I read over site files in /var/www/html/support/. I noticed I am a member of some interesting groups and decided to get linpeas running. Moving over to the home folder, we grab the first flag.
With that, I start looking over the linpeas results. The OSCP course stressed getting through your current task before following up on leads, so I finished working my way through the linpeas results while taking notes of the findings I thought would be the most promising.
There kernel and sudo versions may be vulnerable, there is a high flag on a finding in the cron jobs, there is a version of GNU Screen that is vulnerable, some ports open on the loopback address, etc. There’s some good options to go with here.
I was interested in the high finding in the cron jobs, but at second glance it requires a reboot. I started with GNU Screen 4.5 because the exploit looked simple. I make a copy in my local directory and then transfer it to the target.
That didn’t work, on to the next one. Tried exploiting the sudo version next which failed because I needed sudo rights to run it. I tried a few kernel exploits but got various errors. Thinking more about the cron job, I figured I would see what file was being launched at restart just in case there is anything in valuable in there. Lucky for us, we get a username and password hash!
I saved the hash to a file and quickly cracked it with hashcat.
I tried to see if this password works for the help account, but it does not. I moved on to attempting to log into the web portal which did work.
Unfortunately, there isn’t much to see here. The next lead I had was from linpeas ‘Linux Exploit Suggester’ section which flagged that it may be vulnerable to CVE-2017-16995. I pulled a copy to the target, compiled, and ran it which ended up giving me root!
This was a decent room. Although, I looked at the official writeup after I finished and I feel like it was a bit of a stretch that I would guess the /graphql directory if I had found the intended path. I was also surprised to find this method wasn’t the intended path, but overall it was a good time.