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."
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.
To answer your question, I though the link was quite appropriate, it was an xkcd that I had missed, and quite enjoyed it.
Also, do you think you own this space or something? I mean your post sure took up alot of room with 0 useful content, while the parents one-liner was a much better use of space.
Obligatory blog plug: http://www.caseybanner.ca/
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.
VPN may encrypt between her computer and the end point; but if she uses the endpoint connection to surf the web, then that activity may be unencrypted.
Does her company have the same service provider as you do at home?
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...
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..