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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
