From: ben at iagu.net (Ben Nagy)
Subject: Wireless Security

I sent this recently on the fw-wizards list. You might find it useful.
There's a whole thread there if you want to dig up the archives somewhere.
Note that the LEAP flaw was originally published here on FD, AFAIK, so you
can dig it up in these archives too.

The bottom line is: "Best" solution is to do all the fancy wireless stuff,
but imagine your WLAN is the Internet and make users VPN in from it.

Cheers,

ben

----snip---
We touched on this briefly a little while ago, when we were talking about
802.1x, so you might want to go and read the recent archives.

If you like, skip to the end for the summary. :)

Here's my (notoriously inexpert) opinion on the crypto problems with Cisco
LEAP and some of the derivatives.

LEAP is "broken". That's easy for people to say, and to an extent it's true.
However, some people may overestimate the extent of its broken-ness. The
basic problem is that there's a really, really _stupid_ crypto mistake which
I can't believe they missed.

The LEAP Flaw:

The SekRiT PaSsWorD is shoved through MD4, which produces a 16 byte hash.
This hash is then padded with 5 nulls (whups!) to produce 21 bytes. The
result is split into three chunks of 7. That happens to be the same as a 56
bit DES key. These three keys are each used to encrypt one single challenge
in sort of ECB (no chaining, anyway), concatenate the outputs and send it as
the response. In other words, the response is E(chunk1){challenge} +
E(chunk2){challenge} + E(chunk3){challenge}. This is a dumb idea. I'm sure
they had some reason for it which I don't understand, but on the face of it
they could have used CBC with a 5 byte IV, used a salt, or one of various
other methods. Anyway.

As you can see, the last DES key is very easy to guess (5 known nulls, thus
2 bytes of entropy ~= 2^16), which gives you Chunk 3 - the last two bytes of
the password hash. Given that there is no salt, you can now just scream
through an existing password database, matching on the last two bytes of the
hash.

So, how bad is it? Well, if you use strong passwords, it's not very bad at
all. If I tell you that the last two bytes of my password are "<!" then it's
not going to buy you much. However, if you use dictionary words or simple
derivatives then it's pretty bad.

Other Problems

There are still some other EAP problems, mostly to do with cunning MitM
attacks, even on EAP-TTLS, PEAP and the like, depending on the tunneled
protocol you use for authentication. There is an IETF draft[1], which may
have expired by the time you read this. It's a little more complicated, but
my basic summary is - authenticate BOTH ends, if you can, and don't use a
tunneled protocol which is itself vulnerable to MitM (CHAP is bad, for
example), or you are probably in trouble.

Please remember that the authentication is only one part of the security -
there is still some link encryption, and to my quick skim Cisco's
pre-standard "TKIP" fixes the most egregious of the WEP problems.

Overall

So, you ask if it's "good enough". Hrm. Myself, I would implement all the
bells and whistles, but still do it your way (create an untrusted,
firewalled segment and let them VPN in from it - you can do this
transparently using Windows IPSec if you are native AD etc). Overall,
however, I believe that if you use all of the available wireless features
(MAC filter, SSID, WEP and TKIP (nonstandard) and 802.1x with LEAP or PEAP
(better) ) then it will almost certainly not be the weakest link in your
chain. The risk profile is something you need to work out yourself, of
course, based on how valuable the data flowing over this wireless network
is.

In one sentence: There are still some crypto problems with the current
wireless protocols, but if you are happy with users running IE and receiving
email attachments then you shouldn't lose sleep over a best-practice
wireless solution.

ben

[1] http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt
----end--- 

> -----Original Message-----
> From: full-disclosure-admin@...ts.netsys.com 
> [mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of 
> Patrick Doyle
> Sent: Friday, November 28, 2003 3:41 PM
> To: full-disclosure@...ts.netsys.com
> Subject: [Full-Disclosure] Wireless Security
> 
> Hope this question isn't off topic, 
> 
> I am currently looking at securing wireless networks using 
> Cisco hardware and wanted to check what peoples thoughts are 
> on security.
> 
> I have read about using LEAP and also IPSEC, my concerns 
> about using LEAP would be that although the client and access 
> point send hashes of the username and password, and also 
> dynamically create WEP keys, the process is still vulnerable 
> to brute force attacks.  Now i know you can lock down the 
> Access Point (AP) to specific MAC addresses, however, in our 
> environment i can see wireless being used for meeting rooms 
> etc, so the users would be random which would mean the 
> constant addition / removal of MACs to the AP which would 
> probably not be possible or practical all of the time.   
> Although policy could dictate that when a wireless card is 
> given out, the MAC address in added to the AP, however if you 
> have multiple APs in different areas of building, being 
> administered by different IT depts then this could soon 
> become be a problem.
> 
> To me IPSEC looks like be the better solution using SecurID 
> tokens (one time passwords) to authenticate users, any 
> thoughts would be appreciated.
> 
> 
> 
>  
> 
> BBCi at http://www.bbc.co.uk/
> 
> This e-mail (and any attachments) is confidential and may 
> contain personal views which are not the views of the BBC 
> unless specifically stated.
> If you have received it in error, please delete it from your 
> system. Do not use, copy or disclose the information in any 
> way nor act in reliance on it and notify the sender 
> immediately. Please note that the BBC monitors e-mails sent 
> or received.
> Further communication will signify your consent to this.
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists