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
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
Nevertheless of WPA I oder II, as long as no AES-CCMP is
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
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.
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