Live data from Hacker News

We spent $20 to achieve RCE and accidentally became the admins of .mobi

labs.watchtowr.com

11–20 of 391 posts

Re: We spent $20 to achieve RCE and accidentally became the admins of .mobi

#11
post #3

Great write-up - the tip of the iceberg on how fragile TLS/SSL is. Let's add a few: 1. WHOIS isn't encrypted or signed, but is somehow suitable for verification (?) 2. DNS CAA records aren't protected by DNSSEC, as absence of a DNS record isn't sign-able (correction: NSEC is an optional DNSSEC extension) 3. DNS root & TLD servers are poorly protected against BGP hijacks (adding that DNSSEC is optional for CAs to veri…

> 2. DNS CAA records aren't protected by DNSSEC, as absence of a DNS record isn't sign-able. NSEC does this. > An NSEC record can be used to say: “there are no subdomains between subdomains X and subdomain Y.

You're correct - noting that Lets Encrypt supports DNSSEC/NSEC fully.

Unfortunately though, the entire PKI ecosystem is tainted if other CAs do not share the same security posture.

Re: We spent $20 to achieve RCE and accidentally became the admins of .mobi

#13

>The first bug that our retrospective found was CVE-2015-5243. This is a monster of a bug, in which the prolific phpWhois library simply executes data obtained from the WHOIS server via the PHP ‘eval’ function, allowing instant RCE from any malicious WHOIS server. I don't want to live on this planet anymore

Always look on the bright side of Life.

The non-sensicalness of it is just a phase. Remember the Tower of Babel didn't stop humanity.

Here is a link that was posted a few days ago regarding how great things are compared to 200 years ago. Ice cream has only become a common experience in the last 200 years..

https://ourworldindata.org/a-history-of-global-living-condit...

Re: We spent $20 to achieve RCE and accidentally became the admins of .mobi

#15

>The first bug that our retrospective found was CVE-2015-5243. This is a monster of a bug, in which the prolific phpWhois library simply executes data obtained from the WHOIS server via the PHP ‘eval’ function, allowing instant RCE from any malicious WHOIS server. I don't want to live on this planet anymore

that seems like a bigger lift than just deciding to help fix the bug

“be the change” or some such

Re: We spent $20 to achieve RCE and accidentally became the admins of .mobi

#18

>The first bug that our retrospective found was CVE-2015-5243. This is a monster of a bug, in which the prolific phpWhois library simply executes data obtained from the WHOIS server via the PHP ‘eval’ function, allowing instant RCE from any malicious WHOIS server. I don't want to live on this planet anymore

The fact they're using `eval()` to execute variable assignment... They could've just used the WTF-feature in PHP with double dollar signs. $$var = $itm; would've been equivalent to their eval statement, but with less code and no RCE.

Re: We spent $20 to achieve RCE and accidentally became the admins of .mobi

#19
Why are tools using hardcoded lists of WHOIS servers?

Seems there is a standard (?) way of registering this in DNS, but just from a quick test, a lot of TLDs are missing a record. Working example:

    dig _nicname._tcp.fr SRV +noall +answer

    _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr.
Edit:

There's an expired Internet Draft for this: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...

Re: We spent $20 to achieve RCE and accidentally became the admins of .mobi

#20

Entertaining and informative read. Main takeaways for me from an end user POV: - Be inherently less trustworthy of more unique TLDs where this kind of takeover seems more likely due to less care being taken during any switchover. - Don't use any "TLS/SSL Certificate Authorities/resellers that support WHOIS-based ownership verification."

None of these are true for the MitM threat model that caused this whole investigation:

- If someone manages to MitM the communication between e.g. Digicert and the .com WHOIS server, then they can get a signed certificate from Digicert for the domain they want

- Whether you yourself used LE, Digicert or another provider doesn't have an impact, the attacker can still create such a certificate.

This is pretty worrying since as an end user you control none of these things.

Post reply on HN