Metasploiting Metasploitable

In my quest to become a IT Security professional I've been playing around with the purposely vulnerable Linux distribution Metasploitable 2.

Metasploitable 2 is produced by Rapid 7, the company behind Metasploit.  If you don't know already, Metasploit is a penetration testing framework that allows for development of exploits and execution of general penetration testing tasks.  Metasploitable 2 is designed with several vulnerabilities in order for one to learn how Metasploit and learn about penetration testing in general.

I decided to give exploiting the backdoor vulnerability in vsftpd 2.3.4 a try.

First I began with a nmap scan against the host to verify that it was running the vulnerable version of vsftpd.

I then setup Metasploit for exploitation of the vulnerability. 

The PAYLOAD command sets the payload to be sent to the target, in this case an interactive shell  that allows one to run commands on the target.  The RHOST command sets the IP address of the target host.

I then ran the exploit and got root on the box.

Metasploitable 2 and other distros like it make penetration testing accessible for those who don't get to do it for a living.   It also gives one the opportunity to learn how to use the various security tools without risk of getting into any trouble.

Anonymizing With Tor

While using the Internet, one may wish to anonymize their activities as much as possible.  Tor is a tool that allows for some anonymity.

In it's simplest form, tor is a tool that routes TCP traffic through a series of nodes while encrypting it so that the destination host cannot determine where the traffic originated.  The tor website has a much more technical description of it along with various tools and applications that allow you to use it.

Of course one can see how a tool like this can be useful for security enthusiasts for both good and bad.

tor creates a proxy server on the local host that allows all traffic pointed to the it to be routed through the tor network.  However, if an application cannot be configured to use a proxy, then a tool like tsocks can be used to direct the application's traffic through the tor proxy.

On a Debian based system tor and nmap can be installed by using the familar apt-get install tor tsocks

Once installed, all one has to do is edit the /etc/tsocks.conf file and change the server_port entry to specify tor's port 9050 as the server port and the server entry to 127.0.0.1.  tor itself should need no configuration at all.

To use applications through tor, either configuration the application to use a proxy at 127.0.0.1:9050 or if the application doesn't support proxy use, just run it by pre-pending tsocks to the command (i.e tsocks nmap scanme.nmap.org).  Keep in mind that tor only supports anonymizing of TCP traffic and not UDP and ICMP.

One popular usage of tor is to anonymize nmap scans.  You simply run nmap via tsocks as follows: tsocks nmap <host> -PN  .  The -PN argument is required so that nmap doesn't perform a ping scan which will reveal your IP address. 

I would provide examples, but I would have to change my network configuration in order to perform a pcap to show tor actually doing it's thing.

One caveat of tor is that it's quite slow do to the way it routes your traffic through three hops before it gets to the destination host.  A tool called tortunnel routes your traffic only through one exit node which will improve performance, but reduce anonyminity.

Learning Exchange 2010

Currently I am working with Exchange 2010 in my home lab.

I have set up a Exchange 2010 organization in the following manner using VMware ESXi 5.1:

The following are some notes on some issues I ran into with working through various lab exercises.

Configuring of routing between sites:
Set a persistant route on NYDC1 and NYDC2 to 10.1.1.0/24 via Teal so traffic could get back to CHIDC1.

Set a static route on wireless router to 10.1.1.0/24 via Teal (192.168.1.106) on the LAN interface so that NAT'd traffic to the internet would know where to be sent.

After removing persistant route from NYDC1 and NYDC2, replication to CHIDC1 stopped working. 

After running a packet capture on teal it was found that replication traffic was going out from CHIDC1 but not going back to it.  No traffic was going back to CHIDC1 at all from NYDC1 and NYDC2.  This caused issues with install Exchange 2010 SP2 on the mailbox server.

dcdiag reported replcation errors.  When replicated was forced via sites and services, a schema mismatch was found.  After waiting for 15 - 20 mins, the schema mismatch resolved itself and Exchange 2010 SP2 installation completed successfully.

What is strange is that there is a static route on my router that points to the network that CHIDC1 is in, so it should forward traffic to it, however it did not seem to work properly for NYDC1 and NYDC2.

Removing public folder database:
Tried the following and ran into permissions errors: http://technet.microsoft.com/en-us/library/bb201664.aspx

Ensured administrator to public folder management group and gave administrator AllExtendedRights on \non_ipm_subtree public folders.  Still wasn't able to remove system public folders.

Found that all mailbox databases were using public folders (get-mailboxdatabase | ft name, publicfolderdatabase).

Used ADSIedit to remove public folder configuration from mailbox databases and to delete the public folder database. (http://exchangeserverpro.com/remove-default-public-folder-database-exchange-mailbox-database)

Troubleshooting OWA not working:

Found that OWA wasn't accessible after upgrade to Exchange 2010 SP2.

Found that all Exchange services weren't started on mailbox and client access server.  Started/restarted all services.  Didn't fix issue.

Checked event logs and found that there was an error in the web.config file for the OWA IIS site.  Tried commenting out the line with the error and tried using the backup web.config file, neither fixed issue.

Checked in Exchange installation log and found that the Service Pack 2 installation hadn't completed successfully.  Re-installed service pack 2 on the client access/hub transport server and rebooted.  Fixed issue.

Later found that OWA access was timing out.  Believe that I restarted Microsoft Exchange RPC Client Access service to fix the issue.

Later found out that mail wasn't being sent within the organization.  Restarted Microsoft Exchange Information Store service to fix the issue.

I'm still working through the material so most likely there will be more to follow.

Idle Scanning With Nmap

As is it has become quite obvious, nmap is one for my favourite tools and I'm trying to learn as much about it is possible.

While reading through the nmap documentation I came across the technique known as idle scanning.

Idle scanning allows you to scan a target without sending any traffic to it.  This is done by using what's called a zombie host to bounce your traffic off of so that the traffic appears to come from the zombie host and not you.  The way it works is very clever and this page on the nmap site explains how it works in detail.

The main issue with a performing idle scans is to find a zombie host that is completely stagnant and increments it's IPID in the way that nmap requires for idle scans to work.  The following command utilizing one of nmap's scripting engine scripts will discover if a host supports the IPID feature in the way that nmap can use it for idle scanning;  nmap --script=ipidseq -v <host>.  If the Host script results returns all zeros, then the host cannot be used for idle scanning, if it returns incremental, it can be.

I set out to test idle scanning on my test network.  I tried using a Debian Linux VM as a zombie host but found that it's IPID sequence was all zeros.  I tried a Windows Server 2008 R2 VM with success.

Here are the results:

1) The IP address of the attacking machine:

 2) The IP address of the zombie host:

3) The IP address of the target host:

4) The scan being run and the results:

In order for the scan to work there needs to be a non-firewalled port on the zombie host that both the attacking and target host can connect.  The -Pn option is used to prevent a ping scan so that no ICMP traffic is sent to the target.  If ICMP traffic is sent it would reveal your IP address.

5) A Wireshark capture from the target host showing that the traffic is coming from the zombie host:

As you can see, idle scanning is a very useful technique.  It's main caveats are that it cannot really differentiate between closed a filtered ports, it can take significantly longer than a normal scan and it may be difficult to find a idle host to use as a zombie host.