nosey employee attack

[sec_ware]

Hi


When it comes to Wireless Security, I am quite a beginner.
Often, wireless security deals with hindering illegitimate
users to obtain "the key".
Fine, yet I have another problem ("nosey employee attack"[1]):


question

Given 1 Access Point, 2 legitimate users (A and B) with
2 laptops (MAC addresses known). For both users the setup
is the same (e.g. same key/passphrase ie. "the key" is known).
If you wish there is also a RADIUS server available.


Question: Is it possible to setup a configuration such that user B cannot read/decrypt A's traffic?


(like this is the case in a switched wired network neglecting
ARP poisoning, TEMPEST and co. Note that I also do not want
to use additional mechanisms (like VPN).).


considerations

As far as I understand:

• open: B always can read A's traffic (trivial)
• WEP: B always can decrypt A's traffic (same key for RC4)
• WPA-PSK (TKIP, with RC4): B also is able to decrypt A's traffic (same PSK, MAC known, ANonce/SNonce known -> PTK predictable[2])
• WPA2-PSK (CCMP, with AES): seems to invoke the same problem as with TKIP/RC4.

More interesting (and maybe the solution to the problem):

• WPA/2-TLS/PEAP: The PSK is replaced with a client-certificate/user credentials

Question: Assume I am in an environment with WPA/2-PEAP. I am
connecting to the network wirelessly using 2 laptops using the
same credentials. Can I decrypt the traffic flowing from the
first laptop if sniffed on the second laptop?


LEPS

I read about the LEPS-Feature[3] of lancom, which allows
to relate a MAC-address to an individual passphrase - so there
indeed seems to be a problem?



I hope this is not too confusing... Any help appreciated! Thanks.


Cheers


[1] http://www.awprofessional.com/articl...&seqNum=6&rl=1
[2] http://www.antionline.com/showthread...592#post825592
[3] http://www.mylancom.de/fileadmin/pro...ecurity-EN.pdf, section 9

[bAgZ]

I haven't done wireless in a while but i seem to recall an option on my 3com wireless router where you could separate the traffic as in clients on AP cannot see each other.

[sec_ware]

Hi

I think you are referring to "client isolation". If I understand this feature
correctly, it essentially turns the accesspoint (AP) away from "hub-behaviour":

client isolation off: ("hub-behaviour")
frames arriving at any port of the AP are forwarded to all other ports.

client isolation on:
frames arriving at the AP's wireless interface only are forward to the wired
interface.

Still, the wireless traffic could be sniffed.



Essentially, I am now wondering to what extend the client certificate (TLS)
or the user credentials (PEAP) influence the (temporal) "keys" used in the
TKIP/CCMP-communication between the client and the AP.


Thanks & Cheers

[bAgZ]

As far as i understand you can always sniff traffic since it is wireless. You can have
all of the different auth methods such as eap peap, eap tls, eap md5 which only
help druing auth. I am not an expret on this but i think that when using Extensible
Authentication Protocol encapsulated over Wireless LAN (EAPOWL) traffic, identity is
not sent before the tls tunnels is up.

But you can still sniff using passive or active attacks one solution i guess would be to
encrypt traffic using IPSEC or soemthing like this. But don't belive me maybe you can
check thess looks like a good resource:

http://www.iss.net/wireless/WLAN_FAQ.php#[2.2.1]%20Wireless%20Sniffer
or http://www.windowsecurity.com/articl...ks_Primer.html

[dmorgan]

IIRC, TKIP generates a seperate key for each client based on the master key, the client's MAC and some other random salt. So, it can be sniffed, but must be decrypted. That is if I remember TKIP correctly

/edit oops, just saw this which kind of negates what I was saying

WPA-PSK (TKIP, with RC4): B also is able to decrypt A's traffic (same PSK, MAC known, ANonce/SNonce known -> PTK predictable[2])

[sec_ware]

Hi

Thanks for the input, both of you!

I have found this (old) microsoft-article[1] quite interesting,
since it discusses PEAP with MS-CHAPv2 in quite some detail.
It confirms what you say, bAgZ , that the authentication
only takes place after the TLS tunnel is up:

The entire exchange is encrypted through the TLS channel created in PEAP part 1.

This also may imply that due to the two-step initialisation, the
random "nonces" cannot be captured since they are sent in the TLS tunnel:

The second part is the use of EAP and a different EAP type to authenticate network access.

(well, maybe I want to interpret it in a way I like it )


I tend to bravely conclude that indeed, PEAP with user credentials and
the random "nonces", which are not capturable, provide a mean to build
unique encryption mechanisms, such that user B cannot read/encrypt
user A's traffic even if both users use the same user credentials.
(The possibility to enable EAP-TLS with client-side certificates is
quite rare).


After my visit to prague, an experiment seems to be required to confirm/deny
these conclusions....


Cheers

P.s. bAgZ, of course traffic encryption using IPSec is a great way,
but it requires for the purpose unbearable configurations on client side. Sigh.

dmorgan, actually I confirm what you are saying: the message has to
be decrypted, however, the key for this procedure is predictable. ANonce and SNonce
are random, but can be sniffed since these "nonces" are sent clear-text.

[1] http://www.microsoft.com/technet/com...uy/cg0702.mspx

[The3ntropy]

yea set up a VPN server with encryption, then force both users to connect over the wireless using any VPN client that supports encryption

[sec_ware]

Hi

As mentioned in the beginning, I did not want to go with a VPN, simply
because I thougt that I would have to "manually" install some kind
of VPN-client on client-side - and also to force me to think about those
wireless protocols

Now, I learned something new - the SSL VPN solution by Fortinet.
All you have to do client-side is open your browser (IE), enter your
username/password (AD, LDAP, RADIUS, but also an built-in database is
supported) on a secure site - boom, there you go with FortiWifi:
VPN over Wifi, with no installation client-side..

We tested it with FortiGate - works like charm. Now we have to buy the
FortiWifi.

Thought, I share this experience

Cheers