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 ..."
Depend on protocols that will be easily hacked as soon as someone sets to it?
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:)
This seems pretty straightforward to me.
What, me worry?
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;
Actually I'm in the process of setting up wireless gateways using a linux kernel, busybox, iptables, dhcpd and freeswan.
:)).
:(
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
This is usually where I spout about OpenBSD, (hehe guess this is a setback for you BSD-Dying trolls...) but I wonder why/who choose OpenBSD? I've recently 'played' with the grsecurity patches for 2.4.9 and I like them. A lot of them give OpenBSD-ish features to linux, but some extend what OpenBSD currently provides. The only reason I bring this up, is that >2.9 (aka -current and future releases) does not have ipf. The pf project (OpenBSD's own packet filter) replaces ipf. But, 3.0 comes out in Decemeber....Wonder how it will all turn out....
Chaos, Mayhem, and Destruction: Not
I would suggest the following experiment to help you gain some perspective:
- Turn off your computer and go outside. Observe your surroundings and note that Slashdot has no influence on any of them.
- Go downtown and watch the crowds for several minutes. Realize that you probably have not seen a single person who knows anything about Slashdot or will ever be influenced by Slashdot.
- Ask yourself whether Slashdot can injure your ability to eat, sleep, or move around without your consent. Then ponder whether Slashdot can hinder your free expression in any other forum but Slashdot itself.
Sure, Slashdot's recent attempts to solve the fundamental paradoxes (freedom vs. quality) of public, online discussion are flawed and causing the site to commit suicide slowly. (For example, I discovered that I cannot title this message "Perspective, perspective, perspective." because it is too repetetive. Silly.) However, do not compare yourself to revolutionaries who struggled to change real, meaningful things. This is an electronic playground and nothing more. Only five-year-olds lead revolutions on playgrounds.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.
I am with a company which is rolling out wireless Internet access via 802.11b and was considering doing something like this. 802.11b sucks for security, but there are definately many protocols for ip that you can tunnel though.
How is this news?
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.
http://windows.scares.us
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.
It would seem to me that people are taking this whole wireless security thing all wrong. Think about it in a wired situation, when you are connected to a hub: anyone can see any packet by using a the right tool. To proovide security in this environment, we encrypt the individual services we feel may contain sensitive data. We don't go around all day worrying about how to encrypt every packet our computers send. It would only make sense that we think of wireless in the same way. If you are worried about password security, use kerberos, if you are worried about shell security use SSH, sensitive data on the web is in most cases already protected by SSL. So in the grand scheme of things, who really cares about WEP?
Who would of thought that was a news worthy item. I mean, a web based login interface, which firewalls you out if you dont have a working login and password. Completely innovative! In a wireless sense, this is called a Captive (or Active, I myself am not clear on the differences) portal. I cant believe they made a press release out of that, and that it took them 40 hours to make!!
Jeff Knox
Damnit, Jim, I'm an anarchist, not a F@#$!^& doctor!
Beacuse it is possible to change your MAC address there is really no securuty in it, a bit like an IP address. It is also possible to sniff MAC addresses, even off encrypted traffic, so it would be easy to get a valid address.
I have not trusted wep for a long time ... I reciently reconfigured my home router/firewall so that the wireless bridge is on it's own interface.
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.
Are you paranoid if you know that they just want to know everything you say and do?
MAC's can easilly be spoofed, and to sniff the network you can do it passively, so the MAC check isn't even going to come into play
Uh, if anyone ever reads some of the wireless message boards (BAWUG, Seattle Wireless, PDXWireless) you'd see that we already knew this. Thanks NASA, but we got it first. I hope they don't patenent it. Sheesh.
No, no, no. Hemos need not apply.
Why, exactly, are so many people bitter, and therefore minimizing what NASA has done with their wireless network? Can't we just say, "Good for you, NASA" instead of the aimless negativity?
Oh well, just my opinion.
Sam
If both users try to use the same MAC address
at the same time, each will get NOTHING!
Lameness filter encountered. Post aborted!
Reason: Ascii art. How creative. Not here though.
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.
Here's a technical description on how they did it: http://www.nas.nasa.gov/Groups/Networks/Projects/W ireless/index.html
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.
we're bitter because they've dashed our hopes a few times already with their recent screw-ups involving Mars (read: metric conversion) and other space-related things. The /. crowd is full of people who dream of space, and don't like the fact that because of nasa's shitty funding, politicizing, etc. we'll never get to go into space. We all like to imagine a space where our dreams of the future come true, but with NASA being the best space agency available, and their constant bad-press, we may never realize those dreams. We can't help but wonder what it'd be like if NASA hadnt screwed up. Would they have more funding? Would the dream that was space come true? Would we be able to use our meager income to experience the glee that must come with complete weightlessness???? I tell you, this is why people are bitter. We dont' want 802.11b security. We want to float around. Sheesh.
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.
Ok, reading what everyone says the only Secure method to use 802.11b is
:)
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.
No.. you don't need a mac address to sniff traffic.
Secrurity? I can tell that the Slashdot editors really take their job seriouslsy.
They run it on OpenBSD ? Why not microsawpht ? OpenBSD is open source and we all know opensource sux. M$ is more reliable, faster, secure,
and they dare to avoid M$ ! What da heck they think they are ??? Are all those comercials on TV and papers for nothing ? Hey guys, don't be so pathetic, get a life !
The whole idea of trusting the wire is a pretty bad one.
http://seattlewireless.net/
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)
Security is a continuing process. You have to work not only on the technical level, but also with people. That being said, I'd like to discuss a bit of security.
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.
Stop the brainwash
If you're looking to set up a public access network you might be interested in something like NoCatAuth.
http://nocat.net
Isn't it just common sense to use proven-security application-level encryption always! It's nice that link-level encryption is there but who will rely on only that... only fools.
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.
You cannot trust any net, there are also "sniffers" for swithed networks :)
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
I installed 802.11 at my house about a year ago and had been planning to enable encryption for some time. But, I live in a small suburb in Tokyo and there's nothing really important on my home networks so defending against the risk of someone cruising past my house with a laptop wasn't a real high priority.
A few weeks ago I found some logins coming from weird IP addresses on our webserver (outsourced, located in the US). After a bit of the usual tracking down, I finally figured out what had happened - my neighbors had installed a wireless network also! 802.11 is being pushed pretty hard here in Japan and several companies are shipping combo 802.11/ISDN Router boxes that are just plug and play (amazingly, ISDN is actually easy to configure here in Japan. Still dog slow but NTT does love it).
Anyhow, I enabled the basic WEP stuff mainly just to keep our networks separate. Now, for the high security stuff, there's an easy solution. I find anyone hanging around outside my house with a laptop they will be introduced to my baseball bat.
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
All of you who are spouting out "let's tunnel everything through ssl/ssh" obviously don't know too much about the real invulnerabilities out there. I hate to break it to all of you OpenBSD/ssh zealots out there, but ssh isn't secure. Anyone who has ever toyed with dsniff (www.monkey.org/~dugsong/dsniff) will easily tell you that it is possible (via man in the middle attacks) to monitor/kill/hijack ssh connections. It takes about 1 minute on FreeBSD to arp-spoof the network's gateway and seamlessly m onitor every packet going through it.
SSH isn't the solution.
derek/heyitsme
What you said is exactly correct. By using a radius server you can do a sort of transparent authentication, but that only stops people coming from the wireless to the wired network. The WLAN is still unprotected. The only way to truly secure a wireless lan is to treat it as unsecure and use a VPN.
All these articles in the last few weeks sound like people actually did use WEP as the only means of security. They can't be that stupid, can they?
Yes, you can join, but NOT thru the same AP.
Try it, I did...