Slashdot Mirror
'Evil Twin' Threat to Wireless Security
BarryNorton writes "The BBC are currently reporting on research from Cranfield University on the ability of unscrupulous third parties to spoof wireless networking clients into believing they are connected to a 'valid base station' and compromising their passwords for Internet banking etc. Of course the rest of the connection through the Internet, even from a trusted router, is insecure in any case and such sites should be using end-to-end security like SSL. Is there, therefore, anything (other than the cute name 'evil twin') to this story?"
Is there, therefore, anything (other than the cute name 'evil twin') to this story?
Yes. If they control the gateway they now have the capability to perform a man-in-the-middle attack.
So, in other words, be careful when you connect to an unfamiliar access point? Shouldn't people already be doing this? This is about the same parallel as "Don't take candy from strangers."
http://sourceforge.net/projects/airjack/
Alls you need
Everyone that disagrees with me is a paid shill
That was my first thought. To properly spoof all the sites so a user is fooled.
:-)
But I suppose key sites you want to capture are all that are required and the rest can be passed through.
So who wants to get one of these going
You can never trust what you're connecting to... It's the age old problem, you're asking for anything you get without performing proper encryption between both links.
Seriously, the only time this problem is going to be fixed is when it's EASY to perform encryption. Where's the easy support for GPG in email clients? SSL in web browsers was certainly a step in the right direction, but what about IM services, email, ftp? Most hosting companies (afaik) don't provide for secure ftp...
I think that Email Interception is the real hole here, rather than depending on unsecure websites. If you can see at which sites a person does secure transactions, you can use the 'email password' functionality to send that user an unencrypted email containing the password or reset link. That email would be easily read by a packet sniffer. Of course the victim would have to have their email client get the email, but email is the first thing that most people check. Sure the victim would get the password reset email, but most would believe that it is just a glitch.
The force that blew the Big Bang continues to accelerate.
TFA has no info on how this is being done. Are the "Cybercriminals" using a regular computer with a wireless card and wired network bridged- forwarding packets and saving a copy for themselves, or are they using a WRT54G with rewritten firmware (OpenWRT?) and to capture packets? Why go through all the trouble when you can park your butt down in the coffee shop with your laptop and latte and sniff everyone directly.
Also it would seem to me that the "evil twin" method would only work with unsecured access points, unless you know the WEP key for the secured access point you are trying to dupe. Anyone trying to connect to their favorite secured AP with their default WEP key would fail to connect to an "evil twin" unless it had the matching WEP key...
Urge to post... fading... fading... RISING!... fading... fading... gone.
and I'll say it again, the average person (not average slashdot person) wants things fast and easy. So anything requiring the least effort is the best route for them. And for some people, that is doing banking on a wireless connection without proper encryption. Of course, this is just one of the many problems that exist with doing online banking without taking precautions or cleaning your cookies afterwards. As long as these settings are not done by default for such interactions, there will always be some people to steal from. Quite easily too might I add.
The security lapse isn't with bad software, it's with bad policy and hapless users. If you connect to a fraudlent base station, then you can intercept banking passwords even on with connections that use end-to-end encryption. Why, and why isn't this protected. Simple. If you connect to a website, even the most-secure site in the world using SSL. If there is something wrong with the SSL certificate you will be presented with a dialog asking you if you want to accept the certificate. 99% of people blindly click yes, because clicking no means that it "wont work" and clicking yes means it "will work". So to the average user there is no downside to clicking yes and a large downside to clicking no. Enough with the psychology though. Once you have clicked yes on this dialog the entire chain of communication is now suspect. You cannot be sure that there is not someone sniffing your connection. Even if you check the certificate and everything looks OK (Sane information in text fields) you still can't be sure that it's valid unless you compare the signature of the SSL certificate with a known-good one. So, the real danger here lies in unsigned SSL certificates and hapless users. This type of attack is just as easy to orchestrate (if not easier) by associating with any wireless access point and spoofing dns or even on a wired network.
This is exactly the reason why VPN was created, for situtations like this. Just create a secure tunnel across the internet, and they can't sniff your data.
The interviewee seemed to be doing his best to simplify the concepts involved, but it sounded as if he were focused on the problem of the initial authentication. For example, the User goes to a public place like a cafe that has a pay-as-you-go model, e.g. he pays a certain amount per minute; such places often require a credit card to initiate the session. (Some business centers in hotels work this way for Internet access.)
If the user sits down at WiFi-R-Us to check his mail, he will have to enter a credit card number. However, there might be a 'rogue' WAP in the area configured to look legitimate, e.g. Wi-Fi-Are-Us, complete with ripped HTML, etc. to make the authentication page look legitimate. (See 'Phishing 101'). The user then enters his information on what he thinks is the proper authentication server.
It's an interesting issue, and I was glad to see it getting some broad[er] exposure.
I want to drag this out as long as possible. Bring me my protractor.
The technique used in the article talks about jamming the legitimate AP to hijack the client connections. The real trick would be to figure out a way to forward the hijacked connections back to the real AP.
Army of One!
It is not unreasonable to base trust on a brand name. That is indeed the purpose of the brand: otherwise we would have to sort through bins of goods and analyze them carefully with each and every purchase. Which we do sometimes (with fruit), but not with everything. We just don't have time for that and in purchases over the internet, it is impossible. Collective opinion (including websites) is often the basis for this trust. The only thing you can ask of people is that they ask around sufficiently before forming trust.
Your issue, I think, is actually that people think something is a brand because it has the logo on it. That is, they are too trusting of the logo itself not being counterfeit. I don't know what we should do about that. SSL can tell us that a website is who it says it is, but it can't verify the correctness of a logo or claimed corporate identity.
I watched the piece on BBC TV news this morning.
:-(
Guy sits down, opens his laptop, starts a Microsoft OS, opens IE and calls up his bank's homepage.
Other guy comes in, sits down, opens his laptop. He's running Linux!
Really, Linux on a BBC news piece, wow!
But then he starts evin twinning the Microsoft guy's wifi link. He's the Linux bad guy.
Nice one BBC.
Well of course you're dead on about slashdot readers. But what about the kid who makes one extra click to surf the new, secure https://disney.com in the morning, whose dad surfs his bank that evening? Hell, with 80% of the wireless routers in residences running default SSID's and no WEP or WAP, one could even launch this attack on a stationary target, where the likelihood of eventual compromise over a period of hours or days would approach certainty. Good luck associating that cause and effect!
About the word "if": If bullfrogs had wings, they wouldn't bounce around on their little green butts.
I prefer the term "Imposter Gateway." (Cough)
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
You can't "fool" a certificate. The entire system is designed to check that the site claiming to be "www.bankofslashdot.org" really is "www.bankofslashdot.org". This is done not by checking IP addresses, but by ensuring that the site you're connecting to (a) has a signed certificate and (b) knows the private key part of that certificate.
If an attacker merely redirects browsers to a different web site, they'd still need the private part of that certificate, which is something they will not have. Why is that important? Because without the private part of the certificate, the spoof site cannot sign anything which means the browser will realise the site is fake immediately.
If an attacker tries to create a bogus certificate, for which they have the private part, they'll have problems getting it signed by any of the authorities whose keys are stored in every modern browser. (Want a list? Get Firefox [I don't have IE here so can't give the instructions for IE], check Preferences, Advanced, Certificates, Manage Certificates, Authorities.)
Unless the certificate is signed by an authority known to the browser, the browser will issue a warning, and while the average user might click through for unsigned certificates for "pr0n.net" or "fredsdiscountshop.com", they're sure as damn it not going to for their online banking. Indeed, in the latter case, the browser itself may actively prevent them from connecting if they've been to the site before and it had a legitimate, signed, certificate at that point.
There's no fooling the certificate. The certificate DOES NOT USE DNS. It associates a hostname with the certificate, but the entire point is to make sure that the machine that ultimately is connected to is the real thing, and the real thing could have any IP address.
You're saying, essentially, that the certificate system would be fooled by the very thing it was designed to prevent. It isn't. One of the primary reasons of designing it this way was to prevent this kind of attack. Otherwise, why store all the certs in a browser? It'd involve a hell of a lot less administration if we could just download the certificates automatically as we need them.
You are not alone. This is not normal. None of this is normal.
"If you think the problem is bad now, just wait until we've solved it." --- Arthur Kasspe
There's a small SF Bay Area startup that makes specialized wireless access points. You setup a network of the access points. The access points know about all other access points that *should* be there. When it detects another access point that is acting like an "evil twin," the network of access points can not only locate the evil AP to within few meters, but also DOS it with bunch of bad packets to knock it off the network. The CS department in Berkeley uses it. It can also be configured to knock out any non-evil AP if you want to restrict wireless APs in your organization. I don't know the name of the startup as the presentation by CS IT department chose not to disclose the company.