Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

labs.watchtowr.com

Post reply on HN
Print view View original

71–80 of 391 posts

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

#71

Post by rty32 »

hansjorg wrote: post #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...

The reality of life is that there are way more hardcoded strings than you imagine or there should be.

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

#72

Post by mschuster91 »

iscoelho wrote: post #36
mschuster91 wrote: post #34

Earlier quoted context omitted.

> Like someone at your work had all these great ideas, started implementing them, then quit when they realized it would be too difficult to complete. The problem is, in many of these fields actual real-world politics come into play - you got governments not wanting to lose the capability to do DNS censorship or other forms of sabotage, you got piss poor countries barely managing to keep the faintest of lights on, you…

Considering we have 3 major tech companies (Microsoft/Apple/Google) controlling 90+% of user devices and browsers, I believe this is more solvable than we'd like to admit.

Browsers are just one tiny piece of the fossilization issue. We got countless vendors of networking gear, we got clouds (just how many AWS, Azure and GCP services are capable of running IPv6 only, or how many of these clouds can actually run IPv6 dual-stack in production grade?), we got even more vendors of interception middlebox gear (from reverse proxies and load balancers, SSL breaker proxies over virus scanners for web and mail to captive portal boxes for public wifi networks), we got a shitload of phone telco gear of which probably a lot has long since expired maintenance and is barely chugging along.

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

#73

Post by 8organicbits »

iscoelho wrote: post #50
8organicbits wrote: post #48

Earlier quoted context omitted.

Tainted seems a little strong, but I think you're right, there's nothing in the CAB Baseline Requirements [1] that requires DNSSEC use by CAs. I wouldn't push for DNSSEC to be required, though, as it's been so sparsely adopted. Any security benefit would be marginal. Second level domain usage has been decreasing (both in percentage and absolute number) since min-2023 [2]. We need to look past DNSSEC. [1] https://cabf…

I agree that DNSSEC is not the answer and has not lived up to expectations whatsoever, but what else is there to verify ownership of a domain? Email- broken. WHOIS- broken. Let's convince all registrars to implement a new standard? ouch.

I'm a fan of the existing standards for DNS (§3.2.2.4.7) and IP address (§3.2.2.4.8) verification. These use multiple network perspectives as a way of reducing risk of network-level attacks. Paired with certificate transparency (and monitoring services). It's not perfect, but that isn't the goal.

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

#74

Post by iscoelho »

NovemberWhiskey wrote: post #61
iscoelho wrote: 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…

None of these relate to TLS/SSL - that's the wrong level of abstraction: they relate to fragility of the roots of trust on which the registration authorities for Internet PKI depend.

As long as TLS/SSL depends on Internet PKI as it is, it is flawed. I guess there's always Private PKI, but that's if you're not interested in the internet (^:

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

#75

Post by Dylan16807 »

iscoelho wrote: post #32
candiddevmike wrote: post #28

Earlier quoted context omitted.

Our industry needs to finish what it starts. Between IPv6, DNSSEC, SMTP TLS, SCTP/QUIC, etc all of these bedrock technologies feel like they're permanently stuck in a half completed implementation/migration. Like someone at your work had all these great ideas, started implementing them, then quit when they realized it would be too difficult to complete.

obligatory https://xkcd.com/927/ Honestly: we're in this situation because we keep trying to band-aid solutions onto ancient protocols that were never designed to be secure. (I'm talking about you DNS.) Given xkcd's wisdom though, I'm not sure if this is easily solvable.

Can we all agree to not link that comic when nobody is suggesting a new standard, or when the list of existing standards is zero to two long? It's not obligatory to link it just because the word "standard" showed up.

I think that covers everything in that list. For example, trying to go from IPv4 to IPv6 is a totally different kind of problem from the one in the comic.

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

#76

Post by tetha »

devvvvvvv wrote: post #21
DexesTTP wrote: post #20

Earlier quoted context omitted.

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…

Thank you for clarifying. That is indeed much more worrying. If we were able to guarantee NO certificate authorities used WHOIS, this vector would be cut off right? And is there not a way to, as a website visitor, tell who the certificate is from and reject/distrust ones from certain providers, e.g. Digicert? Edit: not sure if there's an extension for this, but seems to have been done before at browser level by Chrom…

CAA records may help, depending on how the attacker uses the certificate. A CAA record allows you to instruct the browser that all certs for "*.tetha.example" should be signed by Lets Encrypt. Then - in theory - your browser could throw an alert if it encounters a DigiCert cert for "fun.tetha.example".

However, this depends strongly on how the attacker uses the cert. If they hijack your DNS to ensure "fun.tetha.example" goes to a record they control, they can also drop or modify the CAA record.

And sure, you could try to prevent that with long TTLs for the CAA record, but then the admin part of my head wonders: But what if you have to change cert providers really quickly? That could end up a mess.

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

#77

Post by account42 »

iscoelho wrote: 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…

> 1. WHOIS isn't encrypted or signed, but is somehow suitable for verification (?)

HTTP-based ACME verification also uses unencrypted port-80 HTTP. Similar for DNS-based verification.

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

#78

Post by acdha »

worthless-trash wrote: post #16
pimlottc wrote: post #4

As a reminder, RCE = remote code execution (it’s not defined in the article). https://www.cloudflare.com/learning/security/what-is-remote-...

These days people use "RCE" for local code execution.

I would clarify that as running code somewhere you don’t already control. The classic approach would be a malformed request letting them run code on someone else’s server, but this other pull-based approach also qualifies since it’s running code on a stranger’s computer.

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

#79

Post by iscoelho »

goodpoint wrote: post #63
iscoelho wrote: post #32

Earlier quoted context omitted.

obligatory https://xkcd.com/927/ Honestly: we're in this situation because we keep trying to band-aid solutions onto ancient protocols that were never designed to be secure. (I'm talking about you DNS.) Given xkcd's wisdom though, I'm not sure if this is easily solvable.

Standards evolve for good reasons. That's just a comic.

The comic is about re-inventing the wheel. What you propose "standards evolving" would be the opposite in spirit (and is what has happened with DNSSEC, RPKI, etc)

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

#80

Post by ffsm8 »

coldpie wrote: post #57
sebstefan wrote: post #8

>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

As has been demonstrated many, many (many, many (many many many many many...)) times: there is no such thing as computer security. If you have data on a computer that is connected to the Internet, you should consider that data semi-public. If you put data on someone else's computer, you should consider that data fully public. Our computer security analogies are modeled around securing a home from burglars, but the ac…

by this logic, every picture you'll ever take with your phone would be considered semi-public as phones are Internet connected.

While I wouldn't have too much of an issue with that, I'm pretty sure I'm a minority with that

Post reply on HN