Dailydave mailing list archives
Re: All Ur WiFi(WPA) R Belong 2 PacSec
From: neal wise <neal.wise+dailydave () assurance com au>
Date: Wed, 12 Nov 2008 14:14:29 +1100
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 _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- All Ur WiFi(WPA) R Belong 2 PacSec Dragos Ruiu (Nov 07)
- Re: All Ur WiFi(WPA) R Belong 2 PacSec Dave Aitel (Nov 07)
- Re: All Ur WiFi(WPA) R Belong 2 PacSec Stephen John Smoogen (Nov 07)
- Re: All Ur WiFi(WPA) R Belong 2 PacSec Raul Siles (Nov 09)
- Re: All Ur WiFi(WPA) R Belong 2 PacSec Cedric Blancher (Nov 09)
- Re: All Ur WiFi(WPA) R Belong 2 PacSec wishi (Nov 11)
- Re: All Ur WiFi(WPA) R Belong 2 PacSec neal wise (Nov 11)
- Re: All Ur WiFi(WPA) R Belong 2 PacSec Stephen John Smoogen (Nov 07)
- Re: All Ur WiFi(WPA) R Belong 2 PacSec Dave Aitel (Nov 07)