Sedna is the second vulnerable VM released by hackfest.ca this month.  Much of the first steps of enumeration will be similar to that of my write up for the first VM in the series.

The first thing I start with is an Nmap scan.  The output is below, shortened for brevity.

Like before, the index.html page on port 80 did not disclose much useful information.  To enumerate these web applications, I once again used Nikto.  I ran this tool against the server on both port 80 and port 8080.

Nikto output of port 8080:

Nikto output of port 80:

I first went after the Apache Tomcat server.  I tried to brute force the manager password using the metasploit module auxiliary/scanner/http/tomcat_mgr_login.  After using a couple different lists, I was not able to discover the password.  I decided to let the Tomcat server sit for a moment and move on to the webserver on port 80.

During the Nikto scan a license.txt file was found.  As stated by the Nikto output, “License file found may identify site software”.  I looked at the content of the file and it did indeed disclose the name of some software that was running.

This was at the top of the output:

Seeing as I know knew there was the “BuilderEngine” software on this server, I went searching in ExploitDB for a relevant exploit.  Based on the license, we can see that the software likely hadn’t been updated since 2015.  This exploit for BuilderEngine was published in 2016.  The vulnerability is unauthenticated file upload. The PoC lists some simple HTML to upload a file and post it to the vulnerable service.  The only thing we need to modify is change “localhost” to the IP of our target server.

Because we can see that this server is running PHP, we can use the pentestmonkey php reverse shell.

We just need to make a few modifications to point to our server:

The HTML PoC was saved to local file. Browsing to the file in a web browser allowed me to upload my PHP shell and have it accessible on the server.

The PHP shell could be triggered from http://10.0.1.22/files/pwn.php

I set up a netcat listener to catch the shell.

After a lot of enumeration, and attempting several exploits such as the overlayfs local root in ubuntu, I decided to look for something very recent. The dirtycow exploit was released late 2016 and is a good candidate to exploit this relatively newer Ubuntu system.  There is more than one way to skin a cow, and the dirtycow Github page lists a number of PoCs. If you do a search on ExploitDB for an exploit the first one comes up is this one, which is based upon one of the original PoCs.  After downloading the exploit code, I modified the username, and hosted it on my attacker system:

I grabbed it using wget from the victim system, writing it into the /tmp directory.  I then followed the instructions in the exploit comments to compile it:

After the exploit ran, I was able to log into the system via SSH with my new n00py account.

At this point I now had root, but was really curious about the Tomcat server still.  While I was enumerating Tomcat I remember seeing some output in the 401 error that stated, “please examine the file conf/tomcat-users.xml in your installation. That file must contain the credentials to let you use this webapp.”

I found the tomcat-users.xml file, which disclosed the password for the management interface.

Knowing that Metasploit contained a module for automatically uploading a war file (exploit/multi/http/tomcat_mgr_upload) ,I attempted to use it in the default configuration:

It created a meterpreter shell, but it died immediately.  While I could have tried using different payloads withing the module, I decided to create a standalone payload with Msfvenom.

Once I created the war file, I could upload it through the Web UI.  I could then trigger it by visiting  http://10.0.1.22:8080/shell/

I still used Metasploit to catch the shell, as seen here:

As it turns out, Tomcat can also be used for privilege escalation as well. A recent exploit was discovered in 2016.  From the advisory:

I had tried running the exploit out of the box, but it failed because of this check:

As I already had root, I decided to make a simple modification just to see this exploit work.  I backed up the ld.so.preload file:

I then ran the exploit:

To save time, I just used the root account to restart Tomcat:

This triggered the rest of the exploit, allowing me to gain a root shell from the Tomcat7 account.

And there we have it.  While I’m sure there may be other ways to exploit this system, these are the ways I found.  If anyone knows of others, feel free to comment.