Monday, November 16, 2009

Wednesday, November 11, 2009

Metasploit Autopwn: Hacking made simple

Nowadays, exploiting a system requires little, if no knowledge of computer systems or networking. Merely, someone with 10 minutes on their hands that is interested enough to Google how it’s done.

One with very little skills has the ability to fire up Metasploit, load an exploit, and fire it at the target system – giving attacker’s the ability to compromise a system within minutes.

I thought I would write a post on Metasploit’s autopwn module to reiterate just how simple it is to attack/compromise a system in today’s environment. My intentions here are to give you a tutorial on the Metasploit autopwn module and provide a timely reminder on just how important it is to have a good patch policy in place. I would also recommend regular audits on system services.

The tools I will be using in this tutorial are:
  • Nessus - A free vulnerability scanner for Mac OS, Windows and Linux
  • Metasploit – framework 3 - A free exploit framework for launching exploits against targets
  • A virtual machine running an unpatched version of Windows XP SP2 as my target system
1. First we’ll fire up Nessus and run a scan on our network.

As we can see, Nessus has picked up several ‘High’ risk vulnerabilities on the target system (indicated by the red highlighting).

2. We will now export our Nessus scan results. In order to use these results in Metasploit’s autopwn module, we will need to save the results in the Nessus .nbe format.

First click the ‘Export…” button In the ‘Report’ tab. Second, select the ‘Save as…’ option and choose ‘NBE (*.nbe)’. Now save the file.

3. Now we want to import our Nessus output into Metasploit. Browse to your Metasploit main directory (On Backtrack 4 it will be /pentest/exploits/framework3) and fire up Metasploit.
# ./msfconsole

 Note: I am using Linux for this section, but Windows is fine.

4. Next we want to create a database to store our Nessus results. This will allow autopwn to quickly traverse the database and assess whether the vulnerabilities found are indeed exploitable.
At the Metasploit console, type:
msf > db_create
You should see the following:

You have just created an sqlite database to store the results of the Nessus scan.
Note: Metasploit has context sensitive help which is very useful. If you type ‘help’ in the Metasploit console at any stage of this process you will be able to see the commands available to you for the specific module you have loaded. Very cool :)

5. We’ll now connect to our newly created database. To do this, we type:
msf > db_connect
You’ll notice that Metasploit is smart enough to realize that you want to connect to the most recently created database. If you wanted to connect to a different database – one that you had possibly made earlier – you would specifiy the path/database name after the db_connect command i.e. db_connect /root/.msf3/test.db

6. Now lets import our Nessus results into Metasploit. For this, we type:
msf > db_import_nessus_nbe /root/test.nbe
Notice here I have added the path to my Nessus output file after the import command (db_import_nessus_nbe).

Note: You will not get any confirmation after you have imported the Nessus results into your database. Instead, you will just be returned to the Metasploit console prompt.

7. Now we get to the autopwn part! It is a good idea at this point to type:
msf > db_autopwn
This will display a list of arguments that the autopwn module can use.

The arguments that I will first be using are:
-t Show all matching exploit modules
-x Select modules based on vulnerability references
msf > db_autopwn –t -x
Note: At this point I could just use –e and autopwn would try and exploit the target system. However, in my case, I know that the target system is vulnerable to multiple denial of service exploits which will cause my system to crash – and I don’t particularly want that :)

8. Exploiting! Now that we have seen which vulnerabilities are available to exploit, we have two options:
a)Manually set up the exploit, or
b)Let autopwn do the work for us

For the sake of this tutorial, I’ll use the autopwn option.

If you are happy to use all available exploits against the target system, the process would be as simple as:
msf > db_autopwn –x –e –r
And viola! If one of the exploits was successful, you will be presented with a command shell of the target system.

I hope this tutorial has shown just how simple it is in today’s environment to compromise an out-of-date/unpatched/misconfigured system.  I trust this reiterates the importance of maintaining a good patch policy alongside regular audits of system services.

Tuesday, November 10, 2009

Milw0rm is back! -- Sort Of

If you are someone who is interested in exploit code, you would have undoubtedly noticed that has been dormant since September. Speculation has arisen over Str0ke's health -- with some even stating that he is dead. This is incorrect. However, whilst str0ke's health is intact, the milw0rm repository is not. It appears the site has been troubled by DoS attacks and Str0ke has been subject to trolling. However, with the unknown state of milw0rm, another exploit resource has risen.

On November 4, Offensive Security announced they will be maintaining a new exploit repository -- one which replaces milw0rm. The Offensive Security Exploit Archive "...will be picking up from the place Milw0rm left, and will be maintaining a new exploit archive collection which will be open to the public."

Copy-cat resources currently exist which mirror milw0rm:

Monday, November 9, 2009

New Australian iPhone Worm

Yesterday, A newly discovered iPhone worm was found in the wild. The worm targets jailbroken iPhones - primarily affecting Australian 3G customers.

In this post I will sum up the worms operation and provide links on its removal, source code and further readings.

Initially, the worm scans for Australian 3G IP addresses (hardcoded into the source) on the Vodafone, Optus and Telstra networks. It spreads through 'jailbroken' iPhones using the Cydia application.

The worm spreads through the use of default SSH credentials. If the default SSH root password has not been changed (alpine), the worm will connect to port 22 and copy itself onto the phone. The worm will then kill the SSH service (to avoid someone else compromising the phone) and change the background image to Rick Astley. The worm will then look for other deices to infect.

Whilst the worm is currently frivolous in it's operations, it doesn't take much imagination to realise the potential for something more malicious.

So now people will be asking question, why am I posting the source code? The reason here is twofold. I think it's important to not only get the code out into the public so people can understand/identify the risk it poses, but also effectively defend against it should more malicious versions of the code become available.

Source Code
Removal of the Worm
Interview with ikee, the worm's author

More details about the worm:
First identification (author involved)