NASA Overcomes 802.11b Wireless Security Flaws 111
4mn0t1337 writes: "Looks like the people at NASA came up with a "solution" to the weak secrutity in 802.11: Bypass it. From the article: "The team also assumed that all information on the network would be subject to eavesdropping, and that no identification information built into 802.11b could be trusted." So they chose to disable it, and set up an 'off-the-shelf PC running the OpenBSD operating system, an Apache web server, the Internet Software Consortium DHCP server, the IPF firewall software' and just depend on the security in protocols the services use. Moral of the story: Ignore the 802.11 security and just tunnel into our access points ..."
Re:Perspective. (Score:1)
So... (Score:1)
Re:So... (Score:1)
NASA bypasses 902.11b flaws (Score:3, Insightful)
Re:NASA bypasses 902.11b flaws (Score:1)
That's a pretty sad response (Score:5, Insightful)
The solution is to *fix* 802.11b's security, which shouldn't be that hard. I believe that simply running the crypto algorithm through a few start cycles, before transmitting, is sufficient to stop the published attacks.
Whether the fix requires buying new hardware, or flashing old hardware, or just changing drivers, is another question.
How secure is TCP/IP over wire? Not much. (Score:3, Insightful)
Re:How secure is TCP/IP over wire? Not much. (Score:3, Interesting)
We've deployed a wireless application over CDPD. While we can pretty much assume the traffic between modem and CDPD carrier is encrypted and authenticated using the built in capabilities, we can't say the same about the connection from the carrier to our customer's site and their WAN.
As such, we employ an embedded VPN solution at each client and terminating site. Traffic is encrypted from the moment it leaves the mobile unit until it reaches its final destination. Unencrypted trafffic is not visible except on the terminating LAN (if the VPN is running on a machine seperate from the server).
Re:How secure is TCP/IP over wire? Not much. (Score:3, Informative)
I hope you're not relying on the crypto in CDPD. It's RC2.
Re:How secure is TCP/IP over wire? Not much. (Score:2)
Re:That's a pretty sad response (Score:1)
The solution is to *fix* 802.11b's security, which shouldn't be that hard. I believe that simply running the crypto algorithm through a few start cycles, before transmitting, is sufficient to stop the published attacks.
A potential solution for quite a few flaws in WLAN security could be 802.1x. Sorry that I have no links available at the moment, but a quick search with Google or similar tool should be able to give a rough idea about it.
Re:That's a pretty sad response (Score:1)
Facing this kind of problems, our local university decided not to use WEP at all from the beginning, but an IPsec derivate (unfortunately with vendor-specific extensions for the user-based authentication).
Why did it take this long for people to get it? (Score:4, Insightful)
Cool...but... (Score:2, Interesting)
However, it is good to see widespead use of these techniques. Maybe it'll help those less secure installs:)
WARNING: Another goatse.cx moron (Score:2)
Re:WARNING: Another goatse.cx moron (Score:2)
Is this surprising? (Score:1)
Well shit, DUH! (Score:1)
Re: insecure? (Score:5, Informative)
The real details are not too hard to find...30 seconds with a search
engine came up with quite a few references, including:
http://www.cs.umd.edu/~waa/wireless.pdf [umd.edu]
That document contains a fair number of bibliographical references
which you might find interesting.
The principal problem I've found with wireless security is that lots
of people deploy it poorly - effectively allowing anyone nearby to
"plug" into their network. Most of the news articles about hacking
wireless networking are about this kind of insecurity. The implication
is that when you set up a wireless network you need to use WEP to
encrypt the connection.
Some of the more alarming articles suggest that WEP is weak, and so
can't really be relied upon. If this is correct, then it means one
must use encryption at a higher level - which is not a trivial
undertaking. If you can't deploy IPSEC thoughout your network, you'll
have to put your wireless access points outside of your firewall and
use VPNs to get in.
Re: insecure? (Score:2)
Less clear is whether WEP must be insecure. I see no reason that a MAC-level protocol cannot be as secure as any other protocol. And WEP is based on a presumably secure encryption algorithm, which it uses poorly.
MAC-level will not work (Score:1)
Re:MAC-level WILL work - depends how you use it (Score:1)
at the same time, each will get NOTHING!
Re:MAC-level WILL work - depends how you use it (Score:2)
Re:MAC-level WILL work - depends how you use it (Score:2)
Tunneling seems to be the only immediate cure, but I was thinking...(laughs)...why not rewrite 802.11b firmware and drivers to reverse the bytes in a message before transmission, and unreverse upon reception. I know another data movement operation can be expensive, but it _is_ only 11Mbps worst case. Easy for even a 486 to keep up. This would at least thwart the capability of predicting that the first byte of every message is 0xAA. Obscurity, yes, and a bit of relief for the clueless home user. Even with a fix to 802.11b security, do I put the base stations outside the firewall? YES
The funny thing is, now we install more wires just to go wireless.
Re:MAC-level will not work (Score:3, Informative)
Certainly even encrypted systems are susceptible to traffic analysis (putting together an org chart by seeing who talks to who), but that is rarely a threat in the commercial world.
Re: insecure? (Score:2)
I believe the answer is that WEP as implement in 802.11b is insecure. 802.11x (I believe x is correct) will add a new key exchange that is supposed to be secure.
The real problem is that marketing wants 802.11 to be secure *and* easy to setup. Security is not easy. Sure the cryptography part is dead simple. It is all the parts around it that have to be equally secure that make it hard.
Re: insecure? (Score:1)
Re: Bluetooth (Score:5, Informative)
Not really...
802.11b is seeing high adoption rates in corporate networks. For better or worse, impenetrable security is not usually at the top of the list when choosing a network component. (ahem [sourceforge.net])
By starting with a halfway decent basestation that allows for only registered MAC addresses to attach to it, then running some simple Vlan software (with or without WEP) you have an RF network that is as secure as most people *really* need it to be.
As for Bluetooth, it's reaally not here yet, and it's intended for short-range devices that will most likely require lower throughput's than what 802.11b offers. HomeRF is a sort-of direct competitor, but it also has issues of it's own.
With the right tools, and some dedication almost any simple network can be cracked. I remember when most people didn't know what "promiscuous mode drivers" were for, and many corporate LANs on simple 10M hubs were easily cracked by patching into an unsecured jack.
802.11b is gaining a lot of press, and thus attracts more hacker efforts. I can almost guarantee that if HomeRF were the predominant wireless standard, we would be seeing the same hacker tools for it.
Re: Bluetooth (Score:2, Insightful)
Working on something similar (Score:3, Interesting)
I shouldn't say that my piddly firewall can measure up to what the folks at NASA could cook up, though, as I haven't figured out how to get the statefulness of IP Tables/Netfilter to help me out. We're also not using VPN yet (though we're planning to allow VPN clients to connect to a server farther upstream).
Re:Working on something similar (Score:1)
Tunneling is not the answer. (Score:5, Interesting)
This solution, far from creative or unique, offers nothing in terms of aiding in the creation of secure PUBLIC networks.
For example, a college campus can't be expected to teach every student, including the non-geeks how to setup IPsec, port forwarding with SSH, and all other kinds of neat things.
Granted, Dan Kaminsky [doxpara.com] gave a talk at DefCon this year on how to seamlessly tunnel your way through 'hostile' networks it still isn't as simple as just renewing your IP and being online.
One possible solution to secure public nets is similar to the way we validate PGP keys. Face to face signing parties. If I run a public net I'd like to know who is using it. How about you drop by my cafe and just give me your MAC address and I'll add you to the firewall's rulesets. Automatically you now can find out who is in promiscuous mode, who is using all your bandwidth, etc, etc, etc.
There are many other solutions that aren't as much of a hack as IPSec, ssh tunneling, or any of these other high level obfuscators.
Thanks,
David U.
neither is what you suggest (Score:1)
rtfa (Score:2)
RTFA. The infrastructure has very little tunnelling. The login is encripted bia RSA encryption, and the only real tunnelling is done to allow one properly secured station to access the server via SSH.
Forging mac addresses is trivial in most implimentations without going into promiscuous mode.
I think that this is a good solution and shows good though and planning.
Not that new of a solution... (Score:3, Informative)
Re:Not that new of a solution... (Score:1)
Sorry for the product plug (I do work there), but as other have pointed too, NASA hasn't "come up with a solution"; more likely they've read our (or our competitor's) data sheets.
IPSec (Score:1)
The security comes from IPSec. It also works with OpenBSD (tho Open is hard to fit on a single floppy
Still not ready for public release tho
OpenBSD baybee (Score:1)
Major league insecure (Score:3, Insightful)
not perfect, but worth modding up... (Score:2)
The problem as I see it for NASA in particular is that they probably support MANY client OSes. Thus making VPN difficult at best as many have suggested. I would not be suprised to hear that there were 95/98/NT/2000/MacOS 8/MacOS 9/MacOS X/Solaris/Linux clients that would all want to make use of the wireless network. It would be possible to support them all under multiple VPN products - but it wouldn't be cheap nor would it be management friendly.
Re:not perfect, but worth modding up... (Score:1, Interesting)
Don't need to. I'll use http. Their http server redirects you to https. Mine won't. Most users won't notice the difference. I'll put an "under construction" icon on the page and say we're remodeling. All I need is one less-cluefull user to give me his username and password, and it's game over.
And this without even getting into DDOS attacks. A rogue DHCP server is a mindnumbingly painful adversary.
Re:Major league insecure (Score:2)
I'm implementing a hardware based VPN for our WLAN. As others have noted, that makes it hard to support multiple OS, though not impossible. I have Free S/WAN interoperation with the VPN using IKE preshared secrets, so that gives me Linux support. Now what we need is integrated IPSEC support from the WLAN vendors.
Re:Major league insecure (Score:2)
Yes, I know both IP and MAC addresses can be spoofed but do you have any idea how blatently obvious it is when you stick two machines on one network (wireless or not) with the same MAC/IP address?
"Man In The Middle" attacks are wonderful conversation pieces but good luck in finding any reported successes outside a controlled lab environment.
Either way, combine their solution with both client and server certificates and you have a good solution that your "man in the middle" won't touch.
Make people REGISTER to get an account and issue them a client certificate at that point.
Re:Major league insecure (Score:2)
Ha! That's where your fatal flaw will get you nailed in 10 minutes. NASA doesn't take servers down for maintainence at all! That's why they still run SunOS 4.1.
Keep thinking like a logical tech, man, and you'll never break into their level.
I was thinking of similiar schemes.. (Score:1)
Maybe an ogre but not a troll... (Score:1, Troll)
The real "news" here is that NASA would find it appropriate to issue a press release on a project I would expect anyone half rational and competent to be able to figure out and implement in their sleep.
"This just in from NAS NASA - We have succesfully patched IIS against Code Red thus developing the glue to keep our servers up and operational [editorial: for now]. More on this exciting development can be read at slashdot.org"
Please... Spend my tax dollars telling me how close you are at getting me and countless others some time in space. Not on how your (notably horrible in security) NAS team has defeated the WEP weaknesses that everyone and their brother already knew how to get around.
MAC based security? (Score:2, Informative)
Re:MAC based security? (Score:2)
It should not be confused with simply filtering by MAC *addresses*.
They didn't 'overcome' anything.. (Score:2, Flamebait)
The principle should be the same for any network, especially reagarding anything going over the internet. Even a wired network is not 'secure'. Sure, there is the physical security element.... but one compromised host with a sniffer and you are in the same boat.
Encryption is a good thing.
Re:They didn't 'overcome' anything.. (Score:1)
Uhh, Web based login interface is innovative? (Score:1)
Re:Wireless at any speed... (Score:1)
We have the cryptographic techniques to make a wireless protocal unsnoopable. It's just a quesiton of someone actually implementing it.
Been there ... Done that ... (Score:1)
I treat it as a hostile (external) interface. If the connection is from a known IPsec peer, then I consider it a trusted internal connection.
For the non IPsec connections I allow access to a few servces, mostly ssh and other crypted authenticated services.
I have setup a easy way for me to enable forwarding from the wireless network to the outside, so that when a friend comes over with a 802.11b laptop, I open my wireless network to the outside, while the inside is restricted.
Being able to do this is one of the advantabes of running a real system as a firewall/router than one of the "Firewall/routers for dummies" boxes.
Bitter, aren't we? (Score:1)
Oh well, just my opinion.
The OTHER solution... (Score:2)
Have a company distribute sound or music over 802.11, and then have the company use the DMCA to take anyone who cracks the security, and bash them over the head with a big legal mallet.
Either that or the military solution, to outlaw non-governmental, non-corporate encryption to the same end, bash in the head with the legal mallet.
(similarities ('bash' vs '/bin/bash') to a popular shell merely coincidental.)
Description of how they did it (Score:1)
Here's a technical description on how they did it: http://www.nas.nasa.gov/Groups/Networks/Projects/W ireless/index.html [nasa.gov]
It's pretty neat:
You get your networking infos via DHCP. This gives you access restricted to public data.
If you connect to their HTTPS web site and authentificate, this pokes a hole in the firewall and you get access to secured/private servers.
A real solution (Score:2, Interesting)
I'll install Linux (BSD's should work too) on my laptop and tunnel PPP over SSH to my server, thus creating a quick and easy VPN. My server's firewall will then be set to block and log everything except DHCP and SSH that comes over the real 802.11b interface, but allow everything that uses the secured PPP session.
That causes three problems:
1) I'd like to be able to keep Windows on the laptop just for the software compatibility, but I think I can get by with VMware under Linux.
2) It's not very scalable. The best solution I can think of is to make a universal SSH acount that just provides PPP sessions. The client PPP IP address would be selected based on some sort of ID that the client provides, just like DHCP. I suppose I could make the client script pass it's 802.11b adapter's MAC address to the server and then the server would assign it an IP accordingly. But, I still have to give anyone who I want to connect to my network the password for that SSH account and the client side script, and they have to be running a UNIX family OS.
3) I'm still vulnerable to DoS attacks by people in range of my WLAN. A simple broadcast storm would probably be pretty effective. But, I don't think this is a big threat, since my range is pretty limited. I'm also vulnerable to any security holes that may be in DHCP or SSH, but I seriously doubt there are any skilled crackers within range of my WLAN. And, I'll patch any holes myself once they are published on BugTRAQ or something, so script kiddies aren't a threat, if there are any in range.
Re:A real solution (Score:1)
So the only solution. (compiled) (Score:1)
1. Disable WEP
2. Put a firewall between your wireless router and network.
3. Only allow the VPN ports
4. Run a VPN client.
Is this it? Doesnt sound too hard, and I have a 486 that would make a nice firewall. Humm, time to go pick up a wireless router now.
We figured this out about a year ago. (Score:1)
http://seattlewireless.net/ [seattlewireless.net]
That's pretty obvious (Score:2)
Hoho!
The point is high usability / flexibility (Score:3, Informative)
This device is indeed quite "common sense"; it is supposed to be. We searched for a vendor that provided these services (user accounting/authentication, dynamic firewall, etc), but didn't find any, so we simply built it ourselves. It does the job for what we need it to do in our environment.
-Nichole
(NASA Advanced Supercomputing Division)
Not a problem if you implement real security (Score:1)
Security is not implemented on a single level. The idea is that if you fuck up, there is a pretty good chance another level will catch you.
Consider this wireless story. It's really not THAT terrible - if you are using secure protocols. The people that struggle, are those that trusted 802.11b to the point of thinking that was their only level of security.
The fact is, a lot of security incidents stem from employees. They may be disgruntled or just curios. Whatever their motivations may be, it is a bit naive not to watch your back when dealing with coworkers. I'm not talking full-on paranoia, just using ssh rather than telnet on the intranet and measures to that effect. It's quite amazing what you can accomplish with a bit of elbow grease and a healthy mindset.
Not quite that simple. (Score:1)
SSH isn't the solution.
derek/heyitsme
WEP as the only security means? (Score:1)