WPS Attack Detection and Reaction

For those of us in the security industry we are well aware that reactions to attacks can take vendors a long time to develop and deploy a preventative measure.  This is especially true with embedded devices that have no auto-update feature and/or are completely forgotten about once they are up and running on the network.

As a refresher in December of 2011 an attack was published that targeted a weakness in the Wi-Fi Protected Setup (WPS) protocol that demonstrates how to significantly decrease the amount of attempts needed to derive a valid WPS PIN during a brute force attack.  This attack leaves most routers that have WPS enabled vulnerable to an attack that will allow an attacker to learn the WPA Pre-Shared Key (PSK) or WEP key as well as gain access to more configuration information.

Click here to see a video of an attack against WPS using SILICA.

Most routers are still vulnerable to this attack today because there is no easy way to disable WPS in the router's configuration interface (a regular user is not going to go through the trouble of modifying firmware) and not very many people/organizations are very good about checking for and updating new firmware.  I should probably also mention the probability that most people that use or administer a wireless router are completely oblivious to the fact that there is such a weakness in WPS and don't disable it even if they can (after all it is a protocol meant to provide a convenient method to the admin and network users).

Even though it usually takes a long time for vendors to respond to this kind of attack we have recently seen a change in Netgear's firmware that actually addresses the security weakness.  Take a look at the following section taken from a Netgear R6300 web interface:

This is the first vendor response that I have seen for the WPS PIN attack.  After 3 failed attempts the feature is disabled and you get the following message next to the feature configuration: 

 

This obviously does offer another avenue of attack in the tune of a not-so-exciting denial of service (DoS) making it easy for an attacker to turn off WPS all together.

This slightly changes the game (and by slightly I mean not very much).  It used to be that identifying that WPS is enabled was all an attacker needed to determine if the AP was vulnerable to this attack (no major or minor versions to check before launching the attack - it's kind of the same feeling you get when you are pentesting a ColdFusion server/application; it doesn't matter the version you just know it's vulnerable). 

The WPS bug and attack are not going anywhere for a long time but it's interesting to see the proactive actions of vendors hoping for an eventual extinction.  I will keep you posted if I see any similar trends.

SWARM and Vulnerability Impact

Yesterday the latest D2 exploit pack for CANVAS was released. In it there was an exploit module for the local file include in TP-LINK's TL-WR841N Wireless Router (CVE-2012-6276). I'd been looking at some data in SWARM that had a high concentration of TP-LINK routers so in the back of my mind I thought that it'd be interesting to see if I could find vulnerable routers with a high degree of confidence.

For those of you playing at home SWARM is Immunity's answer to distributed and parallel CANVAS. If you need to scale CANVAS to hundreds of thousands of IPs per hour, then SWARM is the solution. One of the things that SWARM is really good at is recon on a massive scale which can give you perspective on how much you should care about a particular vulnerability. Sure enough today another interesting router vulnerability was disclosed by the folks at www.s3cur1ty.de, and they were nice enough to include some tips on finding these routers. Having looked at well over 100,000,000 IPs with SWARM at this point I decided to see how many of these routers were really available.

We learned a few things:
1) We had much better results parsing the index page for the webserver than relying on server banners because of #2

2) There are a variety of server headers associated with this product. We saw: Mathopd, "Linux, HTTP/1.1, DIR-[3|6]00", obviously spoofed headers, and even blank server headers

3) Sometimes you get the firmware version in the http server header (2.X series), others you have to parse the server's index.html (1.x), occasionally you wouldn't get it at all

4) Some configurations will leak what appear to be internal host names and MAC addresses to unauthenticated users (name=$HOSTNAME&key=$MAC_ADDR is the string if you're curious). They didn't look like SSIDs but without more context it's hard to tell.

5) There aren't that many easily found routers of this type with their web servers exposed to the internet, out of our data set we found ~1500

6) We found only a handful of routers which met the version criteria to be considered vulnerable

A subtle thing people forget with scans of any real magnitude is that they offer a rolling snapshot of the IP space. The results you get for a particular IP reflect only the results for that IP at the time the request was sent. This may seem obvious but if your scan takes two days to run you can't consider the output to be "Thursday's results". Half your requests went out on Thursday the other half Friday. For environments where hosts are statically mapped this isn't as big of an issue but when you look at big networks it becomes a headache. It's fun to see the exact same host pop up at multiple IPs within the same set of results. It's possible you'll miss hosts entirely if they jump from the end of the IP range to the beginning while the scan is running.

Going through this exercise gave me another idea for SWARM. Many American ISPs now bundle anti-virus with their broadband offerings and security is playing a bigger part of the marketing narrative. I think a neat application of SWARM that fits with this is for your ISP to notify you if your router has a public vulnerability. At some set interval the ISP can kick off a scan that finds all the routers with their webservers exposed to the internet, then filter that through some Python to pick out models with public bugs (which is all of them). Easy, automated, helpful.