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
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.
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_createYou 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_connectYou’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.nbeNotice 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_autopwnThis 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 -xNote: 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 –rAnd 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.