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!
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.
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.
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.
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.
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)