1723263 - Sectigo: IP Address Domain Validation Failure

Status: RESOLVED INVALID

(CA Program :: CA Certificate Compliance, task)

Description

[Charles Wang]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36

Steps to reproduce:

Hijacked the IP prefix(BGP Announcement) and attmpt to apply a Sectigo DV IP certificates,then add the validation value.

Actual results:

Sectigo issued certificates to the hijacked IP prefixes.
Related Mis-issued Certificates:
https://crt.sh/?id=4725920782
https://crt.sh/?id=4725920708
https://crt.sh/?id=4725910704
https://crt.sh/?id=4725910685
https://crt.sh/?id=4725910685
https://crt.sh/?id=4725889467
https://crt.sh/?id=4725859168
https://crt.sh/?id=4725858971
https://crt.sh/?id=4725842909
https://crt.sh/?id=4725842940
(None of these test certificates are deployed)

Expected results:

These tested IPs are owned by China Telecom and used for router/backbone/exchange usage.
From this case,we can see anyone is possible to hijack an IP prefix with BGP announcement and pass DCV without the ownership of the ip addresses.
Advice:
Change the guideline to force verifying RPKI (https://datatracker.ietf.org/doc/html/rfc6480) before issuance of IP certificates.

Comment 1

[Charles Wang]

Update:
Upon further investigation,we tried to test more IP addresses and successfully issued certificates.
We conclude hackers only need to hijack an IP prefix for minutes to their fake server to pass the domain control validation and
then remove the hijacking announcement,it could be really hard to be discovered by the owner of the IP address in certain circumstances.
I’m actively digging deeper with my colleagues and will come back with more convincing evidence and solutions regarding this case.

Comment 2

[Ryan Sleevi]

Charles: Thanks for reporting this, but it's unclear to me that this is an issue with Sectigo, per-se.

BGP hijacking applies equally to IP address validation or DNS validation. That is, one can bypass DNS validation by doing BGP hijacking of the resolved IP for a given domain (e.g. google.com) between the CA and the authoritative AS, and use that to perform a domain validation control.

To some extent, this is nominally mitigated by CAA records on google.com, except again, an attacker able to leverage a BGP hijack can equally hijack the NS servers for google.com and omit the CAA record (or insert any other record for purposes of domain validation or control).

In short, TLS cannot and does not provide any guarantees against BGP hijacks, and never has. It's certainly true that route validation is useful here, but obviously that requires multiple parties to opt-in, from the path of the originator of the routing information to the consumer of the routing information.

So I'm not sure what's new or unique here, either with respect to IP address validation (since this applies to DNS) or to Sectigo in particular.

Certainly, if you're performing BGP hijacks on entities you don't control/operate, that would almost certainly be a violation of internet norms and very likely regional specific laws, and so would want to discourage you from doing this again, consistent with https://www.mozilla.org/en-US/security/bug-bounty/

Comment 3

[Andrew Ayer]

Per Mozilla Root Store Policy 2.2(4):

For a certificate capable of being used for SSL-enabled servers, the CA must ensure that the applicant has control over all IP Address(es) referenced in the certificate.

The applicant does not need to have "ownership" over the IP addresses, and it seems from Comment 0 that you did have control over the IP addresses (albeit improperly) at time of issuance.

Did you report these certificates to Sectigo's problem reporting address? If so, did Sectigo revoke the certificates within 24 hours as required by BR 4.9.9.1? If so, I don't think this is a compliance incident.

Comment 4

[Charles Wang]

Andrew Ayer
I agree this is not a single issue Sectigo has and not a security incident,I posted this to start the discussion about how we can preventing mis-issuance from BGP hijacking.

Ryan
Thank you for your response,I still think there is a potential that certificates can be mis-issued when hackers performs BGP hijacking,according to a report,there are thousands BGP hijacking incidents happens per year,so I think this should be prevented. At least for IP certificates.

Comment 5

[Charles Wang]

Regarding the CAA @Ryan mentioned,I agree it works for domain names,but IP addresses not.So i think more limits should be carried out.

Comment 6

[Ryan Sleevi]

Charles: As I explained, CAA does not work around this.

To be explicit: TLS does not defend against BGP hijacking, either for DNS addresses or IP addresses.

I'm closing this issue as Resolved/Invalid, because this is known and within the threat model for TLS; namely, both BGP hijacking and DNS hijacking (e.g. hostile registrar transfer) are not things TLS defends against. THat's not to say they aren't important risks, and we should hope to see mitigations (e.g. RPKI implemented at more networks), but CAs are built on the threat models of BGP and DNS.

For general discussion, we encourage folks to start threads at https://groups.google.com/a/mozilla.org/g/dev-security-policy , rather than file CA issues, especially if it's not actually a CA incident.