Slashdot Mirror
Why One-time Passwords Suck For MITM Attacks
whitehartstag writes "Black Hat 08 disclosed several SSL VPN and DNS vulnerabilities that caused several people to sit up and take notice. Some of these new exploits performed a brilliant Man-In-The-Middle attack on SSL VPN tunnels. This article walks you through how using certificates, instead of OTP tokens, for second-factor authentication can increase the security of your SSL VPN against these new types of attacks."
Alice and Bob's relationship will be at stake when an unknown interloper...Larry...arrives on the scene. Is this love line segment about to become a love triangle? Will the self-signed certs be accepted?
Coming to you this fall...Larry is...The Man in the Middle.
Obligatory blog plug: http://www.caseybanner.ca/
http://xkcd.com/177/
Eve
I know that there are some people that are very clever at doing these man in the middle attacks, but they usually happen in an academic setting as proof of concept.
Have there been documented cases of (successful) mitm attacks on banks or other high profile targets ?
MP3 Search Engine
This isn't an attack on anything, really.
Here is what the article says:
"They will then go to all of the trusted CAâ(TM)s and try to get them to issue them a valid âoeinternal onlyâ certificate with the FQDN of a target sslvpn URL. As soon as they get a success, that company now becomes their target of choice. Remember, the certificate they need can be issued from any trusted CA in the browser and does not need to match the CA that the SSLVPN gateway is using."
Now, may be I am not understanding the purpose of SSL certificates and the PKI infrastructure in general, but I was under distinct impression that the whole reason those authorities exist is to verify who they give the certificate to, and in such a way that we, users, can trust these certificates.
If this is not correct, and anyone can with relatively minor effort get certificate for a random domain name from one of recognized cert. authorities - game over, none of this matters, the entire PKI infrastructure is in the crapper.
So, either we have to deal with cert. authorities signing things they should not or this is not an attack that is worth discussing. Everything else is a half-measure.
The guy was able to buy a certificate for Microsoft's login.live.com, from an undisclosed CA that's trusted by IE by default, because he checked a box saying it was only going to be used for internal use.
Please reveal the CA. They need to be shut down.
... and then the execs need to be drawn and quartered.
Only partly joking. This is such a flaming case of massive malfeasance that impacts **SO** much more than your run-of-the-mill corruption and other shenanigans. As other posters have noted, this shadiness means certs like this are, in general, complete crap, and given the extent to which many very vital businesses conduct online operations on the basis of these certs, a simple slap on the hand -- or even forcing the CA out of business -- is far too limited a repercussion.
Cheers,
"What in the name of Fats Waller is that?"
"A four-foot prune."
Thawte does this; look about halfway down the page
I must say that in general I have been unsatisfied with thawte. They gave me a hard time about re-issuing my cert after the debian-ssl debacle and in general their tech support people don't know anything beyond what is already on their site.
Seriously, I pay over a hundred clams a year just to so that I can have ssl communication without the "OMFG THIS SITE IS GONNA HAXOR YOU" dialog box pop up in user's browsers, and they pull all kinds of monkey business.
But since verisign owns them, I wouldn't hold my breath for them to be shut down. My guess is the other CAs do this, too.
weirdest thing I ever saw: scientology advertising on slashdot.
Too bad that the new authenticators from blizzard are OTP's and people are convinced that it is 100% foolproof, as this article tends to prove otherwise.
Most VPN Clients I've used support a split tunnel mode... the idea being that data going to your company's internal LAN goes through the VPN tunnel ; data going elsewhere goes outside the tunnel. The idea here is that if you're trying to do stuff on the public network (that's assumed to be less sensitive to begin with), you don't have to wait for the traffic to flow from your computer to your company and then to the site you want (worst case being if you wanted to say stream music off your music server on your home LAN)
That would be my guess.
I made a VPN server using IPCop and added the Zerina OpenVPN package to it. Simple plug and play. It has it's own internal certificate authority, and issues it's own client certificates for each road warrior client you set up to be an OpenVPN client under the Zerina webgui. Very secure, since it will only accept the client certificates that were generated locally to the machine. The cost for the software, is of course FREE. The old AMD Athlon 2400 Compaq PC upon which I'm running it, is worth maybe $200 tops, including the second NIC card I had to put into it to make it a true dual-homed Linux firewall. It supports 15-20 concurrent roadwarrior connections easily, then my single T-1 line is saturated long before the IPCop box reaches any significant load.
I might be missing something here, but this article proposes, as a way of trying to make the management of keys/certs easier (which is necessary to implement the client-side certs), to use this "SecureAuth" system. . . which downloads an SSL cert to your computer. So. . . uhh, why can't an attacker intercept this? Well, the answer seems to be (maybe I'm misunderstanding here) that before the SecureAuth system will download the cert to you, it sends you some sort of one-time-password via phone or SMS, which you must enter to get the key . . . but once you've typed in this one time password you got by phone, what prevents the MITM from intercepting that passsword the exact same way it would have been attacking the other one-time-password generated by the keychain fob, and therefor be able to impersonate you to the SecureAuth server and get the client cert which should have been sent to you?
We need more Red Dwarf references...
We need more Red Dwarf references...
A superlative suggestion sir, with only two minor drawbacks: one, we don't have enough boys from the dwarf and two, we don't have enough boys from the dwarf. I know that technically that's only one drawback, but I thought it was such a big one it was worth mentioning twice.
Me failed English...
FreeBSD over Linux. If my comments seem odd, this may explain...
Not all OTP's are prone to MITM attacks; the Yubikey for example has a (8hz) timer built in, initialized to a random value on connection. Next time a OTP gets generated the timestamp moves up too with a maximal difference of 10%. This timer prevents MITM attacks; without the use of a battery. Read more on their website.
I'm currently writing an authentication platform working with Yubico's demo and reprogrammed Yubikeys.
I'm not affiliated with Yubico, just a user of their product ; although I can tell this key has it done right!
They also seem to have a nice mindset allowing a large suite of usages with their product by focussing on the hardware only, leaving the software with 3rd party developers.
Oh, and did I mention it was open source?
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..