Introduction
Today, I’m going to try and hack into a Linux box called FormulaX Writeup on a website called Hack The Box. It’s created by someone named 0xSmile. I’ll share my journey and tell you how I managed to break into FormulaX to find the flags.
I’m still learning, so sometimes I’ll check out the official guide for help. Think of this as more of a personal story of my experience rather than a step-by-step guide.
Hacking Phases in Formulax HTB
- Initial Access: Getting into the system.
- Nmap TCP Port Scan: Using Nmap to check for open ports.
- Web Page Enumeration: Exploring web pages for information.
- Directory Bruteforce: Trying to find hidden directories.
- Vulnerability Assessment: Finding weaknesses and vulnerabilities.
- Server-Side Template Injection Exploitation: Exploiting vulnerabilities in server-side templates.
- User Flag: Finding and getting the user flag.
- Privilege Escalation: Finding ways to gain higher levels of access.
- Find Privilege Escalation Vectors: Identifying paths for privilege escalation.
- Escalate Privilege exploiting Perl capabilities: Using Perl capabilities for privilege escalation.
- Root Flag: Obtaining the highest level access flag, known as the 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 Perfection HTB 😌
https://twitter.com/HacklikeHacker
FormulaX Enumeration
First, I started up the FormulaX machine and connected to the VPN. Then, I checked if the box was online by pinging it. Here’s what I found from the Nmap scan:
- SSH is running on port 22.
- HTTP is running on port 80.
- HTTPS is running on port 443. It looks like the system is Ubuntu and it’s using Nginx. Also, the domain linked to the box is FormulaX.htb.
I also noticed that the SSL certificate is set to Dorset, which made me wonder if TheCyberGeek is from there.
sudo nmap -sC -sV -p- 10.129.236.104
FormulaX Application Enumeration
After I finished scanning with Nmap, I tried to open the IP address in my web browser, but it sent me to the FormulaX.htb website.
To make sure I could access the application correctly, I added both the domain and IP address to my computer’s host file.
Here’s what happened when I tried to visit the IP address, followed by 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, a famous strategist, said that knowing your enemy and yourself leads to winning battles. This idea applies to hacking too. Understanding the application we’re attacking is crucial for success.
To learn about the technology behind the application, I used a tool called ‘whatweb.’ It showed that the application is made with Node.js and uses the Express framework. Since I’m still learning about Node.js, I might not understand all the technical terms perfectly.
sudo whatweb <http://nunchucks.htb>
First, I tried to sign up as a user, but I ran into a problem. Then, I attempted to log in using common usernames and passwords, but I got a message saying that user logins were turned off. Not sure what to do next, I looked at the official guide for help.
The author, TheCyberGeek, mentioned a note at the bottom of the page about a store that’s about to open. So, I decided to check out other virtual hosts by trying different login combinations.
Exploring Alternative Routes
Even though I had different ways to try brute-forcing more virtual hosts, I chose to use ‘gobuster’ because that’s what TheCyberGeek suggested.
I was surprised when ‘gobuster’ didn’t find what I expected, which left me a bit confused. But when I checked the list of words I was using with ‘grep,’ I found that it did have the word ‘shop’ in it.
I was determined to find more, so I decided to try ‘ffuf.’ I was happy when it quickly gave me results. At first, I ran it without any specific filters to check the size of the error page. Then, I used this size as a filter to narrow down the results.
Through this process, I found the ‘shop’ virtual host with a file size of 4029. I was puzzled why ‘gobuster’ didn’t find it.
Even though I could have just added the store virtual host to my host file based on guesswork, I wanted to use different tools to be thorough.
Looking back on past experiences, I realized that giving up or skipping ahead when things get tough doesn’t help with learning.
It’s important to keep trying and explore different ways to understand things better and improve your skills.
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
Finally, 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
I checked out the new host in my browser, but besides a nice background, there wasn’t anything really interesting.
The only thing worth mentioning was a button asking users to sign up for a newsletter. Even though I looked at the code of the page, I didn’t find anything important. Also, when I ran ‘whatweb’ again, I found out that this application also uses the Node.js Express framework.
The mailing list subscription box caught my eye because whatever I typed into it showed up on the page.
At first, I tried some simple XSS tricks, but it seemed like the form was checking the input. So, I went back to the official guide, and suddenly, I understood what the box was for.
Nunchucks Server Side Template Injection
Server-side template Injection (SSTI) is a common vulnerability in web applications. It happens when a hacker can put and run their own code within a server-side template.
This lets the hacker get sensitive information or do unauthorized things within the web app, which can mess up the whole system.
SSTI attacks usually go for apps that use templates to make web pages, like those made with frameworks such as Flask or Django. Checking input properly and coding output can help stop SSTI vulnerabilities.
In this example, when I put in the code ‘808/2’, the response showed ‘404@htb.htb‘. The system did the math and showed the answer in its response.
After confirming the SSTI vulnerability, I looked at the POST request in Burp and tried to see what was in the ‘/etc/passwd’ file.
Even though my first try didn’t work, it made the application show its file paths because of an error. This was actually helpful because it gave me more clues about the application.
Unfortunately, the code I got from Hacktricks didn’t fix the problem. So, I went back to the official guide for help. Even though I found a code that worked there, it didn’t answer my questions.
I was especially curious about why we needed to put backslashes in the code. Here are the original code (from Hacktricks) and the one that worked. The only difference is that the working one has two backslashes.
It seems that the backslash is needed to escape the quotation mark. But now, I wonder why one backslash is outside the quotation mark while the other is inside.
No worries! Just describe the SSTI examples, and I’ll be glad to help you further.
Cybersecurity often brings many new challenges, and right now, I’m not really excited about dealing with the reverse shell.
Getting a Foothold
This part was tough and made me think a lot about the path I’ve chosen. Even though the task seemed simple, I kept running into errors no matter what I tried. I searched online a lot and looked at other people’s guides, but my code just wouldn’t work, and it was really frustrating.
I made sure to escape double quotes properly and tried using single quotes instead, but nothing worked. It was really frustrating.
As a last resort, I decided to reset the box, not expecting much to change. Surprisingly, the codes that didn’t work before started working now.
Following a guide, I added an SSH key to David’s authorized keys. The attack involved using SSTI to get into the ‘/etc/passwd’ file, finding David as a user, checking his home directory, making a ‘.ssh’ directory, and adding my public key to his ‘authorized_keys’ file.
Feel free to use the code below and change the commands as needed for the attack sequence.
Finally, I managed to get the user key.
ssh -i key david@10.129.216.64 david@nunchucks:~$ cat user.txt 774▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓c50
Authenticated Enumeration
After getting into the system, I used LinPEAS to look for ways to get higher access. It found two CVEs, but they didn’t help me get root access.
However, LinPEAS showed that Perl had special permissions enabled. Also, it found some backup files owned by the root user but belonging to the david group.
Now, we’re getting into things I don’t fully understand yet. So, I’ve decided to follow the steps in the official guide.
Even though Perl has special permissions that could help us get higher access, our attempts didn’t work as we hoped.
Running into errors suggests there might be other things causing problems. For example, when we tried to read the shadow file with Perl, we got a “permission denied” error. This happened even though guides suggested it should 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 seen as root. This makes us wonder if the system is confused about our identity, maybe not giving us all the privileges that come with being the root user.
perl -e 'use POSIX qw(setuid); POSIX::setuid(0); exec "whoami";' root
After looking into it more, it appears there’s an AppArmor profile for Perl. This profile mentions a script that’s in the ‘opt’ directory.
Privilege Escalation
Upon looking closer, we found that the script is owned by root. But when we checked its contents, we saw that it uses ‘POSIX::setuid(0);’ to run as root no matter who runs it.
This is a bit tricky. Even though the file is owned by root, any user can run it. But because of the ‘setuid’ line in the script, it runs with root powers.
It’s a smart move to hide the file from tools like LinPEAS, which is frustrating. Sadly, we can’t change this script to add our own commands for getting higher access.
In the next part, we found a big security problem with the SETUID abilities on the Perl program, even though it’s restricted by AppArmor.
The bug mentioned in the link explains that if a script has a shebang pointing to the right program, it gets around the restrictions set by the AppArmor profile.
This is a serious bug, one we can use to get higher access to ‘root’ and finally get 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
Finishing this box gives me a huge sense of relief. It was really tough, and I couldn’t have done it without the help I got.
I have to admit, there were times when I almost gave up, especially at the start. But I kept going and eventually succeeded. Even though I still don’t understand all the mistakes I made, I made it to the end.
One thing I struggled with was getting reverse shells through Burp, which shows I need to get better at it.
During the part where I had to get higher access, I realized that just using automated tools might not always work. Without help from outside, I don’t think I would’ve figured it out on my own.
I probably would’ve kept using GTFO bins until I hit a dead end. This box taught me the importance of thinking differently and trying new things. It also showed me how much I still have to learn, which makes me think about my own abilities. Until next time!
Also Read: HTB Write-ups
