Forgot your password?
typodupeerror
Security Communications Encryption IT News

Become an SSLAdmin In a Few Easy Steps 64

Posted by Soulskill
from the chain-of-trust dept.
Renderer of Evil writes "With news that it is rather simple to mimic authority with many webmail providers in order to coax an SSL certificate authority into creating one for the domain, a Canadian security expert has decided to take it upon himself to see who out there is actually vulnerable and provide information to the public on how prevalent this issue is as we speak. Out of eleven webmail services chosen at random and without prejudice, just under half of them permitted him to register with credentials (ssladmin) that allowed him to create an SSL certificate in their name. In most of these cases, there was a pre-existing, legitimately-acquired certificate." Update: 04/19 01:30 GMT by S : Kurt Seifried's original paper, on which the BetaNews article is based, provides more detailed information on the subject (PDF).
This discussion has been archived. No new comments can be posted.

Become an SSLAdmin In a Few Easy Steps

Comments Filter:
  • I have no idea what Slashdot articles are talking about.
    and at least for SSLAdmin, their is no easy search able definition.

    • Re: (Score:2, Redundant)

      by NNKK (218503)

      From TFS: "Out of eleven webmail services chosen at random and without prejudice, just under half of them permitted him to register with credentials (ssladmin) that allowed him to create an SSL certificate in their name."

      Does that help?

    • Re: (Score:2, Informative)

      by Anonymous Coward

      In order to get a SSL certificate for your domain for use with E-Mail you have to provide an email address on which the CA sends an E-Mail to confirm your identity.
      Most CAs have a list of predefined addresses, one of which is ssladmin@.

    • Re:Sometimes (Score:5, Informative)

      by Arancaytar (966377) <arancaytar.ilyaran@gmail.com> on Sunday April 18, 2010 @09:40AM (#31886722) Homepage

      In a nutshell:

      When you log in to your email account, the server sends you a certificate to confirm that it does indeed belong to the email provider and not an eavesdropper.

      By registering an email account like "admin" or "ssladmin", an attacker could contact certification authorities and request a new certificate pretending to be a staff member of the service.

      They could then use that certificate to intercept and redirect your connection to their own server, intercepting passwords and emails, while your browser will still tell you that you are connected with a genuine mail server.

      • by iluvcapra (782887)

        By registering an email account like "admin" or "ssladmin", an attacker could contact certification authorities and request a new certificate pretending to be a staff member of the service.

        Would it really be that simple? Wouldn't a CA require any correspondence from the mail site be signed with one of their certificates?In TFA the author never succeeds (or tries) to get a CA to go along.

        • Re:Sometimes (Score:4, Informative)

          by Anonymous Coward on Sunday April 18, 2010 @09:55AM (#31886780)

          He doesn't need to try this, it's established procedure. Yes, the idea behind SSL was to require more reliable identification than just being able to receive mail for one of a few mail addresses. What was initially the plan with SSL is now called an "extended verification" certificate. Regular SSL certificates are less secure than DNSSec distributed keys would be. DNSSec would at least ensure actual control over the domain, not just the ability to receive mail for that domain. The lack of proper authentication by the certificate authorities has been a problem for a long time and this is just another outrageously simple way of getting a certificate for someone else's domain.

          Let me be clear on this: It's the CA's fault. The mail provider could plug this hole by not allowing users to register these addresses, but those addresses are arbitrary. It's the CA's job to ensure that they're only giving certificates to the owners of a domain.

        • Re: (Score:3, Informative)

          by NNKK (218503)

          Would it really be that simple? Wouldn't a CA require any correspondence from the mail site be signed with one of their certificates?

          Yes it would, and no they wouldn't. Most certificates are issued in a completely automated manner, and there is no good way to make sure that a certificate hasn't already been issued for the domain by another CA (one could try making an HTTPS connection to the server, but that's still vulnerable to manipulation).

          • by iluvcapra (782887)
            So you're saying I can send an email to a root CA, and as long as the clear, unsigned from field looks serious they'll sign my cert for a domain? Can you DEMONSTRATE this? TFA sure didn't.
            • Re: (Score:2, Informative)

              by Anonymous Coward

              No, the CA sends mail to an address of your choice, which must be in the domain that the certificate signing request is for and have a user part which is on a list of "special" addresses for domain ownership verification. This mail contains a code which you then use to confirm that you can indeed read email for that address. Then the CA signs the certificate and you're done. This is not news. TFA is about the fact that the existence of this (stupid) protocol appears to be unknown to quite a lot of mail serv

            • Re:Sometimes (Score:5, Informative)

              by Wannabe Code Monkey (638617) on Sunday April 18, 2010 @10:35AM (#31886956)

              So you're saying I can send an email to a root CA, and as long as the clear, unsigned from field looks serious they'll sign my cert for a domain? Can you DEMONSTRATE this? TFA sure didn't.

              You sure are angry for a Sunday morning. From the Betanews article:

              1. Find a free Web mail provider.
              2. Register an account such as ssladmin.
              3. Go to RapidSSL.com and buy a certificate. When given the choice of what e-mail address to use, simply select ssladmin.
              4. Go through certificate registration process (this takes about 20 minutes).
              5. You will now have a secure Web certificate for that Web mail provider

              So, it's not the attacker sending an email from ssladmin@example.com to the certificate authority asking for a cert that does it. It's the attacker telling the certificate authority that ssladmin@example.com should be used to prove control over of the domain, then RapidSSL.com would send a confirmation email to that address assuming it was under control of the right people. I guess ssladmin is on a predetermined list of email addresses they allow for authentication.

              In his own tests, Seifried says, it usually took only a half-hour to acquire a perfectly valid certificate for a major Web mail service.

              So, yes, he can demonstrate this.

              • Re:Sometimes (Score:4, Informative)

                by moonbender (547943) <moonbender@gmai l . com> on Sunday April 18, 2010 @10:52AM (#31887040)

                That's exactly right. The primary email contact is taken from WHOIS, but there are a few addresses that seem to be alternatives for most CAs (e.g. hostmaster). But for some CAs, the list of alternate addresses is rather long, ie:

                administrator@seifried.org
                admin@seifried.org
                info@seifried.org
                hostmaster@seifried.org
                root@seifried.org
                ssladmin@seifried.org
                sysadmin@seifried.org
                webmaster@seifried.org
                info@seifried.org
                postmaster@seifried.org

                This is the revised list which is in use by RapidSSL (a Verisign subsidiary) now, before the discussion was started. The original list was longer and contained generic addresses like is, it and mis (mis?!). It's not surprising that some mail providers didn't prevent people from registering a few of those.

                The whole thing is documented on https://bugzilla.mozilla.org/show_bug.cgi?id=556468 [mozilla.org] and in the Kurt Seifried's original article on the issue http://www.linux-magazine.com/Issues/2010/114/BREACH-OF-TRUST [linux-magazine.com] (which are really the two links the Slashdot summary should have had).

          • Re:Sometimes (Score:5, Informative)

            by J-F Mammet (769) on Sunday April 18, 2010 @10:12AM (#31886846) Homepage

            It depends on who will issue the certificate. Serious companies like Network Solution, Thawte or even Godaddy will send a validation email to the owner of the domain (if it's listed in the whois data) or require you to create a new file on the web site or a DNS CNAME to prove that you have admin right on the domain. It's a bit of a pain in the ass when you are registering SSL certs for a third party partner, but it's rather safe.
            Some SSL companies though will simply ask you to provide an email for that domain and send a validation link to that email. So you could create ssladmin@hotmail.com and they would happily create you a perfectly valid SSL certificate for hotmail.com you could use for man in the middle attacks.

            • by luizd (716122)
              OK, OK... now tell me if it makes any difference for your browser/app if the certificate is generated by some respected CA or a crappy one. There is no "trust level", just yes or no. Any CA can provide ANY certificate for ANY host. You control one CA, you control them all. If you can make any accepted CA generate the desired certificate, by bypassing identity validation, by political force, by social engineering, by whatever, SSL is just useless. It just protect you from someone a little more "powerful" tha
        • by iluvcapra (782887)
          Sorry I just read the first article. You're right, and it's pathetic.
      • Re: (Score:1, Informative)

        by Anonymous Coward

        In a nutshell:

        When you log in to your email account, the server sends you a certificate to confirm that it does indeed belong to the email provider and not an eavesdropper.

        By registering an email account like "admin" or "ssladmin", an attacker could contact certification authorities and request a new certificate pretending to be a staff member of the service.

        They could then use that certificate to intercept and redirect your connection to their own server, intercepting passwords and emails, while your browser will still tell you that you are connected with a genuine mail server.

        Oh, so rather than being a guide to administering your own SSL certificates and SSL-using services, like Slashdot's title implies, it's really talking about a social-engineering security vulnerability with several email providers. Yes, that clears things up nicely.

        • by MrCrassic (994046)

          Well, doing the former is rather simple; there are tons of tutorials for that on the Internet. Technically, when one takes advantage of this flaw, they do become a SSL admin in the eyes of the CA, which is the point.

          I'm sure the complaints would've been loud and clear if the articles were on the former.

        • Agreed, about the Slashdot article title. More accuracy in the future, please? Or someone else start a news for nerds site? Thanks.

          But this: "it's really talking about a social-engineering security vulnerability with several email providers" is not quite right.

          The vulnerability exists because of a lack of protocol and is (loosely) a social engineering vulnerability between the CAs and those email providers. That is, the CAs are also part of the vulnerability.

      • I thought it had to be something like that.

        Thanks for the information.

        I am surprised that they would allow anything with admin in it, I would assume any email I got with admin@whatever.xxx (or something like that) would be from the runners of the email service.

      • by ari_j (90255)
        How does one use a certificate to intercept and redirect a connection intended for legitimate.example.com to evil.example.net? You're missing the step of how that is done. My understanding, apparently wrong, is that the SSL certificate for a TCP server does two things: It authenticates to the client that he is connected to the correct site and it includes a public key for encrypting communication between server and client. That is, it tells the client that it got the right server. Just how does one use
        • Re: (Score:3, Informative)

          by Arancaytar (966377)

          You are right, the SSL certificate is not used to intercept the connection. It is merely used to disguise an intercepted connection as a genuine one.

          The interception itself can be done by many different technical means, including DNS poisoning/spoofing, packet sniffing on a wireless network, etc. These aren't always trivial or feasible - but the risk of them is the reason SSL certificates exist in the first place.

          • by ari_j (90255)
            That makes sense. I was worried that something else was going on where SSL certificates were being used for more than they were intended for, causing insecurity. Cf. social security numbers.
      • by MrCrassic (994046)

        A huge mitigating factor for this flaw is that most huge free-email services (Google Mail, Hotmail, Yahoo, et al) prevent the registration of typical admin-like names (root, admin, ssladmin, postmaster, webmaster, etc). Additionally, some SSL CAs (StartCom, GoDaddy) do attempt to look up the real admin of the site and send confirmation emails there, which makes this useless.

        While it's a serious flaw that needs to be attended to, it's not as impacting as it seems. (In fact, Seifried used portugalmail.pt as o

        • Re: (Score:3, Insightful)

          by seifried (12921)
          Another problem however is that there is no way for a domain holder to check if SSL certificates have been issued in their name from all the SSL providers. There may be someone out there with a certificate in your name and you'll literally never know unless you run into it or someone reports it to you (which is unlikely since it is a legit certificate).
        • by DavidTC (10147)

          A huge mitigating factor for this flaw is that most huge free-email services (Google Mail, Hotmail, Yahoo, et al) prevent the registration of typical admin-like names (root, admin, ssladmin, postmaster, webmaster, etc).

          I'm sure that Jesus himself has come down from heaven and told them all the names, that every single SSL CA uses, which they need to reserve on their system. And comes down with an update when some brand new SSL CA decides that they'll send SSL certs to configssl@

          Or, you know, not.

          Additi

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Certificate authorities (which issue certificates for SSL to web sites and email providers) must somehow know whom they're talking to when they are presented with a certificate signing request. While this authentication phase was meant to involve some documentation, for quite some time now the only proof of identity required to get an SSL certificate is to be able to receive mail under a list of "special" mail addresses under a domain. One of the names is "ssladmin@example.com" (where example.com is the dom

      • by DavidTC (10147)

        It turns out that the importance of these addresses is not widely known amongst mail service providers.

        Yes, the important of these addresses that SSL providers decided to invent out of thin air is not well known to random other people. Imagine that.

        There actually are real defined role accounts. 'ssladmin@' is not one of them. Neither is, for a more surreal example of where they will send the cert, 'info@'. People can't just wander around inventing role accounts for third parties and then pretending they

  • by hweimer (709734) on Sunday April 18, 2010 @09:58AM (#31886796) Homepage

    ... they want their exploits back.

  • by DarkOx (621550) on Sunday April 18, 2010 @10:05AM (#31886830) Journal

    They really should:
    1. Do more out of band communication; e-mail being virtually impossible to verify is not a good medium to confirm who you are dealing with.

    2. They should probably use the contact on the domain registration period. Most of them accept any number of alternate mail address that might or might not be protected. root@doamin, hostmaster@domain, ssladmin@domain, administrator@domain, postmaster@domain, and so forth. This is the exploit done in the TFA.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Correct. He says he's not sure whom to blame.

      *I'm* sure whom to blame: the CAs, who are falling prey to the "man who walks in in a UPS uniform" trick.

      The LHS of your email address does *not* constitute an authentication scheme, people.

    • by gravyface (592485)
      I buy my certs from rapidssl.com (because afaik, they're the only ones that are actually "rapid"), but TFA missed one thing: they require that you have a land line (cellphones, at the least the ones I tried from standard NA carriers, do not work) that's used to verify an on-screen code when the automated verification call comes through. Still, not really a big deal -- I'm sure there's plenty of methods out there to obtain access to a "fake" land line (I'm sure you could kindly ask a StarBucks employee to p
      • by daeg (828071)

        I switched to DigiCert a few months ago and they are much more "rapid" than rapidssl was ever for us.

        Our original account with Rapid was under one company name. We subsequently changed the holding company's name on a later request and apparently our account was flagged for manual validation 100% of the time. Each time we renewed it would take 4 or 5 days of faxing forms, confirmations, phone calls from hell, etc.

        The nice thing was, at the time, they were one of the few SSL providers to allow unlimited re-is

      • by seifried (12921)

        The original article I wrote at http://www.linux-magazine.com/w3/issue/114/054-055_kurt.pdf [linux-magazine.com] (that was copied by this guy) covers that:

        for the phone verification, you can just use an anonymous prepaid cell and mumble; it’s automated and doesn’t care

        The phone check does nothing security wise, it is just a bit of security theater

  • Symantec has added mail servers and operating systems to their definitions list. I'm not taking any chances. I'm updating right n***********************
  • by jgreco (1542031) on Sunday April 18, 2010 @10:12AM (#31886850)

    This is nothing new, we've been talking about issues like this since the introduction of SSL. Either you have onerous and thorough verification, which makes SSL a real pain to deploy and discourages adoption, or you have an easy-to-game system that makes SSL less secure. Security always involves lots of effort, and that's simply at odds with the way things are "supposed to work" on the Internet.

    • by guruevi (827432)

      It doesn't make SSL less secure. It just makes it less trustworthy. You should never trust an SSL certificate to provide you with any identification. SSL's are there to encrypt the connection and so far, that level of protection provided is fairly immune to attacks.

      If you want a website to identify themselves, they should provide you with something else, an identifier that is unique to your account with them that you might have established before (as many banks are starting to do - they provide a picture wi

      • We can actually validate certificates relatively well using "notaries". This gives us in effect validation of identity. It's better than trusting CAs, and you don't have to buy certificates:

        "Perspectives"

        Demo [networknotary.org]

        About [cmu.edu]

        Firefox extension [cmu.edu]

  • Same thing Mike Zusman did at presented about already at BlackHat/Defcon a couple of years back. Can't believe it's STILL going on. When will these companies learn.
    • > When will these companies learn.

      Learn what? That neither their customers nor the users actually give a damn about security? They already know that.

  • Though security on the Web is broken by design Perspectives [cmu.edu], while no panacea, can help. Be sure and check "Contact notaries for all HTTPS sites".
  • Once again, this goes into my direction of saying that your registrar is the only party that can really certify that you are the owner of the TLD you registered with them. Let's change ICANN's rules and enforce that it's the duty of each accredited registrar to provide certs (and how about requesting that it should be a free service, already paid with the domain, and for how many subdomains as needed?).
    • > ...and how about requesting that it should be a free service...

      That would just mean that those of us who don't need certificates would have to pay for them anyway.

      • Considering:
        - the number of accredited registrar
        - the price of domains
        - the fact that there's a lot of competition and
        - the economy of large scale

        I am convince that such added charge would be insignificant. I shall now spell the current situation where SSL certs are overpriced, when they should cost nothing (eg: there's no server to maintain once the cert has been issued, just a trivial function to implement on a web site) while there are root servers to keep online and the registry database itself to
  • Verisign just told me they're going to truncate the list of eligible email addresses down to a more manageable 6.

This screen intentionally left blank.

Working...