Introduction
Nunchucks is a Linux box on Hack The Box, made by TheCyberGeek, and I plan to hack it. Hey there, welcome to Techyrick! In this post, I’ll share how I managed to hack into Nunchucks and grab the flags.
As I’m still learning, I’ll refer to the official walkthrough when necessary. So, think of this write-up as my blog documenting the experience rather than a step-by-step guide.
Hacking Phases in Nunchucks
Initial Access
- Nmap TCP Port Scan
- Web Page Enumeration
- Directory Bruteforce
- Vulnerability Assessment
- Server-Side Template Injection Exploitation
- User Flag
Privilege Escalation
- Find Privilege Escalation Vectors
- Escalate Privilege exploiting Perl capabilities
- Root Flag
Let’s Begin
Hey you ❤️ Please check out my other posts, You will be amazed and support me by following on X.
Let’s Hack Nunchucks HTB 😌
https://twitter.com/HacklikeHacker
Nunchucks Enumeration
I fired up the Nunhucks machine and got on the VPN. Then, I checked if the box was online by pinging it. Take a look at the Nmap scan results below:
SSH on port 22, HTTP on port 80, and HTTPS on port 443 are open. So, it looks like it’s an Ubuntu system running Nginx. Also, the domain linked to the box is nunchucks.htb.
I noticed the SSL certificate is set to Dorset, which got me thinking if TheCyberGeek is from there.
sudo nmap -sC -sV -p- 10.129.236.104
Nunchucks Application Enumeration
After running my Nmap scans, I tried to go to the IP address in my browser, but it just sent me straight to the nunchucks.htb domain.
So, I put the domain and IP address into my host file to make sure the application redirected properly and I could access it.
Here’s what happened when I tried to visit the IP address, and then the command I used to add the domain to my host file. Finally, you can see the application I was trying to reach.
echo "10.129.236.104 nunchucks.htb" | sudo tee -a /etc/hosts 10.129.236.104 nunchucks.htb
Sun Tzu once said that if you understand your opponent and yourself, you won’t have to worry about losing in battles.
He would’ve been good at hacking because of this mindset. Knowing all we can about the application we’re dealing with is crucial to beating it.
So, I used ‘whatweb’ to figure out what technologies the application uses. Turns out, it’s made with Node.js and uses the Express framework. I’m still learning about Node.js, so I might not get all the terms right.
sudo whatweb http://nunchucks.htb
Crawling Forward
At first, I tried signing up as a user, but it didn’t work. Then, I tried logging in with some standard usernames and passwords, but got a message saying user logins were turned off. I wasn’t sure what to do next, so I looked at the official guide.
The author, TheCyberGeek, mentions there’s a message about a store coming soon at the bottom of the page. So, I figured I should try brute-forcing some other virtual hosts.
I had options for trying to brute force more virtual hosts, but I decided to go with ‘gobuster’ because that’s what TheCyberGeek used.
Surprisingly, it didn’t work, which caught me off guard. I checked the wordlist with ‘grep’ and found that it did include the word ‘shop.’
So, I decided to give ‘ffuf’ a shot, and I’m glad to say it worked pretty quickly. First, I ran it without any special filters to figure out the file size of the error page. Then, I used that file size as a filter to narrow down the results.
This led us to find the shop virtual host with a file size of 4029. I’m not sure why gobuster missed it. Sure, I could have just added the store virtual host to my host file since it seemed logical, but I wanted to use different tools.
In the past, whenever something didn’t work, I either gave up or skipped ahead. That’s not a good habit because you don’t learn anything from it.
sudo ffuf -u https://10.129.236.104 -H 'HOST: FUZZ.nunchucks.htb' -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -fs 30589
Lastly, I added the host to my host file.
echo "10.129.236.104 store.nunchucks.htb" | sudo tee -a /etc/hosts 10.129.236.104 store.nunchucks.htb
Going Shopping
I checked out the new host in my browser, but besides a nice background, there wasn’t anything interesting happening.
There was a button to subscribe to the newsletter, but that’s all. I peeked into the page source, but didn’t find much. I also ran ‘whatweb’ again and found out that this application also uses the Node.js Express framework.
The subscription box for the mailing list caught my attention because whatever I typed in there showed up on the page.
I attempted some basic XSS tricks, but it seemed like the form was checking the input. So, I went back to the official guide, and suddenly, the name of the box started to make sense.
Nunchucks Server Side Template Injection
SSTI, or Server-Side Template Injection, is a type of weakness in web applications. It happens when a hacker can add and run their own code within a server-side template. This lets the hacker get access to private info or do things they’re not supposed to on the web app, which could mess up the whole system.
SSTI attacks often aim at apps that use templates to make web pages, like ones built with frameworks such as Flask or Django. Making sure to check input and encode output properly can help stop SSTI problems.
In the example below, when I put in the code ‘808/2’, the response showed ‘404@htb.htb‘. The system worked out the math and gave back the answer in its reply.
Once I confirmed the SSTI weakness, I looked for the POST request in Burp and tried to see what was in the ‘/etc/passwd’ file.
My first try didn’t work out, but it made the application show its file paths due to an error. This was actually helpful because it gave me more details about the application.
Unfortunately, the code from Hacktricks didn’t do the trick. So, I went back to the official guide for help. Even though I got a working code from there, it didn’t answer my questions.
I wanted to understand why we needed to add backslashes to the code. Below, you can see the original code (from Hacktricks) and the one that worked. The only difference is the two backslashes.
It looks like we need the backslash to escape the quotation mark, but now I’m curious why one is outside the quotation mark while the other is inside.
No problem! Feel free to describe the SSTI examples in text, and I’ll help you with that.
Cybersecurity can feel like constantly facing new challenges. Right now, I’m not excited about trying to make the reverse shell work.
Nunchucks Foothold
This part was tough, and it got me thinking about what I’m doing with my life. It seemed like such a simple thing to do, but no matter what I tried, I kept getting errors. Even after searching intensively online and reading through other people’s guides, my code still wouldn’t work.
I made sure to escape double quotes properly and tried replacing other quotes with single ones, but nothing seemed to work. It was driving me crazy.
In the end, I decided to reset the box. I didn’t think it would make a difference, but strangely enough, the codes that didn’t work before started working now.
Following a guide, I dropped an SSH key into David’s authorized keys files. The attack chain involved using SSTI to access the ‘etc/passwd’ file, finding David as a user, checking his home directory, creating the .ssh directory, and adding my public key into his authorized_keys file.
You can use the code snippet below and replace the commands with the ones needed for the attack chain.
Finally, I managed to obtain the user key.
ssh -i key david@10.129.216.64 david@nunchucks:~$ cat user.txt 774▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓c50
Authenticated Enumeration
Once I got access to the system, I downloaded and ran LinPEAS to search for any clear paths to escalate privileges. It detected two CVEs, but they didn’t lead to gaining root access.
However, it did discover that Perl had setuid capabilities enabled. Additionally, it highlighted that several backup files belonged to the root user but were part of the david group.
Now, we’re stepping into areas that are a bit above what I know. So, I’m going to simply repeat the steps from the official guide.
Although Perl having ‘setuid’ capabilities might seem like we could boost our privileges, it didn’t actually work out that way.
Trying to do so gave us errors, indicating there might be something else going on. For instance, trying to read the shadow file with Perl resulted in a “permission denied” error, even though according to GTFO bins, it should have let us read the file.
perl -e 'use POSIX qw(setuid); POSIX::setuid(0); exec "cat /etc/shadow";' cat: /etc/shadow: Permission denied
Furthermore, when we run the ‘whoami’ command with Perl, it shows that we’re root. What’s happening?
Is the system experiencing some sort of identity confusion, not granting us the privileges of the root user?
perl -e 'use POSIX qw(setuid); POSIX::setuid(0); exec "whoami";' root
After doing more investigation, it appears there’s an AppArmor profile for Perl that includes a mention of a script in the ‘opt’ directory.
Privilege Escalation
We noticed that the script is owned by root. But when we peeked inside, we saw it’s using ‘POSIX::setuid(0);’ so it runs as root even if a different user runs it.
It’s a bit puzzling to figure this out. The file is owned by root but can be run by anyone. Yet, because of the ‘setuid’ line in the script, it runs with root powers.
It’s a clever trick to hide the file from tools like LinPEAS, which annoys me. Unfortunately, we can’t edit this script to add our own commands to elevate our privileges.
This next part reveals a major security flaw with the SETUID capabilities on the Perl binary, even though it’s limited by AppArmor.
This bug mentioned in the link explains that if a script has a shebang pointing to the binary in question, it doesn’t follow the restrictions set by the AppArmor profile.
That’s a pretty serious bug, and we can exploit it to elevate ourselves to ‘root’ and finally grab the root flag. You can find the exploit below.
david@nunchucks:~$ vim whoops.pl david@nunchucks:~$ cat whoops.pl #!/usr/bin/perl use POSIX qw(setuid); POSIX::setuid(0); exec "/bin/bash"; david@nunchucks:~$ chmod +x whoops.pl david@nunchucks:~$ ./whoops.pl root@nunchucks:~# cat /root/root.txt 5fc▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓b21
Conclusion
I’m relieved to have finished this box. It was quite challenging for me, and I wouldn’t have made it through without the guide.
I’ll admit, I almost gave up when trying to get started, but I kept at it and eventually succeeded. Unfortunately, I still don’t fully understand what I was doing wrong, but I got there in the end.
I struggle with getting reverse shells through Burp, which is something I need to improve on.
The privilege escalation showed me that automated tools won’t always give you all the answers. I don’t think I would have figured it out on my own.
I probably would have kept trying GTFO bins but eventually given up. This box taught me the importance of thinking creatively and exploring different avenues. It also made me realize how much I still have to learn and has left me questioning my own abilities. Until next time!
Also Read: HTB Write-ups
