Fear thy neighbours

In a previous article All your AP base are belong to us, I touched on why it is so important to ensure that you do not have WPS running on your wireless access point (WAP) or router. If you had no alternative but to run WPS, then you should make certain that your router is upgraded/patched against the WPS vulnerability.

The purpose of this post is to expand on exactly why it is so important to secure your wireless network. Through practical examples, I will show you some activities a malicious attacker can perform on your network in a very short time if they gain access to your wireless network, and in most cases without your knowledge. As always, any examples I provide are performed in my home lab under controlled conditions. Under no circumstances should any of the information I provide be used without prior approval by whomever has engaged you to perform a penetration test or vulnerability assessment.

I will assume that that the client does not have WPS enabled any longer and that they are also not running WEP. If they are running WEP, I am sorry to say that they probably deserve to exploited. For this attack, I’ll show you why it is so imperative to have a complex WPA/2 key for joining your wireless network, and why you should always keep on top of those annoying “Windows update available” messages.

The scenario is as follows. We have been tasked to perform a penetration test and vulnerability assessment of a small business network. No Ethernet ports are available as they are all ‘shut’ unless explicitly ‘unshut’ by the systems administrator. No WPS is enabled and WEP is not configured. The wireless is secured by a non-standard PSK, and the SSID is hidden. The CEO would like a report with all your findings and recommendations. Simple 101 stuff. So let’s get cracking.

The easiest attack to perform on a WPA/2 encrypted wireless network is obviously a dictionary attack against the pre-shared key. I will not be going into detail of how you perform this attack as there are plenty of great articles and resources already written on this subject (see aircrack website for examples). The basic technique is to capture the 4-way handshake by de-associating a client, and then using that handshake capture to dictionary attack the WPA/2 passphrase. It goes without saying that the shorter or less complex your passphrase, the quicker and more likely it will be to expose the passphrase via a dictionary list. Time is the only factor protecting your WPA/2 key, so no matter how difficult your string is, it can, and will be broken. When I pentest a WPA/2 wireless network, I will generally only use a dictionary such as 18-in-1, rockyou, or even a smaller dictionary like darkc0de. If I do not ascertain the key in a large dictionary, I will usually use other methods of attack or move on to another entry point to the network.

First up we confirm the above in relation to switchports and the wireless network. We cannot see the SSID as it is hidden, however we simply disassociate a client and as they re-associate against the wireless network the SSID is exposed and we capture a 4-way handshake. We run a dictionary attack against the wireless network and crack the WPA2 PSK as it was found on line 98645 of the darkc0de dictionary; “4n7i70nic”.

We have now connected to the wireless network with the above PSK and have successfully been assigned a DHCP lease address of 192.168.77.43. If we did not get a DHCP lease we could simply watch our VAP monitor traffic and quickly ascertain the class of network we are working with. Now, the first step I always perform after gaining network access is to jump onto the router and have a bit of a look at whom I’m dealing with.

When we browse to the router homepage we are greeted by a login banner for a Billion router. This is a good start as at least we know which brand of router we are dealing with. A quick Google for “billion default username and password” returns the info which we are after. The default password is “admin”, so let’s give that a crack.

Voila, we are in. Sometimes it is not this easy as people do the right thing and set a non-default username and password for their routers. If for some reason I really want to jump onto the router for a ferret around, I will usually saturate the user’s network with enough traffic to make the unwilling user log onto their router to check what is going on. At the same time I arpspoof the network, have a packet capture looking explicitly for the HTTP POST method, and grab the login credentials accordingly. We’ll cover this more later in the article when we perform a man-in-the-middle (MITM) attack

The next logical step for me is to check if DHCP is running, and if so to look for how many other hosts are around. I would then start looking at system log files to check if I’m leaving any footprints around or whether a syslog server is receiving our logs. For now let’s check whether the ISP requires the user to authenticate onto their network for Internet access. Navigate to “Advanced Setup -> WAN Service” and click “Edit”. One ISP username and obfuscated password.

Now, of course you read my previous article Obfuscation is no longer sexy and you know we can simply change the input type from password to text, so I won’t spend time explaining this.

Now what? Well, it’s obvious isn’t it? For information gathering purposes it is ideal to include some real data in an assessment. We log onto the ISPs webpage as the user, grab some account info, contacts, payment details, and whatever other information is worthwhile to include in your report. You’ll most probably notice that the ISP has web mail available for it’s customers also, so jump onto the web mail portal and grab some emails for your report while you are at it.

Now it is time for the fun stuff. I have written my own custom tool for preforming MITM and other attacks, called “etKira“. Whilst I am not making etKira available to the general public, it does utilise in part some third party tools which are freely available and useful for your own pentesting toolkit. For this exercise, I will reference the publicly available tools, however I will not be going into any detail on any other aspects of etKira.

• SSLStrip by Moxie Marlinspike
• Driftnet by Chris Lightfoot
• urlsnarf by Dug Song
• Ettercap by Alberto Ornaghi and Marco Valleri

For this task I am arp spoofing all traffic destined from the IP address of 192.168.77.41 to the gateway address of 192.168.77.254. Why this particular address? When I performed a quick promiscuous tcpdump of the network, this device was generating a lot of traffic to internal and external IP addresses. This address is also interesting to me as when I performed a physical reconnaissance of the work site, the PC with a large printed label sticker of 192.168.77.41 was identified as belonging to the sysadmin…. This is a potential gold mine.

Let’s start with Driftnet. This tool will capture images and videos from a TCP stream. Whilst you probably think that this is a “sh!ts and giggles” type of tool, it is actually very useful for building bigger pictures of your target. For example, using this tool we have been able to see from images that our particular sysadmin likes to browse news websites and a number of other interesting sites. We can also see that he/she likes to troll through people’s Facebook and twitter profile images. Odd? Yes. Useful? Most definitely when profiling a target.

Perhaps work is a bit stressful for our sysadmin. Looks like he/she may be looking for holiday destinations.

Our target also has an interest in some type of footy or other sports tipping.

Looks like our sysadmin also has an interest in fishing judging from the facebook profile pictures he/she is trolling.

The following Driftnet output is interesting when you want to ensure your arpspoof is running accurately. This data should continuously tick over.

While my examples are very brief, you can start to understand just how important the Driftnet tool could be for your social engineering profiling activities.

Next, let’s take a look the urlsnarf. Urlsnarf outputs all seen HTTP traffic. Whilst this is again a great profiling tool, it’s a lot more important when it comes to credentials. The common HTTP POST methods will show up in our output, as well as coveted cookie session IDs and similar important information.

Whilst the above is great for plain HTTP POST data, what about all the SSL connections? “What do you mean ‘what about all the SSL connections’? SSL is secure!” I hear you say. Enter stage left sslstrip. From Moxie’s website: “It (sslstrip) will transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links. It also supports modes for supplying a favicon which looks like a lock icon, selective logging, and session denial.”

I’ll give you a moment to pick yourself up from the floor. That’s right; SSL isn’t as secure as you believe. Take a look at my Be still our bleeding hearts article for just one of many examples of why it’s not the golden chalice we all believe it is.

Let’s take a look at a snippet of our output.

As you can see from the output, we have exposed the website and the username/password credentials for our user. Not HTTP POST credentials, but credentials captured by hijacking HTTPS traffic without the user having any idea.

What else shall we look at? I always like to tcpdump all traffic from any pentest sessions. This gives us a lot of detail which we can troll through after our vulnerability assessment.

First example is another capture of POST data. I am a bit of a zealot when it comes to using tcpdump for all my investigations and tests, however you could use wireshark to come to the same results. I run the following to get the POST traffic:

tcpdump -s 0 -A 'tcp dst port 80 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354)' -r pentest/pentest.pcap

How about we use wireshark to have a look at a telnet session we noticed. If we follow the TCP stream, we can see the login credentials in plain text.

Now, there are plenty more tools we could run, and if you spent a good period of time testing the network you would end up with a lot of data to present to your client. You will probably capture some IMAP/POP/SMTP traffic, a lot more user credentials, finance and other private data, and a world of other information. Imagine how much more information you are going to gather when you start running Nexpose, Metasploit, Nessus, Burb, and the list goes on.

The moral of the story in this case is simple. Make sure you WPA/2 key is complex and non-English based. The above examples were performed from an authorised point of view. Imagine if you had a malicious person in your area with access to your wireless network. Identify theft, financial gains, and other criminal activities come to mind. Then think that with the right antennas and other equipment the attacker could be suburbs away. Scary to say the least. Change your PSKs regularly if you are in an environment which makes this task simple. Try not to use plain text protocols to log into devices, and make sure you log, and check said logs, as much as possible. If you can use x.509 certificates on top of you WPA/2 PSK it will take your wireless network to the next level and ensure that simple tasks such as above are more difficult to perform. If you have the ability and the approval, vulnerability or penetration test your network often, especially after any change or integration of new systems.