CyberSecLabs Office Write-Up

User / www-data and dwight

First we will run an nmap scan of the machine IP address, export our results to an HTML file, and view it in Firefox-ESR.

We see there is a HTTP Web Server running on Port 80, a HTTPS Web Server on Port 443, and a listening SSH Server on Port 22. Let’s add the IP address and hostname to our /etc/hosts file.

Next let’s take a look at the website on port 80.

Oh just another day at the Dunder Mifflin Office! It looks like Dwight has initiated some sort of “Doomsday Device” and is using a WordPress site and Forum to tell everyone in the office about it. We will soon see if there is any way we can get user credentials or bypass authentication.

Also when we take a look at the HTTPS server we see it is just a default Apache landing page.

The SSL certificate also has dwight@office.csl as a listed email address. This may be a username we can try to use for the log-in.

Next let’s try some directory fuzzing for our web servers. Not much turns up for the server on port 80, but the secure web server does have some interesting endpoints.

Let’s take a look at the forum endpoint and see if we can find anymore useful information.

Looks like everyone in office is concerned about the Accountability Booster, each trying to find a way to deal with it. Some are even trying to brute force a log-in portal that was forwarded to Jim’s local machine. We haven’t found any such portal yet, but it’s good to have an idea what to maybe look for later. Let’s keep enumerating this site and check out what’s on the Login and Chat Logs page.

We get an Access Denied on the Login page, but the Chat Logs page does show us something interesting.

It appears to load and print out all of the chat messages we just read from a Text File. The web server is loading the contents of a local file using the ?file= parameter. This looks like a great place to try a Directory Traversal exploit. Maybe we can get the server to print out the contents of a useful file.

Let’s run wfuzz with the LFI-Jhaddix.txt wordlist found in the SecLists Github Repository, trying each phrase as a filename in the URL parameter and see if we can find any useful files on the machine.

There seems to be a problem. It looks like wfuzz is returning a 200 OK HTTP Response Code on every filename that we try. That’s not very useful as we won’t know which files are really there or not. Luckily we can see that each response has a different amount of returned content and we can filter these based on the amount of data received. Looking at our output, it looks like anything with a line length of 27 may not actually be returning a valid file. Let’s filter out any responses that return that number of lines and see what we have.

That’s better. The first thing that catches my eye is ../.htpasswd, which is a flat-file used to store usernames and passwords for basic authentication of HTTP users. Let’s use that file as a parameter and see what it returns.

It contained a username/password hash combination for dwight! I will copy this hash over to another computer that has the hash cracker JohnTheRipper installed and we will try to brute force crack this hash with the default wordlist.

And we were successful. We should now have log-in credentials for the WordPress log-in portal.

We are now successfully logged into the WordPress Admin Dashboard, and it looks like we have the ability to upload files. We will use this to get shell access to the machine with a Local File Inclusion exploit, which will allow us to run the code in our uploaded file on the machine hosting the web server.

First we use the ifconfig command to find out what our network IP address is.

Now we find a PHP Reverse Shell Script and add our IP address to it, as well as a port number that we will set up a netcat listener on for our script to call back to. Here we have renamed the script to a.php.

We start our netcat listener, and upload our reverse shell script.

To run our script we just append the filename to the web server URL.

And when we check our listener, we see that we received a callback and now have shell access to the machine.

We run the whoami command and see that we have access as user www-data, and with a little bit of poking around we find the flag file /home/dwight/access.txt and print out the contents.

When we run sudo -l we see that the sudoers file is configured to give our current user the ability to run the command /bin/bash with user dwight privileges, and is configured to do so without requiring a password using the sudo command. So running sudo -u dwight /bin/bash will effectively give us a bash shell prompt with dwight’s privilege settings. After doing this we find dwight’s .ssh directory and see that it is empty.

To get ssh log-in access to dwight on this machine, let’s create a ssh key-pair on our host machine with ssh-keygen.

Then copy the public key that we created and paste it onto /home/dwight/.ssh/authorized_keys on the remote machine.

We now have ssh access to dwight on the remote machine with our private key file.

Privilege Escalation / root

After browsing around the machine for a few minutes we find a file called webmin-setup.out.

Looking at this file we can see the version number and port that this application is supposed to be running on.

Let’s use netstat to see if there is actually anything running on this port.

We find that there is an application using this port, so it is most likely this Webmin. But what exactly is Webmin?

Wikipedia tells us that it is a web based system configuration tool for linux. Let’s do a little bit of searching and see if the version of this software that is installed has any publicly known vulnerabilities.

It most definitely does have known vulnerabilities. Let’s use ssh to forward this service port over to our local machine and take a look at it in our browser.

And here we have the Log-in Portal for the service. Is this the portal that Jim was talking about trying to find a password for? I’m not sure brute force guessing passwords is the best way to approach this, since it has some commonly known vulnerabilities. Let’s start up the Metasploit Framework Console with the msfconsole command on our host machine and search for exploit scripts for this service. We will try the webmin_backdoor exploit, as it seems that we do not need to be authenticated to successfully use this exploit.

We look at the options for the exploit and set the remote machine’s address to our localhost address that we are forwarding the service to, then set our listening address to our host machine’s network address.

Next we cross our fingers and run the exploit. Success! The exploit ran and called back to the listener giving us an open session.

We now have a shell prompt with root level privileges and can print the flag file /root/system.txt

Now that we have root access to the machine it would be trivial to stop Dwight’s “Doomsday Device”, or set up persistent access and do anything else we wanted to do. I will thank the creator for this very fun, creative challenge. I thoroughly enjoyed it.