[Dailydave] All Ur WiFi(WPA) R Belong 2 PacSec

[neal wise]

On 12/11/2008, at 5:07 AM, wishi wrote:

> I think this a perfect example for two technologies, which aren't
> vulnerable for themselves: on the one hand this attack only works on  
> QoS
> enabled Access Points, one the other hand these Access Points have to
> use TKIP, too.

In playing with tkiptun-ng I found I had to enable 802.11e/WMM (off by  
default) on an out-of-the-box Linksys WRT54G. Sure you'd have it if  
you were doing QoS-based ranking. I can't think of any enterprise APs  
that have QoS on by default.

The tkiptun-ng tool released to implement the attack attempts to  
determine RFC1918 addresses in use by wireless network. So,  
interestingly, it seems that wireless networks numbered with public,  
assigned TCP/IP addresses rather than private ones would make  
determining unknown plaintext bytes harder. This applies to a couple  
of my lucky clients who have large, historical registered address  
ranges in use for their internal networks.

So you'd need to know non-RFC1918 TCP/IP addresses in use to, um, know  
the TCP/IP addresses in use. Phone call to helpdesk+social  
engineering, mail headers, etc. :-) and then add that network to  
tkiptun-ng src to narrow it down.

And for the attack you need to support a group rekeying time long  
enough to recover the unknown plaintext that ALSO doesn't change on  
events. Like how Cisco Aironet APs can rotate group keys based on  
member capability changes and when group members leave the group (roam  
to another AP or, well, leave)

If enabled (not a default) this group key change would seem to require  
restarting the "walk through" part of the attack (the part based on  
recovering the unknown parts of the plaintext from the encrypted ARP  
request/replies it identifies). So as long as your victim network has  
long enough group key time *and* never, ever changes on events while  
you're looking...

> Nevertheless of WPA I oder II, as long as no AES-CCMP is
> used.
> Thing is: TKIP without QoS won't allow any successful attacks, either.
> But today there's a need for VoIP and other technologies which need a
> good latency. Which lead me to another tought:
>
> UCsniff has been released this week. It's a very advanced VoIP  
> sniffer.
> (http://ucsniff.sourceforge.net/)

Yeah you'd certainly be more likely to have QoS in a multi-SSID AP  
supporting data/voice. And you do see networks around that mention  
voice/phone in the SSID name harhar

That makes me think about lining up the required issues - WPA/TKIP on,  
WMM/802.11e on for EDCA, long-ish group rekeying time (3600 *is* a  
common default), private network addresses in use (common certainly) -  
I can think of a whole generation of VoIP-over-wireless devices  
released starting around 2005 that supported WEP out of the box but  
were firmware upgradeable to WPA/TKIP (no WPA/AES or WPA2/AES).  
Spectralink E340's spring to mind - these were OEM'd quite a bit by  
bigger telephony vendors.

regards,

Neal
___________
Neal Wise CISSP CISA - assurance.com.au!neal.wise
PGP: 1DAA 1F81 EE57 F975 BA41  5BBA 7C38 F9F0 522D F20E