Certificate validation phishing

[tde...@gmail.com]

Some CA use the following protocol for certificates:

- A form ask for a CSR, your contact details (ex. YourName
contact@yourdomain ) and the contact details of the person that can
validate the website ownership (ex. admin@yourdomain), the email
constrained by (admin|administrator|hostmaster|webmaster|postmaster)@yourdomain
or the WHOIS contact infos.

- An email is sent to admin@yourdomain (for example) with the code to
validate the certificate:

> YourName contact@yourdomain asked a certificate
> Please use the following code [secret to validate the certificate ] to validate the request

- Once the code is submitted (click on a link, or a file to create, a
DNS entry to add, ...) an email is sent to contact@yourdomain (for
example) with the certificate.

I was wondering your thoughts about the following attack scenarios
against bigcorp.tld :

BadGuy create a CSR and fill the form with these informations:

- His CSR
- LegitEmployee legit_e...@bigcorp.tld as contact detail
- ad...@bigcorp.tld as validator detail
- (optionally, if bigcorp is lax with email security) sent an email to
ad...@bigcorp.tld with the sender spoofed as
legit_e...@bigcorp.tld explaining the need of a certificate

What happends next:
ad...@bigcorp.tld received the email from the CA:
> LegitEmployee legit_e...@bigcorp.tld asked a certificate
> Please use the following code [secret to validate the certificate ] to validate the request

The email is legit, what the email imply is "LegitEmployee
legit_e...@bigcorp.tld did the action", but the reality is
"someone claiming to be LegitEmployee legit_e...@bigcorp.tld did
the action", the CA never have validated these contact informations.

If the use behind ad...@bigcorp.tld falls in the trap, the certificate
is sent to legit_e...@bigcorp.tld but could also be submitted to
Certificate Transparency logs. BadGuy then has just to download it
from a CT log.

legit_employee@yourdomain could contact ad...@bigcorp.tld to warn him,
but if the certificate is created it's too late, as revocation is
badly broken.

Example of two real wording from two different CA:

First one:
> This order was placed by XXX whose phone number is XXX and whose email address is XXX

Second one:
> Applicant Information:
> Name: XXX
> Email: XXX
> Phone: XXX

Note: these tests were done with "Free trial certificates" valid for
less than 3 months.

Is it a valid/plausible attack scenario?

What could be improved ?

- The wording of the email for the CA, to emphasis that the sender
were NOT verified
- Authenticate the sender as well

In the long term:

- defined a new CAA flag "must-staple" that require that all generated
certificate must have the must-staple extension

[Lewis Resmond]

I don't understand all steps.
You say that ad...@bigcorp.tld receives a code (not an activation URL). So when he sends the code to his employee, how does the hacker get the code?

(Besides, most CAs limit the cofe validity to a few minutes, so this scenario is not likely to work many times)

About your long term solution:

- the idea about the flag is not bad. Maybe someone can write a RFC about it.

- but improving the revocation process doesn't solve the actual problem you mentioned (the insecure validation)

- since a lot of web servers don't support OCSP stapling, the CAs would make their customers very, very angry, if the purchased certificate doesn't work on their web server.

[Lewis Resmond]

The real solution would be a CAB/BR requirement forcing the CAs not to use the domain validation method XYZ, once it has been proven as vulnerable.

[tde...@gmail.com]

> I don't understand all steps. You say that ad...@bigcorp.tld receives
> a code (not an activation
> URL). So when he sends the code to his employee, how does the hacker
> get the code?

ad...@bigcorp.tld receive:
- (first CA) the code and an URL where he have to paste the code
- (second CA) an URL where he have click on a button

So it's more likely he does the validation himself than sending the code to the other employee.

> - but improving the revocation process doesn't solve the actual
problem you mentioned (the insecure validation)

When you are the target of an elaborate phishing, you often realize it too late, when the legitimate employee see the emails for example, so improving the revocation is important.

> - since a lot of web servers don't support OCSP stapling, the CAs
would make their customers very, very angry, if the purchased
certificate doesn't work on their web server.

Using a CAA is a decision of the customers, and the CA could emphasis that requirement during the validation process

[Nick Lamb]

On Sunday, 22 January 2017 10:09:26 UTC, Lewis Resmond wrote:
> The real solution would be a CAB/BR requirement forcing the CAs not to use the domain validation method XYZ, once it has been proven as vulnerable.

There are no doubt an unlimited number of vulnerable methods possible. Instead, and I would argue better, Ballot 169 explicitly listed all the acceptable means of validation.

However Ballot 169 revealed that several CA/B members have patents related to domain validation, and that woke a sleeping giant. The patented methods are in my opinion very weak sauce. They are to the ACME challenge validations what a plank of wood laid over a stream is to the Bay Bridge. However they probably reflect, more or less, the actual practice at major public CAs today.

Of course the CA/B says itself these are only Baseline Requirements, and Mozilla is free to insist members of its root programme do the moral equivalent of implementing Ballot 169 anyway, as Ryan has proposed in another thread.

[Santhan Raj]

If a domain administrator approves a request without checking why/who needs the cert, there is little a CA can do to mitigate such threats.

[tde...@gmail.com]

On Monday, January 23, 2017 at 10:34:42 AM UTC+1, Santhan Raj wrote:
> If a domain administrator approves a request without checking why/who needs the cert, there is little a CA can do to mitigate such threats.

I agree. But the CA could help prevent these threats.

And, in that specific case, the CA did facilitate that threat by stating a falsehood: The CA stated that a legitimate employee did requested the cert, when, in fact, the CA has no idea who requested it (If I'm not mistaken, in both my tests the CA did not validate the ownership of the email of the "employee" asking the certificate).

[Jeremy Rowley]

What do you mean they are weak sauce? Considering at least one of the
patents is claimed to cover the ACME challenge validations, they seem pretty
on-point.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Nick Lamb
Sent: Sunday, January 22, 2017 4:27 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Certificate validation phishing

On Sunday, 22 January 2017 10:09:26 UTC, Lewis Resmond wrote:

> The real solution would be a CAB/BR requirement forcing the CAs not to use
the domain validation method XYZ, once it has been proven as vulnerable.

There are no doubt an unlimited number of vulnerable methods possible.
Instead, and I would argue better, Ballot 169 explicitly listed all the
acceptable means of validation.

However Ballot 169 revealed that several CA/B members have patents related
to domain validation, and that woke a sleeping giant. The patented methods
are in my opinion very weak sauce. They are to the ACME challenge
validations what a plank of wood laid over a stream is to the Bay Bridge.
However they probably reflect, more or less, the actual practice at major
public CAs today.

Of course the CA/B says itself these are only Baseline Requirements, and
Mozilla is free to insist members of its root programme do the moral
equivalent of implementing Ballot 169 anyway, as Ryan has proposed in
another thread.

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Nick Lamb]

On Monday, 23 January 2017 18:07:59 UTC, Jeremy Rowley wrote:
> What do you mean they are weak sauce? Considering at least one of the
> patents is claimed to cover the ACME challenge validations, they seem pretty
> on-point.

I thought my comparison illustrated very well what I meant by weak sauce. People can _claim_ anything they want. Nothing I've seen in the patents comes close to achieving the desired confidence that the would-be subscriber is able to exert control over the FQDN to be validated.

[ The remainder of this post might feel like it's picking on GoDaddy. But actually all the patents are awful, they're just serving as an illustration ]

There are three ACME challenge validations in use today, two are already covered in Baseline Requirements document version 1.4.2. so that leaves only dns-01 which would be covered under the proposed 3.2.2.4.7 from Ballot 182 (and Ballot 169).

GoDaddy claims US9183368 is relevant to 3.2.2.4.7 but they have not, so far as I've seen, claimed that US9183368 actually impacts the ACME dns-01 challenge.

US9183368 is concerned with a "Pass String" which is analogous to the Random Value described in part of 3.2.2.4.7. The CA chooses a "Pass String", this is communicated somehow to the would-be subscriber, and then the CA checks whether it appears in a DNS TXT or CNAME record. That's it, validation done, That's what I mean by weak sauce. What did we validate? What are we sure about? Not very much.

ACME's dns-01 challenges can't use a Random Value approach, it would not achieve the confidence we want that the would-be subscriber and whoever is fiddling with DNS are one and the same. Fortunately 3.2.2.4.7 also offers the possibility of using a Request Token rather than a Random Value so ACME does this:

1. the CA picks a random string containing at least 128-bits of entropy and tells the ACME client

2. the ACME client uses its private key (the ACME account key, not the private half of the key for an X.509 certificate) to sign a data structure containing the random string called a "key authorization"

3. the ACME client puts a base-64 encoded SHA256 digest of the key authorization in a DNS TXT record [there's your Request Token]

4. the ACME client sends the whole key authorization back to the CA

5. the CA checks the DNS TXT record, verifies that there's a digest inside, that the digest matches the provided key authorization, that the key authorization is signed by the ACME account key, and that the authorization is for the random string it chose in step 1. Only if all these checks pass is the FQDN validated for this ACME account.

The "Pass String" idea is very simple, but it's wholly inferior in terms of the confidence that can be achieved.

In particular, the Pass String is subject to a trivial MITM. Anyone who can convince me to perform US9183368 based validation can use that to pass other DNS-based validations, whether US9183368 or something else. So maybe I thought I was validating my domain for a new advertising network, or a government scheme, but instead I just validated their control of my domain to a CA and they're getting a certificate issued.

Because the ACME approach uses public key crypto it can render a MITM ineffective. If Monika chooses to use her own ACME account key then she can't get the appropriate key authorization digest into the victim's DNS. If Monika instead lets the victim use their own ACME account keys, the digest will match up but Monika can't obtain a certificate because now the validation belongs to the victim.

[Jeremy Rowley]

And why wouldn't a request token fit the patent's interpretation of a "Pass
String"? The only definition I saw in the patent was something generated by
the validating entity and forwarded to the requester. The pass string can be
a code, but that does not necessarily preclude a request token.

"1. the CA picks a random string containing at least 128-bits of entropy and

tells the ACME client" = Pass String?

The rest is really an add on to the Pass String, but there it still looks
like Acme is using a Pass String.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Nick Lamb
Sent: Monday, January 23, 2017 3:42 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Certificate validation phishing

On Monday, 23 January 2017 18:07:59 UTC, Jeremy Rowley wrote:

> What do you mean they are weak sauce? Considering at least one of the
> patents is claimed to cover the ACME challenge validations, they seem
> pretty on-point.

[Nick Lamb]

On Tuesday, 24 January 2017 04:40:12 UTC, Jeremy Rowley wrote:
> And why wouldn't a request token fit the patent's interpretation of a "Pass
> String"? The only definition I saw in the patent was something generated by
> the validating entity and forwarded to the requester.

The digest of the key authorization, which I identified as the Request Token in the Baseline Requirements terminology is _not_ generated by the validating entity. They couldn't if they wanted to. Do you see why?

Even if you squint very hard indeed this digest isn't "the Pass String", but it is a Request Token because it binds this demonstration of control to this request, something a "Pass String" can't do.

That's absolutely key to understanding why this trick works. Such an understanding is completely absent from the patent, because the patent isn't describing what the Baseline Requirements call a Request Token but only a Random Value which it calls the "Pass String".

Whether a lawyer can be paid to pretend otherwise in a Western District of Texas specialist patent court remains to be seen. But meanwhile the plain truth is discernible to us non-lawyers.

[Gervase Markham]

On 24/01/17 09:08, Nick Lamb wrote:
> That's absolutely key to understanding why this trick works. Such an
> understanding is completely absent from the patent, because the
> patent isn't describing what the Baseline Requirements call a Request
> Token but only a Random Value which it calls the "Pass String".

No-one has actually come forward and said this to me, but I suspect that
doing patent analysis in this group will lead some members to be wary of
reading messages or participating, because of various effects that might
have on their "knowledge" of patents, which is relevant in patent law in
some jurisdictions.

While I would like this group to be a central meeting point for WebPKI
issues in general, can we please avoid patent analysis, at least without
saying first that you'd like to do some and explaining why it's
important for it to be done in this particular venue?

Thanks :-)

Gerv

[Jakob Bohm]

On 23/01/2017 23:41, Nick Lamb wrote:
> On Monday, 23 January 2017 18:07:59 UTC, Jeremy Rowley wrote:
>

> ... (Patent discussions, which Mr. Markham has since asked to stop)

>
> Because the ACME approach uses public key crypto it can render a MITM ineffective. If Monika chooses to use her own ACME account key then she can't get the appropriate key authorization digest into the victim's DNS. If Monika instead lets the victim use their own ACME account keys, the digest will match up but Monika can't obtain a certificate because now the validation belongs to the victim.

But if Monica simply sends a phishing mail to the victim claiming that
the token she computed (with her own key), pretending this to be a
value to be put in DNS/whateverelse for some convincing purpose,
then the cryptography has achieved nothing.

Note that the ACME challenge is not usually e-mailed to the victim
domain admin, so there is a lot less to make the victim organization
aware what is going on. Not sending e-mails to legitimate users is
necessary because of the need to facilitate automation with the short
certificate lifespans and other limitations of the Let's encrypt system.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Nick Lamb]

On Tuesday, 24 January 2017 16:50:33 UTC, Jakob Bohm wrote:
> But if Monica simply sends a phishing mail to the victim claiming that
> the token she computed (with her own key), pretending this to be a
> value to be put in DNS/whateverelse for some convincing purpose,
> then the cryptography has achieved nothing.

Yes, DNS administrators should always reject such things as potential social engineering attempts :)

Returning to the original topic of this thread, obviously we should discourage sysadmins [people receiving the BR-compliant domain validation email] from clicking on links in unsolicited email about certificates, but there's also some level of responsibility on the shoulders of the CA to have the sysadmin actually make a determination of whether this is a legitimate request, fulfilling their intended role in this system.

Our experience in the browser UI was that guessing doesn't work when it comes to security design. So it may be necessary to conduct experiments with ordinary people in a sysadmin role (ie certainly not m.d.s.policy participants, browser vendors, or CA employees) to find out what, if anything, you can write in the email that causes them to make that determination rather than just mechanically pushing the button.

Or the use of validation emails could go away. But I somehow don't think that's on the cards in the immediate future.