Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security

Why One-time Passwords Suck For MITM Attacks 138

Posted by CmdrTaco from the my-password-is-pass1234 dept.
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."
This discussion has been archived. No new comments can be posted.

Why One-time Passwords Suck For MITM Attacks More

Why One-time Passwords Suck For MITM Attacks

Comments Filter:

  • The Love Triangle... (Score:5, Funny)

    by kcbanner ( 929309 ) * on Monday August 18, 2008 @05:17PM (#24650767) Homepage Journal
    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.

  • frequency in the wild ? (Score:5, Interesting)

    by jacquesm ( 154384 ) <j AT ww DOT com> on Monday August 18, 2008 @05:21PM (#24650821) Homepage

    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 ?

    • Yeah, just check the attacker's bank statement - you'll see whether or not his attacks have succeeded!

    • Re: (Score:3, Funny)

      by Intron ( 870560 )

      http://www.imdb.com/title/tt0212671/ [imdb.com]

      Yes. The above link was successful for 6 years.

    • Re: (Score:1, Insightful)

      by Anonymous Coward

      One place where these attacks actually happen is in hosting facilities. Often the switches are not configured properly and without ARP monitoring MITM attacks are trivial. With unencrypted protocols like FTP still in use, attackers don't even have to work that hard.

  • This is NOT an attack on SSL VPN (Score:5, Interesting)

    by ugen ( 93902 ) on Monday August 18, 2008 @05:27PM (#24650883)

    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.

    • Re:This is NOT an attack on SSL VPN (Score:5, Funny)

      by Diss Champ ( 934796 ) on Monday August 18, 2008 @05:36PM (#24650989)

      Cert authorities are notorious for poor checking. The main thing they check is that they are getting paid. There are things certificates are good for- knowing for sure the first time you see one for a site that they are who they claim they are without further checking is not one of them.

    • Roll yer own... IPCop and Zerina OpenVPN (Score:3, Interesting)

      by Anonymous Coward

      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 top

    • Re:This is NOT an attack on SSL VPN (Score:5, Insightful)

      by Sloppy ( 14984 ) on Monday August 18, 2008 @06:57PM (#24651845) Homepage Journal
      Authority is subjective. Once everyone realizes this, they might as well switch to the OpenPGP trust model, which acknowledges it, instead of trying to hide this inescapable truth from the user.

    • Re:This is NOT an attack on SSL VPN (Score:5, Informative)

      by tgd ( 2822 ) on Monday August 18, 2008 @08:31PM (#24652935)

      You miss the point -- they are issuing a valid cert for an internal address.

      "intranet" would be an example. Not intranet.mydomain.com.

      Since your DNS will append mydomain.com automatically, it leaves you vulnerable to anyone who installs an "intranet" cert on a server they have spoofed into your DNS if you the browse to "intranet".

      If "intranet" is an SSL VPN, then they can get in the middle and get your OTP.

    • Re: (Score:2)

      by Bert64 ( 520050 )

      Actually, SSL certificate signing is more about making money than security...
      It's a way for a few select players to create an artificial market and keep their monopoly cartel in the name of "security".

      Most of their checks are as rudimentary as "do you have an email at the domain? yes? ok then you can have a cert".

      What would be better, is if organizations you do business with (banks especially) issue you a certificate out of band (ie they give you it on physical media when you go to a branch or when they sen

  • long story short... (Score:5, Interesting)

    by brunascle ( 994197 ) * on Monday August 18, 2008 @05:29PM (#24650899)
    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.

    • Re:long story short... (Score:5, Insightful)

      by jacquesm ( 154384 ) <j AT ww DOT com> on Monday August 18, 2008 @05:32PM (#24650943) Homepage

      Shutting them down is stopping short, all the certificates issued by them need to be revoked as well and reissued by another CA after thorough checking.

      If there is one documented case there are likely to be many more undocumented cases.

      • Re:long story short... (Score:5, Insightful)

        by QuoteMstr ( 55051 ) <dan.colascione@gmail.com> on Monday August 18, 2008 @05:57PM (#24651199)

        Somebody, preferably a government agency, should be in charge of testing CAs. CAs have very strong economic incentives to loosen verification rules in order to compete and sell more certificates. When one CA loosens its rules a little bit, all the others are compelled to do the same to stay competitive. It's a race to the bottom [wikipedia.org].

        Market forces cannot solve the problem because there's a fundamental information asymmetry. Joe Myspace isn't going to understand what a root CA is, much less manually remove it from his browser. And even if he did understand what that meant, would he lose access to his favorite SSL-protected sites for some egghead's paranoid security fears?

        We need regulation, and we need it now. We need several free, worldwide certificate revocation lists [wikipedia.org], and we need agencies running these lists to randomly and anonymous ensure CAs are following the verification rules.

        Having just one CRL gives too much power to one authority, which is especially dangerous if these authorities are organs of government. Browsers should check all CRLs and consider a certificate invalid if, say, two-thirds of the CRLs say to do so.

        In any case, the current situation is untenable.

        • I don't know about you, but I remember enough of the history of the FBI and CIA to know that's a terrible idea. Anyway, the intarweb is international - which government?

          • You misunderstand my proposal. The FBI and CIA abused special investigatory powers. On the other hand, these bodies I'm proposing only need the power any private citizen would have. They're only likely to be government organizations because there's no profit in them.

            And the whole reason for having multiple organizations here is to avoid any one of them being made into a DoS-a-matic.

            Each organization only has the "power" to state "this certificate is invalid" or "this CA's certificates are invalid." It's up

            • Re: (Score:2)

              by mi ( 197448 )

              You misunderstand my proposal. The FBI and CIA abused special investigatory powers. On the other hand, these bodies I'm proposing only need the power any private citizen would have.

              If they are part of the government, they will be even more likely to cooperate with a warrant-less "search". Here is an example:

              1. A foreign company (example.co.bz) sets up a web-site and buys a certificate from this agency you are suggesting.
              2. You wish to buy something from them: a hotel room, a flight to Lahore — anything t

              • You don't buy certificates from these agencies. You buy them from CAs.

                What these agencies would also do is attempt to buy certificates from these CAs as well, except they'd try to obtain certificates they weren't supposed to. When they did, they'd update their CRLs and shame the companies with lax verification.

                • Re: (Score:3, Interesting)

                  by silas_moeckel ( 234313 )

                  Replace "attempt to buy" with a "get a court order" (or whatever flimsy paperwork the FBI is giving out because our fearless leader says it's good thats an entirely different point) throw in a gag order. Hell simplify the whole process and have them sign a signing cert to make a NSA CA legit in most browsers.

                  The SSL cert process is broken by design because stopping MITM attacks is hard. It's also only a tech good for commercial encryption if a power government wants to subvert it it will. Military grade

                • Re: (Score:2)

                  by mi ( 197448 )

                  You don't buy certificates from these agencies. You buy them from CAs.

                  We are discussing a (hypothetical) government agency in charge of issuing certificates (a CA). My point was, such an agency will be more cooperative with FBI, than a non-governmental entity.

                  • No, we are discussing a consumer watchdog agency that issues nothing except warnings. You don't buy certificates from this hypothetical organization.

              • The CA just signs your cert. Only you hold the private key.

                • Re: (Score:2)

                  by mi ( 197448 )

                  The CA just signs your cert. Only you hold the private key.

                  That's good, if I trust, that I obtained the matching public key via a reliable source — the key needs to be signed. Certificate Authorities are in charge of signing these keys — this way a browser needs only to know a handful of CAs and be able to use SSL with countless thousands of the CAs' customers.

                  If a CA issues a certificate for "Example, Inc." and, they can issue another one (with the same company name and domain), and give it t

        • Re: (Score:2)

          by Sloppy ( 14984 )

          Somebody, preferably a government agency, should be in charge of testing CAs.

          I think this is bad idea, and here's why.

          First, government regulation is going to add an air of trustworthiness to something we should already be increasingly skeptical of.

          Second, letting them certify the certifiers, gives them a way to impose political agendas. We have already seen governments, when unable to attack a server directly, attack their DNS records. Now they'll make CAs revoke certs for whomever they don't like, reg

      • Agreed. Doesn't revoking the signing root certificate then revoke all certificates signed by them? That's what needs to happen.

        • Yes, it does, but without checking all the certificates that were signed with that root we have no idea how many (and which!) other certificates they issued were bogus and that is very important information.

          It will give people that were using these certificates a chance to review their records to see if anything bad happened to them.

          The only other alternative is to mark all the parties that bought their certificates there as untrustworthy, but since there is probably nothing wrong with 99 % of the parties t

    • 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

      • Re: (Score:3, Funny)

        by kcbanner ( 929309 ) *
        ...they were then fired for their incompetence.
        ...then they were taken out and beaten to a pulp.
        ...then they were ground up into this powder!

    • Thawte (Score:5, Informative)

      by an.echte.trilingue ( 1063180 ) on Monday August 18, 2008 @05:51PM (#24651145) Homepage
      Thawte does this; look about halfway down the page [thawte.com]

      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.

      • It doesnt necessarily mean it was Thawte, though. From an earlier article [networkworld.com]:

        he simply checked the box that stated that the certificate was not going to be used on the internet and was for internal testing only. Luckily, Michael also stated that most CA's rejected his requests.

        It's a little vague, but it might mean that a lot of CAs have this checkbox.

  • A client cert, stored on the computer, should NOT be considered one factor in a two factor scheme, because the client computer is far too easy to compromise.

    OTOH, it makes a good point that a client cert (OR, hell, just caching the server cert and complaining when it changes!) should be used because its too easy to social engineer a valid cert from a CA

    • I agree. This is what SSH does, just cache the server's key and complain when it changes...this system works well (as long as your certain who your talking to on the first connection).

    • Likewise, an OTP doesn't answer "who you are". I'm not really sure what this headline is about.
      I get the gist of the journalism industry, with catchy headlines and so-so content, and the is Slashdot after all, but
      "One-time Passwords Suck For MITM Attacks" implies an awful lot.

      What does a OTP have to do with MITM anyway? I can't see how it can suck any more than normal password authentication and MITM attacks.
      Is there some delusion that OTPs establish identity?? It's just a password you carry in your pock

    • A client cert, stored on the computer, should NOT be considered one factor in a two factor scheme, because the client computer is far too easy to compromise.

      Well insofar as the client is who you're trying to protect, if the client computer is compromised, then you're already f*$ked. From the client-end of things, it should be sufficient to know, "if I'm not already compromised, then I won't become compromised by doing this."

      So client-end root certificates serve a very important function in the security system. If the client is good, and the trusted root server is giving good information, then the subsequent certs should all be good too. The problem here is

    • If you're worried about the client machine being compromised you can't trust passwords, certificates, one-time passwords, or anything else attached to or entered into the client system other than isolated computing environments in a challenge-response configuration (i.e. smartcards, etc.). If your authentication system uses any data that is ever stored in the client RAM, it is possible to obtain that data if the client system is compromised.

      You might not consider a host certificate plus a user password suff

    • Re: (Score:2)

      by Sloppy ( 14984 )

      A client cert, stored on the computer, should NOT be considered one factor in a two factor scheme, because the client computer is far too easy to compromise.

      If the client computer is compromised, then you have already lost everything. There is no authentication solution which can sustain that.

  • OTP can work effectively and does thwart MITM attacks if implemented properly. Using counter-based algorithms obviously is useless in my opinion but products based on time-based algorithms with effective end user policies are more than effective in doing the job. I'd like to see one person show me an attack public or otherwise that is able to counter an OTP that has a lifespan of 20 seconds and is implemented properly with account lockout policies. Add to that end-user certificates and you have extremely ef

    • This is not about one time passwords, it's about misusing them.

      And, while it is about poor practices issuing certs, it is more about the inherent weakness of trying to do it all with a single browser. And about the inherent weakness in using certificates issued by the public CAs.

      With the current tools, requiring the client to have a cert, too, mitigates things a bit, but the client should never have been allowed to connect without a cert anyway, and neither the client nor the server should be using certific

      • Re: (Score:2)

        by lgw ( 121541 )

        If you need security, you have to be willing to issue your own certs for day-to-day operations.

        Today this is the main factor that distinguishes real security from pretend security in practice. I think banks and other financial institutions have to do this internally to meet auditing requirements - at least, the market for expensive boxes that do nothing but act as an automated internal CA is bigger than you'd think.

        I can't think of any other way to validate that endpoints' identities without providing your own CA, and all the crypto in the world won't help if one endpoint is the attacker (MITM or ot

  • My wife has shown something to me today that really has been bugging me for the entire day, she connected to her work via VPN with a security token, a number generator that is given to her that is synchronized against a server number list I suppose and when she ran a search on something she mistyped, our provider, Rogers Canada, was able to get the mistyped word and injected their own search frame into the HTML that returned to her browser.

    Now, I am not sure how this happened, I was under the impression tha

    • Re: (Score:3, Informative)

      by carleton ( 97218 )

      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

      • You are probably correct, I am going to check that client. I wonder how it decides what is split, just by filtering out anything that is directed at an IP not within the company subnet or maybe there are lists of IPs that go through encrypted channel. Thanks.

    • Re: (Score:1, Interesting)

      by Anonymous Coward

      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?

    • Uhm... if she was doing a search at Google, she was most likely not using the VPN connection, unless your wives employer happens to be Google and you're talking about their internal search mask or something...well I'm no Google insider. ;) Or maybe she used a client on the other side to access Google and your employer happens to be with the same provider?

    • Re: (Score:2)

      by zonky ( 1153039 )
      Depends how the VPN is setup, and whether or not it sets itself as the default IP gateway. It could be that it's only routing VPN destined traffic across it. Presumably when she mis-typed, she was routing across her normal gateway, which Rogers then 'improved'.
    • VPNs are generally set up to route only a specific network's traffic - for instance, if your internal stuff is on 10.0.0.0/8, there's a rule routing 10/8 to the vpn, while the regular stuff (giggle) goes out into the big bad world.

  • too bad for the new blizzard authenticators (Score:3, Interesting)

    by poetmatt ( 793785 ) on Monday August 18, 2008 @06:14PM (#24651365) Journal

    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.

    • The people who believe that probably also believe that they're getting keyloggers from addons. Or that copy-and-pasting your credentials will defeat a keylogger. Or one of many other numerous ill-conceived notions.

      • Yep.

        I trashed the authenticators on wowinsider and got flamed to hell by people going "this thing is foolproof zomg how dare you doubt blizzard"

        • Hehe. Really? I probably read your posting.

          For what it's worth... I think the tokens are a good step. They're probably better than the weak passwords and low-hanging-fruit desktops that make up the current environment. But people should understand their limitations and that they aren't invincible.

  • Can anyone verify what, if any, difference these "testing ony" certificates are?

    Do they come up with the name "TESTING ONLY - Mozilla corporation", or it it more like the sub-root key is named "Strictly testing only", which requires you to inspect the certificate fully for every connection?

    Fortunately we've used client-side certificates for our 2 factor authentication for years. Its cheaper than tokens, and easier too.

  • I don't see how this is much better? (Score:4, Interesting)

    by JSBiff ( 87824 ) on Monday August 18, 2008 @07:21PM (#24652171) Journal

    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?

  • Sort of on-topic: I'd just like to say that recently I decided to code a Java app for Smartphones that is a token generator [calum.org] (MD5 of minutes since 1970 and known string appended) - it works pretty well. I'm sure all you bastards will find some flaws in it though.

    • The idea is cute, but if you're going to rely even partly on a hash, you should at least use a reasonably strong hash. Base it on HMAC(SHA-256), where the secret code is stored as a 256-bit hash and used as the key for the HMAC, hashing the minutes.

      • Re: (Score:2)

        by caluml ( 551744 )
        It really doesn't matter. If you don't know the key, you can't work out what the md5 hash will be.

        • If it was that simple, you'd just use + as your hash function. No.

          The minutes are well-known so that is already a lot of entropy you're giving the attacker for free. They don't know the string, but if they intercept the hash, they can work it out almost trivially because of how broken MD5 is. At least using HMAC and SHA256 (or better) will insulate the key from hash reversal.

  • Forgive my squirrelly ignorance, but is using an OTP even supposed to be a counter to a MITM attack? I that they were used so that there was no one password to be compromised, prevent "replay" attacks, that sort of thing...

  • OTPs are meant to help against eavesdropping.

    Anybody who feels the need to point out that they don't protect against MITM hasn't been paying attention somewhere in Security 101.

  • Not all OTP's are vulnerable to MITM! (Score:3, Interesting)

    by freaker_TuC ( 7632 ) on Tuesday August 19, 2008 @03:00AM (#24655417) Homepage Journal

    Not all OTP's are prone to MITM attacks; the Yubikey [yubico.com] 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?

  • Rofl (Score:2)

    by X.25 ( 255792 )

    From the article: ...he didn't disclose the CA that issued it to him but it was one that was trusted in IE by default.

    Hey, let's blame the SSL, and not the retarded cert authority.

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close