Description

DC-1 is a purposely built vulnerable lab for the purpose of gaining experience in the world of penetration testing, designed to be a challenge for beginners.

To successfully complete this challenge, one will require Linux skills, familiarity with the Linux command line and experience with basic penetration testing tools, such as the tools that can be found on Kali Linux, or Parrot Security OS.

Although there are five (5) flags in total, the ultimate goal is to find and read the flag in root’s home directory. You don’t even need to be root to do this, however, you will require root privileges.

For the purposes of this exercise, I will demonstrate how to acquire the flag in the root directory. But keep note that this may not be the only way to do it and there may be quicker ways to do so, including using brute force against the services.

You can get the vulnerable machine from the VulnHub website by following this link. I won’t go into the process of setting up the machine as each person may set it up differently. For this exercise, I am using VMWare Fusion configured with NAT. Both my Kali machine and the vulnerable machine are on the same subnet.

Credit goes to DCAU who created the box and can be accessed on twitter via his handle @DCAU

Step 1 - Finding the machine and its services

Given that the machine is on the same subnet, I need to find the IP for the machine to enable me explore further.

sudo netdiscover -i eth1 -r 172.16.122.0/16

Finding the IP of the server, we are able to use nmap to discover the ports and services that are running.

# This is a noisy scan and searches all 65,535 ports and wouldn't typically 
# be used in an actual penetration testing exercise.

nmap -A -p- 172.16.122.5 

We are able to determine that SSH and a Web Server are running on port 22 and 80 respectively. In addition, the Web server has a robots.txt file that informs web crawlers to ignore.

Accessing the web server via the browser takes us to a Drupal Website.

Step 2 - Identifying vulnerabilities and gaining access to the web portal

From the previous scan, we recognized that we had a robots.txt file. Accessing this file via the browsers lists files and folders for exclusion from a typical web crawler that can also prove useful for us to find additional information about the site.

Discovering the verison of Drupal used would enable us find an existing vulnerability that we can exploit. Though most of these files are default files used for a typical installation of upgrade of Drupal, the UPGRADE.txt file showed particular promise on the version of Drupal being run.

From this, we can make the assumption that the administrator either installed Version 7 or performed an upgrade of Drupal from an older version to Version 7.

Working with this assumption, we can leverage on searchsploit to determine whether an existing vulnerability exists that we can use.

searchsploit drupal

The search has identified a number of Drupal exploits that we can use. Though the others could be tailored for use, I particularly liked the highlighted one because:

• It can be used for Drupal versions that are within our assumptions (Version 7).
• If it works, it will allow us to have persistent access to the admin panel of the website.
• It leverages on Python which I am more familiar with.

We can do a quick review of the code to see how best we can use it.

less /usr/share/exploitdb/exploits/php/webapps/34992.py 

The code is well-documented. Scrolling to the bottom of the code, we can see how best to use the code from the options presented. The code takes a target (-t option), a username of choice (-u option) and a password of choice for that account (-p option).

Using the code below, we created an administrator account named “drupal_admin” with the password as “drupal” (your target IP may differ depending on your earlier set up).

# From reading the code, you will also notice that it runs on Python 2 and not Python 3
# Also, take note of the need to include the protocol ('http' in my case).
python2.7 /usr/share/exploitdb/exploits/php/webapps/34992.py -u drupal_admin -p drupal -t http://172.16.122.5

We have successfully created the account.

Going back to the homepage, we can log in using the credentials to access the admin homepage.

We now have persistent access to the web portal as an administrator.

Step 3 - Explore the web portal and break out to the host

With our admin account, navigating to the content tab enables us to find flag3.

flag3 gives us the following information that may prove useful in our quest :

Special PERMS will help FIND the passwd - but you’ll need to -exec that command to work out how to get what’s in the shadow.

This cryptic message seems to make mention of the FIND command with the options -perm and -exec. We will keep a note of this hypothesis and refer to it when we manage to gain access to the underlying OS.

Our next step is to try and see whether we can gain a reverse shell executed by Drupal’s PHP server. This would require us to upload code that can create this remote connection. However, the only noticeable upload function can be seen when creating a new article for the site under ** Content -> Add Content -> Article **, and this option only accepts image files.

By default, PHP code is not accepted as part of the article but, on further exploration of the Drupal site and its features, we can see that we can enable an option within the Modules called PHP Filters that will enable us to add PHP snippets within the articles.

Checking this option, saving the configuration at the bottom of the page and returning to the new article page, we are able to add PHP code directly into the article from the drop-down below:

We can customize the PHP reverse shell script to have the site create a reverse shell back to our machine. Since I am using Kali, I will edit the php_reverse_shell.php script (I will use nano from the command line but you can use any text editor of your choice):

# I will make a copy of the script to my Downloads folder.
cp /usr/share/webshells/php/php-reverse-shell.php ~/Downloads

# And then make some edits to the php file.
nano -w /usr/share/webshells/php/php-reverse-shell.php

We shall change the ip and the port numbers to reflect the IP address of our machine and a free port.

Once the changes have been made, we shall copy this code into a new article with the PHP code feature enabled from the drop-down.

Before saving the page, ensure that you have your reverse listener active on your machine

# A different reverse listener like netcat (nc) can be used. I prefer pwncat as it 'automagically' creates a stable shell.

pwncat -lp 4444 

With the listener ready, you can save the article (with a name of your choice). This should initiate a reverse shell that will land you in the command prompt of the web server ‘user’.

Step 4 - Reviewing our notes and scanning the target

Now that we have access to the hosts, we can do a search for exisitng vulnerabilities that we could exploit to get root access. To start, we can do a basic search to find out if there are any interesting binary files that have the SUID bit incorrectly configured:

find / -perm /4000 2>/dev/null

Recall in Step 3 we found an interesting message that formed an assumption that we could exploit the FIND command with its -exec parameter. This particular command also has the SUID bit set to enable us run the command with the same privileges as the file owner (in this case root).

/usr/bin/find . -exec /bin/sh \; -quit

And that’s about it! I hope this has been super-useful. Technically as root, you could quickly scan the entire filesystem to get all the flags if it interests you.