Become an SSLAdmin In a Few Easy Steps

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).

Comments

Slashdot SSLAdmin

[Anonymous Coward]

Error establishing a database connection

Sometimes

[wisnoskij]

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

Re:Sometimes

[NNKK]

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:Sometimes

[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

[Arancaytar]

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.

Re:Sometimes

[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 domain for which the SSL certificate is going to be issued). If you can receive mail for that address, you can go to a number of certificate authorities and get a certificate for example.com. It is therefore expected that mail services do not allow regular users to get that email address or one of the other dozen special addresses. It turns out that the importance of these addresses is not widely known amongst mail service providers. That enables attackers to get SSL certificates for the domains of these services, which can then be used to perform man-in-the-middle attacks on all mail users of these services, i.e. read their passwords and their mail regardless of in-transit encryption.

Re:Sometimes

[iluvcapra]

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

[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.

Re:Sometimes

[wisnoskij]

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.

Re:Sometimes

[Anonymous Coward]

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:Sometimes

[NNKK]

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).

Re:Sometimes

[iluvcapra]

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:Sometimes

[iluvcapra]

Sorry I just read the first article. You're right, and it's pathetic.

Re:Sometimes

[J-F Mammet]

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.

Re:Sometimes

[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 service providers who consequently do not reserve these addresses and instead allow mere users to register them, which puts these users in a position where they can get certificates for the domain of the mail service provider.

Re:Sometimes

[Wannabe Code Monkey]

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

[moonbender]

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 and in the Kurt Seifried's original article on the issue http://www.linux-magazine.com/Issues/2010/114/BREACH-OF-TRUST (which are really the two links the Slashdot summary should have had).

Re:Sometimes

[Anonymous Coward]

I have difficulty with the words "serious" and "Network Solutions" in the same sentence....

Re:Sometimes

[Anonymous Coward]

Correction: It's "extended validation". Not that it makes a difference. It's just a fancy name for what CAs were supposed to be doing all along and are now charging a boatload extra for.

Re:Sometimes

[ari_j]

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 an SSL certificate to force a client to connect to the wrong server?

Re:Sometimes

[Arancaytar]

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.

Re:Sometimes

[Anonymous Coward]

**whine**sniffle**I have no idea what Slashdot articles are talking about. and at least for SSLAdmin, their is no easy search able definition.**sob**

O Rly?Here, you fucking dumbass.

Re:Sometimes

[MrCrassic]

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.

Re:Sometimes

[ari_j]

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.

Re:Sometimes

[MrCrassic]

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 one of his test domains, which is small relative to the heavyweights in the free e-mail space.)

Re:Sometimes

[J-F Mammet]

Yeah I know, that's why I don't work with them unless absolutely required to do, like some of our partners do. They are much more expensive and much more annoying to work with than Godaddy for example. Not that I like Godaddy, who at least should have chosen a name that make them look like a serious business, but at least their pricing is fair.

Re:Sometimes

[seifried]

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).

Re:Sometimes

[Onymous Coward]

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.

Re:Sometimes

[Anonymous Coward]

I am completely surprised reading this that any sort of authorization is made other than admin contact email from whois. I have only used Godaddy.com ssl certs and have helped many people apply for and install them and every time (even on the cheap $15 on sales ssls) there is a request from the admin contact unless the domain resides in the same account (which means they control it).

Re:Sometimes

[luizd]

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" than yourself. Correct me if I'm wrong but many respected CA can be persuaded by big countries, isn't it? How I love my PGP.

Re:Sometimes

[DavidTC]

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.

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.

It doesn't really matter what 'some' of them do, as attackers would presumably get certs from those who don't.

Re:Sometimes

[DavidTC]

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 are authoritative.

And there's not, IIRC, some definitive 'role account' for 'people in charge of a domain'. There's not a domainmaster@ to go along with postmaster@ and webmaster@. We don't need a defined role account, as the person in charge of the domain is, duh, supposed to be the technical contact in the whois, which is the only address which should be sent the SSL cert for a domain.

Even if there actually is some 'domain management role account', (People will argue 'root' is, but that's wrong. That's not actually a defined role account.) that still doesn't mean certs should be sent to random addresses that vaguely sound 'in charge-ish'. Just to the whois tech contact and whatever the role account is.

Re:slashdoted already!

[daveb1]

wtf mod me down but dont' provide a link? what is this mod me down Sunday?

interestingly he didn't try google / gmail

[daveb1]

interestingly he didn't try google / gmail

Re:interestingly he didn't try google / gmail

[wisnoskij]

"Out of eleven webmail services chosen at random and without prejudice"

so actually it probably is not interesting, just random chance.

Re:interestingly he didn't try google / gmail

[Anonymous Coward]

I imagine he suspected that he'd have a better success rate choosing from smaller providers.

1999 just called ...

[hweimer]

... they want their exploits back.

The CA's are not doing their due dilligence

[DarkOx]

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:The CA's are not doing their due dilligence

[Anonymous Coward]

Uh. Why not just require the domain DNS to be updated with a key? Akin to what Google is doing to verify domain authenticity.

sslrequestd41d8cd98f00b2.mydomain.com CNAME theca.com

Re:The CA's are not doing their due dilligence

[Anonymous Coward]

Without DNSSec, that is also vulnerable. The attacker could man-in-the-middle the DNS request and provide the additional record (just like he could MitM the MX record and divert the email). With DNSSec however, the record would have to be signed, which could be done very securely offline. On the other hand, then there would hardly be a reason to use SSL with CA-issued certificates: You could simple distribute the public SSL key via DNSSec directly.

Re:The CA's are not doing their due dilligence

[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.

Re:The CA's are not doing their due dilligence

[gravyface]

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 pass you the phone when RapidSSL calls too). Having said that, I'm sure they can all be exploited somehow -- I know of another one that asks for your company letterhead to be faxed over, like that tells you anything.

Re:The CA's are not doing their due dilligence

[daeg]

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-issuance. Digicert does too, and has even better prices AFAIK.

(Note: I don't work for them or have any financial interest in them)

Re:The CA's are not doing their due dilligence

[gravyface]

Nice. I'll have to check that out.

Re:The CA's are not doing their due dilligence

[seifried]

The original article I wrote at http://www.linux-magazine.com/w3/issue/114/054-055_kurt.pdf (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

Re:The CA's are not doing their due dilligence

[Anonymous Coward]

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.

They should probably use the contact on the domain registration period

Not all domains provide email contact details (e.g. .co.uk).

easy fix

[catmistake]

Symantec has added mail servers and operating systems to their definitions list. I'm not taking any chances. I'm updating right n***********************

This is nothing new

[jgreco]

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.

Re:This is nothing new

[guruevi]

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 with a non-sense phrase that you established during the account creation procedure).

Re:This is nothing new

[Onymous Coward]

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

About

Firefox extension

Re:This is nothing new

[Anonymous Coward]

SSL's are there to encrypt the connection and so far, that level of protection provided is fairly immune to attacks.

Except for man in the middle attacks, which the "identification" part of SSL is supposed to protect against.

Re:slashdoted already!

[Anonymous Coward]

what is this mod me down Sunday?

More like wannabe weekend. Weekends on /. have been like this for years now, all the dumbasses come out of the woodwork. They probably didn't know what you meant by "mirror".

This SAME thing/study was already done.

[higapleez]

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.

Re:This SAME thing/study was already done.

[John Hasler]

> When will these companies learn.

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

Install "Perspectives"

[John Hasler]

Though security on the Web is broken by design Perspectives , while no panacea, can help. Be sure and check "Contact notaries for all HTTPS sites".

Re:slashdoted already!

[Anonymous Coward]

Misspelling of "slashdotted"

Questionable grammar and capitalization

Providing no content of value

UID over 1.6M

Yeah, it's a mystery why you were downmodded.

When will registrar be required to do this?

[GPLHost-Thomas]

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?).

Re:When will registrar be required to do this?

[John Hasler]

> ...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.

Re:When will registrar be required to do this?

[GPLHost-Thomas]

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 maintain).

I also find totally stupid that SSL providers are sending certs to email addresses when a web interface would be so much more convenient (click to revoke a cert, click to download a new one as a file...).

Parent comment is the best summary on this thread

[Anonymous Coward]

Also, here is a list of approvers for VeriSign / GeoTrust certs: (QuickSSL domain-only verification)

        * admin@domain.com
        * administrator@domain.com
        * hostmaster@domain.com
        * root@domain.com
        * ssladmin@domain.com
        * sysadmin@domain.com
        * webmaster@domain.com
        * info@domain.com
        * is@domain.com
        * it@domain.com
        * mis@domain.com
        * ssladministrator@domain.com
        * sslwebmaster@domain.com
        * postmaster@domain.com

However, some of these are being removed in the next update: ssladmin@, mis@ and others.

List to be truncated

[elronxenu]

Verisign just told me they're going to truncate the list of eligible email addresses down to a more manageable 6.