Slashdot Mirror
NASA Overcomes 802.11b Wireless Security Flaws
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 ..."
Hmmm. Not so much a bug fix as a work around
Email: slashdot3@FreeMars.org (Address will be abandoned when it gets spam.)
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.
The only good weather is bad weather.
It's really no different then plugging into a hostile, unswitched network. Trust no one! Sure, it's easier to "plug" into a wireless network, but you should never trust any traffic medium. Encryption all the way!
This is the same thing that any major, secure install has been doing from day 1.
However, it is good to see widespead use of these techniques. Maybe it'll help those less secure installs:)
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
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.
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)
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.
WEP should be viewed as a means of thwarting casual snooping, just as having separate 10BaseT cables for each computer hampers casual snooping. But unencrypted network traffic is ALWAYS vulnerable to snooping, so claiming 802.11b is fatally insecure is foolish. Unencrypted traffic should always be viewed as insecure.
I'm working on something similar using Linux and IP Tables. One benefit (apparently -- I haven't played with IP Filter yet) of using IP Tables is that packets can be matched by IP address and MAC address at the same time.
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).
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 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.
# Hack the planet, it's important.
not the real goatse.cx but bad enough
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
Many people, me included, will put the access points outside the firewall and have the clients VPN back in to the network. This way you can disable WAP and just use the 3DES encryption of the VPN.
eh i love what happens to replies to messages that get mod'd into oblivion
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
this "solution" is wide open to man-in-the-middle attacks. Tomorrow, I'll drive up there and setup my own DHCP server on their intentionally-WEP-disabled network. I'll hand out MY server's IP as the DNS server, and tell them to HTTP/HTTPS to MY server. I'll collect their usernames/passwords, send them a "site down for maintenance, try again later" message, and cruise through the real front door myself. Sheesh.
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.
The only good weather is bad weather.
Please correct me if I am wrong, but is not MAC based security easily circumvented by simply changing the MAC address on your card? It is very easy to do with Linux and/or some vendor supplied setup programs.
They just build a network assuming people could sniff it.
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.
not quite sure how you are going to get your certificate validated to a nasa.gov domain via any certificate authorities - but yes... it is wide open to a man-in-the-middle attack.
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.
http://windows.scares.us
You're kidding right? "registered only MAC addresses" security is a joke. It's such a management nightmare when you're talking about a significant number of users on a wireless network, think quite a few hundred to thousands of docs and nurses on a hospital network, that it's practically unmanageable. The only real solution is to use VPN technology. And what does VLAN software have to do with security? When you say that MAC address lists and VLAN software (whatever that's supposed to give you) makes an RF network as secure as most people *really* need to be you obviously are only thinking about breaking in and not just covert observation and data gathering. Think about HIIPA. If someone is able to gather packets on an RF network (which is relatively easy to do) then restricting which MAC addresses can get INTO the network is next to useless. The concern is people seeing confidential medical information going across the RF network, and limiting MACs does nothing to secure that information. I don't know how VLANs would help in this either. Sounds like you just through that word in there without knowing what you're talking about. And no, I don't think the 802.11b protocol can be "fixed" from a security perspective without making it an essentially new protocol that will not be compatible with all the existing equipment. Sure, it could be "backwards compatible" but then only new equipment would benefit from the enhanced security.
And here I was expecting to see some government or corporate agency come up with the OTHER security solution...
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.)
The living have better things to do than to continue hating the dead.
I've been doing that for some time now. I simply consider the 802.11b net to be accessable to the public, and therefore it's firewalled. The problem is that people can still see what I'm doing (with the exception of SSH and HTTPS) or spoof the IP address of my laptop and get Internet access. But here's how I plan to actually solve the problem once and for all:
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.
No.. you don't need a mac address to sniff traffic.
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.
The only good weather is bad weather.
I'd go so far as to say it didn't take a rocket scientist to figure that out.
Hoho!
As the developer of this system, I would like to add a few points that the news articles didn't make clear, or mis-stated. The reason why we have a wireless network is for conferences and visiting scientists. From the start, it was considered an external network to prevent access to sensitive data. Thus, we have to support any person walking in with any type of equipment (Macs, Windows, Linux, BSD, etc) without having them use any specialized software. This is all focused on how convenient it is for the person who walks in at 8 AM and has a presentation to do in 15 min. As long as they can figure out how to use DHCP and open up a web browser, nothing more needs done. So yes, we can do IPSec, VPN, and so on, but we also don't care as it's external to begin with. We simply do not want to become a "free ISP" like so many other companies are with their wireless.
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)
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.
This solution, far from creative or unique, offers nothing in terms of aiding in the creation of secure PUBLIC networks.
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.
LedgerSMB: Open source Accounting/ERP
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.
cat