[antmldr]

>so I could see if anyone else had a domain with driverhub.asus.com.* registered. From looking at other websites certificate transparency logs, I could see that domains and subdomains would appear in the logs usually within a month. After a month of waiting I am happy to say that my test domain is the only website that fits the regex, meaning it is unlikely that this was being actively exploited prior to my reporting of it.

This only remains true in so far as no-one directly registered for a driverhub subdomain. Anyone with a wildcard could have exploited this, silent to certificate transparency?

[ZoneZealot]

A wildcard certificate is only for a single label level, '*.example.com.' would not allow 'test.test.example.com.', but would allow 'test.example.com.'. If someone issued a wildcard for '*.asus.com.example.com.', then could present a webserver under 'driverhub.asus.com.example.com.' and be seen as valid.

[throaway920181]

Yes... I believe you've successfully reworded what your comment's parent said.

[ZoneZealot]

Parent comment is making a point that it might have been possible for an attacker to avoid discovery via certificate transparency logs, because anyone 'with a wildcard' could pull off the attack, which is not correct.

I'm pointing out that a wildcard at the apex of your domain (which is what basically everyone means when saying 'a wildcard'), would not work for this attack. Instead if you were to perform the attack using a wildcard certificate, it would need to be issued for '*.asus.com.example.com.' - which would certainly be obvious in certificate transparency logs.

[smileybarry]

Can you still publicly apply for a “*.*.mydomain.com” certificate? IIRC a wildcard cert starting with “*.*.” allows you to chain 2+ names with that cert, I think? (E.g.: “*.*.example.com” cert would match “hello.world.and.hi.com.example.com”)

[ZoneZealot]

With public CAs, you can only apply for a wildcard at a single label. You can't have nested wildcards.

RFC6125 limits wildcards to a left-most label (6.4.3. paragraph 2): https://www.rfc-editor.org/rfc/rfc6125.html#section-6.4.3

I don't know of any CA that allows for wildcard characters within the label, other than when the whole label is a wildcard, but it is possible under that RFC.

The CA/Browser Forum's baseline requirements dictates how any publicly trusted CA should operate, and it defines a wildcard certificate in section 1.6.1 (page 26) here https://cabforum.org/working-groups/server/baseline-requirem...

> Wildcard Certificate: A Certificate containing at least one Wildcard Domain Name in the Subject Alternative Names in the Certificate.

> Wildcard Domain Name: A string starting with “*.” (U+002A ASTERISK, U+002E FULL STOP) immediately followed by a Fully‐Qualified Domain Name.

Now of course with your own internal CA, you have complete free reign to issue certificates - as long as they comply with the technical requirements of your software (i.e. webserver and client).

Also note that a cert issued as '..example.com.' would only match 'hi.com.example.com.', not an additional three labels.

[a2128]

I think the point is that it wouldn't be silent to certificate transparency, because having a certificate for *.asus.com.example.com would be a clear indication of something suspicious

[MrBruh]

Nice idea, just checked it now and can confirm there was nothing suspicious in the wildcard records.

[ethan_smith]

You're right about the wildcard certificate blind spot. An attacker with a wildcard cert for .example.com could have exploited this without appearing in CT logs specifically for driverhub.asus.com. domains. This is why CT log monitoring alone isn't sufficient for detecting these types of subdomain takeover vulnerabilities.

[ZoneZealot]

It's 'driverhub.asus.com.example.com.' not 'driverhub.example.com.', therefore entirely discoverable in CT logs by searching for (regex): (driverhub|\*)\.asus\.com\.

[kstrauser]

Furthermore:

- Would a self-signed cert work? Those aren’t in transparency logs.

- Does it have to be HTTPS?