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?"
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
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.
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.
If you check carefully, you'll find out that your password has been sniffed, your box 0wn3d, and you have actually been connecting to 127.0.0.1 ;)
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.
I don't know the exact technical details but I believe the process goes something like this:
Client: I want to make an HTTPS connection to your server www.bankofslashdot.org. Get the ball rolling by sending me your public key.
Server: Here it is. [String of several hundred binary digits follow]
Client: (Examines key) Ok, it's signed by Verisign, and it applies to www.bankofslashdot.org, the site I'm trying to connect to. Sounds good to me. Can you give me a session key I can use to encrypt information I send you?
Server: Here's the session key you're going to use, signed by my private key, which you can verify using the public key I just gave you
Client: (Encrypted) looks good, here's the session key you can use to send me information.
(In general RSA encryption is used. RSA is dual purpose, it can be used to sign information and to encrypt it. RSA keys have a public element and a private element. The public element can be used to encrypt information and verify signatures, but cannot be used to derive the private key. How does it work? Products of two very big prime numbers, don't ask me more than that 'cos I seriously don't know.)
A "man in the middle" would have a little bit of difficulty, as there's no way they could sign the session key they send to the client because that session key can only be signed if you have access to the private key, which they don't have.
If the key is invalid, or there isn't one signed by an authority to begin with (they're not compulsory), then browsers usually warn users.
The best I can think of is that you try to redirect a user to the wrong site. For example, the "Log in" button on http://www.bankofslashdot.org could redirect to https://www.blankofslashdot.org, though doing so would potentially expose the attacker as you have to prove you're real and you're the owner of the domain to most authorities to get a certificate for your key.
Anyone spotting obvious errors or wanting to fill in gaps in my explanation is most welcome to do so.
You are not alone. This is not normal. None of this is normal.
Keys and certificates have nothing to do with DNS, they're actually there to confirm that you really are connecting to a specific machine, not just a machine with the right IP address.
You are not alone. This is not normal. None of this is normal.
Perhaps you should read WEP: Dead Again, Part 1. It compares various WEP cracking tools to see how fast they can crack WEP keys with varying amounts of packets. While the popular AirSnort usually needs over 10 million encrypted packets to crack a WEP key, aircrack usually needs around 500,000. That's the difference between being able to gather enough packets in a day versus a week or more.
Army of One!
Well, the idea is the following:
The product of two primes has exactly the same information as the two primes themselves (there's exactly one way to factorize a number into primes). However while going from the two primes to the product is trivial (just multiply them), doing the reverse is actually hard.
Now RSA relies on a reversible transformation, where for encryption, you just can use the product directly, but for decryption you need the two primes separately. So if you send someone the product, he can easily encrypt a message with that key, but he cannot decrypt even the message he just encrypted, because to do so he would need to factorize the product, which is hard.
So essentially the public key in principle contains all the information to decrypt (otherwise it could not be used for encryption), but in a form where it is practically useless for decryption (because you just can't get at the necessary information in reasonable time).
The Tao of math: The numbers you can count are not the real numbers.
Open web browser (usually defaults to google or MSN).
418 Connection Refused; Your <link...>router is having an encryption problem. Click <link...>router for more information.
User clicks on link, which installs Certificate Authority (with the requisite warnings). Seems simple to most users. There's an error about Wireless Encryption - and it wants to install a certificate. Since the user wasn't trying to hit a secure site at the time, it doesn't seem as immediately suspicious.
No, the "one percent"ers around here know the diff between a Cert and a C.A. But the other 99% don't. Hopefully, by the time they hit their online banking - they will have forgotten about the previous "router issue".
As usual, a small shaking of social engineering in a technical issue can turn a seemingly trivial security issue a very real security issue.
Kinetic stupidity has a new brand leader: Allen Zadr.
No, read the explanation again. The MitM can pass on the certificate but they can't sign the session key with that certificate's private key 'cos they don't have it.
You are not alone. This is not normal. None of this is normal.