Sources of Domain Contact Information?

[Tyrel]

Folks,

I'm sure some of you have already seen this writeup:

https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/

The authors claim that several certificate authorities, for at least one TLD (.mobi), query WHOIS servers that are no longer authoritative for a TLD, and in fact by registering the old WHOIS server name to themselves, they were able to provide any information they wanted about domain contacts, e.g. substituting their own email address for validation method 3.2.2.4.2 for any (.mobi) domain. They also mention that they observed some clients (not necessarily CAs) querying the out of date WHOIS location for domains like "google.com".

The one CA called out by name in the report has opened a bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1917896

But my question for other CAs is: from where do you source information on authoritative WHOIS servers for TLDs? What processes do you have in place to ensure that updates to, e.g., the IANA list, are propagated to production systems?

My question to the community: given the apparent fragility of WHOIS for obtaining registrant info, should the BRs be updated to only allow, e.g., direct information from RDAP from the registrar in charge of a given TLD?

[Claves Nostrum]

I believe this will be a wider issue since in previous discussions it was referenced that CA's typically use tools / ports like linux whois, which also has a wrong reference for e.g. .mobi in its TLD config file:

IANA says the whois server for whois.nic.mobi (https://www.iana.org/domains/root/db/mobi.html)

whois cmd util uses whois.afilias.net as the whois server for .mobi (https://github.com/rfc1036/whois/blob/dc588f10ee8135e17b3a1b6934583476bcb67bed/tld_serv_list#L64)

Although whois.afilias.net has the same DNS A records as whois.nic.mobi it cannot be presumed it stays that way as the TLD operator might remove / decommission the unofficial one and then we might have another example of https://bugzilla.mozilla.org/show_bug.cgi?id=1917896

I believe any CA that does not, as Tyrel references, "ensure that updates to, e.g., the IANA list, are propagated to production systems" might be affected by the same vulnerability. 

Op woensdag 11 september 2024 om 21:48:54 UTC+9 schreef Tyrel:

[Amir Omidi]

It might be time that we discussed what we are getting out of relying on WHOIS for this information with the improvements we've had into other forms of DCV. This recent attack has highlighted two things for me:

1. It's probably time to pull the plug on relying on WHOIS information for DCV.
2. For CAs that don't have publicly accessible endpoints for doing domain validation (practically every CA except a handful), it might be useful to expose an endpoint that goes through the full DCV cycle and signs with a non-trusted key.

For #2, it's important for security researchers to be able to test DCV logic for CAs that get granted the ability to issue publicly trusted certificates. Essentially this endpoint would allow the public, and the root programs to regularly audit any CA's DCV.

It is my opinion that this requirement should be added for new organizations wanting to be a CA. Existing CAs should be required to implement this by some future date.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/72b25d8e-ab8a-4244-8b53-8422759e0b4fn%40mozilla.org.

[Watson Ladd]

I support this endpoint idea. I'd also like to know if we can gather
information about little used DCV methods, to inform the conversation
about risks. Personally I think DNS change and HTTP validation are
probably the only methods we really need, but people should be
encouraged to come up with better ones!

Sincerely,
Watson

On Wed, Sep 11, 2024 at 8:10 AM 'Amir Omidi' via
dev-secur...@mozilla.org <dev-secur...@mozilla.org>
wrote:

> To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAOG%3DJUJZdS9dfecUEUYRvQmv1JOF8iOAf27AOS9QbNp6mKDfOQ%40mail.gmail.com.



--
Astra mortemque praestare gradatim

[Hanno Böck]

Hi,

On Wed, 11 Sep 2024 06:53:28 -0700 (PDT)
Claves Nostrum <claves...@gmail.com> wrote:

> IANA says the whois server for whois.nic.mobi
> (https://www.iana.org/domains/root/db/mobi.html)
>
> whois cmd util uses whois.afilias.net as the whois server for .mobi
> (https://github.com/rfc1036/whois/blob/dc588f10ee8135e17b3a1b6934583476bcb67bed/tld_serv_list#L64)

Related PR:
https://github.com/rfc1036/whois/pull/176

It appears there are more such problems:
https://github.com/rfc1036/whois/issues/177
"whois2.afilias-grs.net (the server for two TLDs) no longer exists, the
domain is owned by some kinda sketchy parking service"

https://github.com/rfc1036/whois/issues/179
"Server for .bz is whois.afilias-grs.info associated with old 'Afilias'
name, might need updating"

This one looks particularly concerning, because it indicates the data
on the IANA database is oudated/incorrect:
https://github.com/rfc1036/whois/pull/178


It appears to me that this is an extremely problematic situation.
Existing whois tools hardcode whois servers, and the data is updated
manually.
That could be "fixed" by requiring CAs to make sure they use updated
data.

But there's a larger question whether there even is a reliable "source
of truth" for whois servers. Does IANA make any guarantees that the
whois servers they advertise are operational, and under control of the
respective TLD authority?

IMHO if there is no satisfying answer to these questions, whois data
should no longer be allowed as a domain validation mechanism.

--
Hanno Böck
https://hboeck.de/

[Amir Omidi]

I second the call to remove WHOIS based DCV as well. This report has likely created copycat attacks. 

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240912092107.1091b356.hanno%40hboeck.de.

[Hanno Böck]

On Thu, 12 Sep 2024 09:21:07 +0200
Hanno Böck <ha...@hboeck.de> wrote:

> But there's a larger question whether there even is a reliable "source
> of truth" for whois servers. Does IANA make any guarantees that the
> whois servers they advertise are operational, and under control of the
> respective TLD authority?

To answer myself: It appears multiple whois servers listed by IANA are
not operational.
This is true for the following TLDs:
cf ci dz ec gn gp hm iq ml na sb tk to uy xn--lgbbat1ad8j xn--mgbtx2b
xn--ygbi2ammx

It therefore strongly appears to me that there is currently no reliable
data source for whois servers, and therefore, it is unclear how domain
validation via whois can be implemented securely.

--
Hanno Böck - Independent security researcher
https://itsec.hboeck.de/
https://badkeys.info/

[Claves Nostrum]

I am a bit surprised that we have not seen anything from other CA on this, Bugzilla's or comments on this discussion, surely others must be affected to some extent, which would imply they need to audit whois-issuances for TLD's with ""questionable" or invalid whois servers configured in their lookup tooling. 

Op donderdag 12 september 2024 om 10:25:03 UTC+2 schreef Hanno Böck:

[Mike Shaver]

They would need to do so in a historically accurate way too, to make sure that they didn’t validate via Whois during a window where the info was incorrect, even if it’s correct now. Could be pretty awkward!

Mike

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f1847027-e1c0-410e-91ab-250cd62cb32an%40mozilla.org.

[Roman Fischer]

Dear Claves,

 

Maybe many CAs (like SwissSign) are not using WHOIS anymore and thus don't reply to this thread. 😉

 

Rgds
Roman

--

[Wayne]

Perhaps the many CAs who are not using WHOIS would be able to help. If they were impacted, when would they feel a clock should start for reporting these incidents? Both infrastructure-impact, and potential misuse of certificates as an ongoing scope of unaudited TLDs is being elaborated upon.

So far I'm not seeing a reason for relying on the non-authoritative information within WHOIS to provide strong identity verification. Given there are CAs still believing it to be authoritative, could they elaborate on why?

- Wayne