Vulnish

Name: Vulnish
Difficulty: Medium
OS: Linux

Link:https://tryhackme.com/r/room/vulnis
Author:HamzaShah

Overview

Initial Approach

In this box, the attacker must discover and compromise a custom webapp with weak credentials. Leveraging their initial access reveals a note about poor file hygeine as well as names of users on the machine. By finding the possibility for path traversal in the webapp's primary functionality, the attacker is able to confirm the found username does in fact exist.

Finding a Foothold

Keeping in mind the other services running on the machine, the attacker is able to brute-force their way onto the machine via FTP over port 21. A quick check, and they're able to confirm that the same set of credentials works to connect over SSH on port 22 as well.

Path to Root

With a classic privilege escalation thanks to a careless Sticky Bit, the attacker is able to exploit the /usr/bin/nano binary to quickly escalate to root and fully copmromise the machine.

Write-Up

Initial Scans

Starting off with Nmap, we'll scan the machine to see what services it offers and what attack surface it presents. I prefer running this in two parts, a simple scan against all ports, then a detailed scan against the ports we find as open.

sudo nmap -T4 -p- -v -oN scans/initial 10.10.234.132
sudo nmap -T4 -p21,22,80 -sC -sV -v -oN scans/specific 10.10.234.132

As we have ports 21, 22 and 80 open, a good place to start gathering information about the target is their web page. Traveling to http://10.10.234.132, we're greeted with a 403 - Forbidden.

Taking note of the service version, Apache/2.4.29, our best move is to start some directory scans and see if there's more to this app than meets the eye.

ffuf -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt -u http://10.10.234.132/FUZZ -o tlds -t 20

Breaking down this command a bit:

• -w: Specifies what wordlist to use
• -u: The target URL to test against
• FUZZ: Where to insert our words
• -o: Specifying an output file, tlds
• -t: Setting a limit to the number of concurrent threads with

Normally, in a THM scenario we wouldn't be so mindful of our thread count, the default is almost always fine. This time however, the machine is a bit unstable, and by letting FFuF run at full speed, the box was at risk of tipping over. Adjusting our threads lets us make the most of this situation, and minimizes the chance of accidentally knocking over the machine.

Port 80

Looking at our FFuF scan, it looks like we've found a 301 - redirect on http://10.10.234.132/secrets. Let's see if this page has anything interesting to us.

Nice! With a login screen now visible, we can start testing this web app to see what we can find in it.

A good methodology for testing input fields is to start with what's obvious, move to what's easy and then if you nothing else works, start testing complex attacks. This helps save time and prevents overthinking.

Since this page has nothing beyond the login prompt itself, let's start with the easy. A test of Admin:Admin, and shockingly, it works! As silly as it sounds, default credentials are commonly left in real world software, it might not always be the path forward, but when it is? Man is it sweet.

Another straight-forward page, the admin panel we land on has a note addressed to Sec from Ludde, these are likely users on this machine and are worth noting down.

For functionality, we have a search bar that doesn't appear to return anything when used. Using Burp Suite -- a web proxy software -- to intercept our traffic, we're able to see that whatever we search is sent to an endpoint called /secrets/process.php.

Further testing of this endpoint reveals that it is susceptible to a path traversal attack, meaning it doesn't properly protect the rest of the file system from being reachable. This can be easily confirmed by entering ../../../etc/hosts as our search term.

Knowing that we can use this to our advantage, we can confirm our user sec exists by checking for ../../../home/sec/.

Finding a Foothold

With a confirmed user, we can try to bruteforce potential credentials against the open FTP port. This is easily done with a tool such as hydra:

hydra -l sec -P /usr/share/wordlists/rockyou.txt ftp://10.10.234.132 -V 

With the following flags:

• -l: Username
• -P: Password List
• ftp://: The target protocol
• -V: Verbose Output

Letting this run will quickly confirm the user has a weak password of password123. Using the credentials sec:password123, we can attempt to connect to the machine over SSH.

A side note, you can see the machine's IP address changed on me. I forgot to extend the timer on THM while testing! Now that we're connected to the machine though, we can grab the user.txt flag and submit it.

Privilege Escalation

Similar to our methodology when testing input fields, it's usually a good call to test for the obvious, easy, and then the complex paths for privilege escalation. When dealing with a Linux machine, the "obvious" to me is to always check what sudo privileges our user has.

sudo -l

Is a simple command that lets us list in what ways we can use sudo.

Immediately my eyes pick out the line, (ALL : ALL) /usr/bin/nano. This means that our user, sec, is able to run nano as root. A wonderful resource when you have a situation like this is https://gtfobins.github.io. GTFObins is a collection of straight-forward privilege escalation methods that rely on exploiting default Linux binaries, perfect for our use case.

Specifically looking at the path listed for "Nano" and "SUDO", we see the following:

Now let's exploit this. After running sudo nano, we will click CTRL+R followed by CTRL+X. In the prompt that appears, we'll type reset; bash 1>&0 2>&0, a slight deviation from what's recommended in GTFObins.

And there we have it! With root access, we can quickly navigate to /root and grab the root.txt flag.

Congratulations!