GoDaddy verification issue history appears incomplete: possible regression of bug in 2010

[Fred Emmott]

Reported earlier this week as https://bugzilla.mozilla.org/show_bug.cgi?id=1330482 <https://bugzilla.mozilla.org/show_bug.cgi?id=1330482> - posting to list per request on that bug:

In January 2010, I reported two issues to GoDaddy, with an example certificate that should have been rejected:
- their website-based authentication required a request to an URL including a random string to include the same random string. A 200 was not required, but even with a 200 requirement, this would have not have been secure for many common website configurations; this appears to be at least extremely similar to the current issue
- their DNS-based authentication required random subdomain to exist as a CNAME record - but the target was not specified. This meant that anyone could get a certificate for any domain that had a wildcard CNAME (e.g. ‘* CNAME @‘ is particularly common).

GoDaddy fixed these in September 2010. I am posting as I believe that GoDaddy should have invested in automated testing for these issues as a best practice (even if not required by industry agreements at the time) and any other verification failures that have been reported to them without publication.

I do not appear to still have access to my original GoDaddy tickets; timeline and details from my notes are below (CNAME incident first):

The new incorrect issuance with non-200 responses appears to be the same as one of two issues I reported (and was fixed) in 2010:

I reported two issues to GoDaddy back in 2010 (included after timeline) - the second one appears to be the same bug as the new incident being discussed at https://groups.google.com/forum/?hl=en#!msg/mozilla.dev.security.policy/Htujoyq-pO8/uRBcS2TmBQAJ <https://groups.google.com/forum/?hl=en#!msg/mozilla.dev.security.policy/Htujoyq-pO8/uRBcS2TmBQAJ> - timeline:

2010-01-09: I wanted an SSL certificate for my domain; I read GoDaddy’s instructions, and realized that my existing configuration probably matched their requirements. I got my SSL certificate with no changes to my DNS or website.

2010-01-10: Notification sent to godaddy (Incident ID 8143623)

2010-01-20: Second notification sent to godaddy (Incident ID 8214596)

2010-01-21: Confirmed the flaw still exists - I got go daddy to issue me a certificate for a friend’s domain (consent
given, but no cooperation)

2010-08-26: Reported again - had not yet received a response - (id 9711250)

2010-09-03: Phone call with Todd Redfoot (Chief information security officer)
2010-09-23: Email from Todd Redfoot confirming fix deployed

My report from 2010 is below - the first one is no longer valid given the switch to TXT-records for authentication.

----- 1. CNAME verification ——

In short: if a domain had a wildcard CNAME, anyone could get a certificate for that domain from GoDaddy.

I have tested this approach, and got a godaddy signed certificate with consent
but not cooperation (and godaddy not being informed of consent).

1. Find a domain which appears to have a wildcard CNAME record (i.e. "dig
somegarbage.example.com" returns any CNAME record)

2. Ask for permission from the owner (optional if blackhat….)

3. Create a CSR for the domain

4. Sign up for a godaddy domain verified certificate (referred to on the site by
a mixture of "Standard SSL" or "Turbo SSL" - same product)

5. Submit your CSR

6. Godaddy will attempt some verification via whois; wait a few hours for this
to fail. They will email to let you know when this happens

7. Sign in to the web panel, and select "domain-based verification"

8. It will immediately confirm that verification was successful

9. In a few minutes, you can download a certificate for the domain

Godaddy's DNS verification is as follows:
- Create a random code
- Require you to make it so that randomcode.yourdomain.com returns a CNAME
record
- The value of the CNAME record is irrelevant and not specified

So, you can get a domain-verified SSL certificate for a domain with anything
like any of the following in the zonefile:

* CNAME @
* CNAME example.com
* CNAME pleasedontsignacertificatebasedonthis.com

----- 2. Web-based verification ------

Instructions as above, except:

1. Find a domain where a not-found page returns a page including the URL
requested. I'd assume that the site must also be misconfigured to return a 200
response instead of 404, but this is a fairly common misconfiguration.

7. Select web-based verification

Similar cause; godaddy require that http://example.com/godaddyRandomCode <http://example.com/godaddyRandomCode>
returns a page including godaddyRandomCode

Regards,
- Fred

[Gervase Markham]

On 13/01/17 17:10, Fred Emmott wrote:
> In January 2010, I reported two issues to GoDaddy, with an example
> certificate that should have been rejected: - their website-based
> authentication required a request to an URL including a random string
> to include the same random string.

Reading through your bug report, it does seem like the problem you
encountered was very similar to that recently reported. Perhaps Wayne
would care to comment?

While there are no audits for the QA process of a CA, domain validation
is the /sine qua non/ of certificate issuance and I would hope and
expect all CAs to have robust testing processes surrounding any changes
to this part of their issuance infrastructure, both testing that
certificates are issued for domains they should be, and that they are
not issued for domains that they should not be, under an adversarial
threat model.

Gerv

[Wayne Thayer]

Back in 2010 all of our testing was manual. We've been investing in automated testing over the last three years. Now we are focusing that effort on the new Ballot 169 methods with a heightened awareness of false positives like this one, and detection of potential vulnerabilities.

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

[Jakob Bohm]

Really? You were doing manual testing that quickly? Using the kind of
randomized challenging normal associated with automated testing?

On 17/01/2017 04:48, Wayne Thayer wrote:
> Back in 2010 all of our testing was manual. We've been investing in automated testing over the last three years. Now we are focusing that effort on the new Ballot 169 methods with a heightened awareness of false positives like this one, and detection of potential vulnerabilities.
>
>> -----Original Message-----
>> From: dev-security-policy [mailto:dev-security-policy-
>> bounces+wthayer=godad...@lists.mozilla.org] On Behalf Of Gervase
>> Markham
>> Sent: Monday, January 16, 2017 3:49 AM
>> To: mozilla-dev-s...@lists.mozilla.org
>> Subject: Re: GoDaddy verification issue history appears incomplete: possible
>> regression of bug in 2010
>>
>> On 13/01/17 17:10, Fred Emmott wrote:
>>> In January 2010, I reported two issues to GoDaddy, with an example
>>> certificate that should have been rejected: - their website-based
>>> authentication required a request to an URL including a random string
>>> to include the same random string.
>>
>> Reading through your bug report, it does seem like the problem you
>> encountered was very similar to that recently reported. Perhaps Wayne
>> would care to comment?
>>
>> While there are no audits for the QA process of a CA, domain validation is the
>> /sine qua non/ of certificate issuance and I would hope and expect all CAs to
>> have robust testing processes surrounding any changes to this part of their
>> issuance infrastructure, both testing that certificates are issued for domains
>> they should be, and that they are not issued for domains that they should
>> not be, under an adversarial threat model.
>>

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

[Wayne Thayer]

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+wthayer=godad...@lists.mozilla.org] On Behalf Of Jakob
> Bohm
> Sent: Tuesday, January 17, 2017 9:25 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: GoDaddy verification issue history appears incomplete: possible
> regression of bug in 2010
>

> Really? You were doing manual testing that quickly? Using the kind of
> randomized challenging normal associated with automated testing?
>

Jakob - I was referring to QA testing. The actual validation of the random code has always been automated.