August 03, 2008

Autoimmunity disorder in Wireless LANs

It is August 2008, that is, famous US hacking conference time once again! This time BlackHat and Defcon are surrounded by the recent Dan Kaminsky's DNS vulnerability. You can get most of the details from the July's posts on his blog, and on the Metasploit blog. Test your DNS, retest, and patch! I couldn't miss not to blog about it! ;)

But not only of DNS we live, so Airtight Networks, as they did last year too with WEP cloaking, is presenting on Defcon 16 about something they called "Autoimmunity disorder in Wireless LANs". The name comes from biology: autoimmune disorder is a malfunction of the body's immune system that causes the body to attack its own tissues. The vulnerability found in WiFi access points allows an attacker to inject specially crafted packets that influence the AP behavior, creating a kind of self-DoS scenario.

It basically exploits one of the major threats against wireless technologies, Denial of Service (DoS), and becomes a new way of launching a DoS attack. It's not a new cutting-edge flaw, and although it is not a 802.11 design vulnerability, it's an AP implementation vulnerability we need to pay attention. The main reason behind it is the complexity of the 802.11 specification. The original 802.11-1999 is a 528 pages document, the 802.11i-2004 spec adds 190 pages, the new 802.11-2007 spec is 1232 pages in length, and now you need to add 802.11n (MIMO), 802.11e (WMM), 802.11w, 802.11f, 802.11k, 802.11r, as well as all the other upcoming IEEE extensions. Do you see how complex the development of an 802.11 AP or client driver can be?

The vulnerability has been found in all kinds of 802.11 APs, SOHO/home, open source and commercial. Each of them is vulnerable to different stimulus, based on their own 802.11 implementation, but with a similar end result. You need to wait till Defcon to get the details, where different malformed crafted frame samples will be demonstrated. Basically, referring back to biology, they have found different antigens (the crafted packets) for different AP implementations, that is, different substances that can stimulate an immune response.

The following scenario demonstrates the issue: Every time a WiFi client connects to an AP, it follows the authentication and association process, it gets an Association ID (AID), and a new entry is created for that client in the AP's association table. When an AP gets a new 802.11 wireless frame, before forwarding it, it checks that the source address is on the association table and therefore belongs to an existent client. If it is not, the AP takes actions using management frames to notify the client about it, and potentially ensures the client is not allowed any access. What if the source address of the 802.11 frame is the broadcast address (ff:ff:...:ff)? The source address can never be the broadcast address, but if the AP has not been implemented with the proper sanity checks, it may try to ensure that "this client" is not allowed to connect to the network. As a result, it disassociates "this client", that is, all clients (broadcast address). A single frame can trigger autoimmunity disorder and cause the AP to turn hostile against its own clients.

Since these are new malicious frames, not available in the current WIDS signature databases (time to update them!), plus it is the AP the final device originating the DoS over the legitimate clients, and because the attacker needs a lower injection rate to keep the DoS going on (vs. the standard deauthentication or disassociation DoS floods), it might be slightly more difficult to detect these attacks.

The second part of the presentation demonstrates a similar scenario against 802.11w-aware AP's. 802.11w (or MFP, Management Frame Protection) is an upcoming specification that promises to protect (through authentication, encryption and integrity) non-data 802.11 frames. Unfortunately, some time ago we discovered that only a few management frames will be protected by it, leaving other management frames and control frames unprotected, still exposing WiFi networks to DoS attacks. Additionally, autoimmunity disorder opens a new door through which DoS attacks can still be launched due to 802.11w-aware AP's with implementation flaws.

A very brief preview of the presentation can be found here.

Although some people still think deploying a wireless network using WPA or WPA2 is enough to protect the network, you can easily learn this is not the case. Check the latest papers on my wireless security Web page, or the recently updated SANS "Wireless Ethical Hacking, Penetration Testing, and Defenses" course I teach in Europe (a whole new set of contents has been added, including lots of new labs, the new FreeRadius-WPE attacks, wireless fuzzing, attacks against other wireless technologies, new sections covering Bluetooth, and a full update to the complementary SWAT kit). We need to deal with lots of recent wireless threats, complex and advanced rogue devices, 802.11n intrusion detection constraints and new attacks, extended wireless client attacks, new EAP implementation flaws, as well as multiple DoS scenarios, and protect other common wireless technologies, like Bluetooth. In the case of autoimmunity disorder, we definitely need a better secure software development cycle for all 802.11 products, including AP's and client software, such as wireless card drivers.

As complementary information (for those reading till the end of my long posts ;), there is a new free online wireless tool to simulate 802.11n coverage, called 802.11n WLAN Coverage Estimator.

P.S: Thanks to Della Lowe and Pravin Bhagwat, CTO, for bringing up this issue to my attention and for the first hand Defcon preview.


WebDAV with SSL on VISTA

A while ago I posted an article about WebDAV and SSL on Windows and in the comments some debate was raised about whether Vista supported SSL for WebDAV or not. I hope this article clarifies the question.

In short, Windows Vista DOES support SSL for WebDAV, at least with SP1 and fully patched through Windows Update as of July 26, 2008.

This is the setup I have tested.

IIS 6.0 running on Windows Server 2003 R2 Ent. Edition. Service Pack 1. English version. Serving on port 80 (HTTP) and on port 443 (HTTPS). Server certificate signed by a Windows enterprise root CA ("Example Root CA"). Sharing through WebDAV the following folder: http(s):// Anonymous access allowed.

Windows Vista Ultimate Service Pack 1. English version. Certificate of the root CA ("Example Root CA") imported on the local computer Trusted Root Certification Authorities certificate store (this is important, see note below about a "Select Certificate" dialog box).

Command used to map the webdav folder:

net use *

Output from that command: (blank lines removed)

C:\Users\admin>net use *
Drive Z: is now connected to
The command completed successfully.
C:\Users\admin>net use
New connections will be remembered.
Status Local Remote Network
Z: file:// Web Client Network
The command completed successfully.
C:\Users\admin>type z:\hello1.txt
This is file hello1.txt

The network traces showed all traffic going through SSL, as expected.

If, however, the certificate presented by the web server is not signed by a CA trusted by the client, you are presented with a "Select Certificate" dialog box with an empty list of certificates, with only the option "Cancel" available:

As soon as you click Cancel the command fails with the following error message, which, granted, doesn't give much of a clue as to what the real problem is:

C:\Users\admin>net use *
System error 1223 has occurred.
The operation was canceled by the user.

I hope this helps.