Live data from Hacker News

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

labs.watchtowr.com

81–90 of 391 posts

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

#81

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.

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.

The point is that, ironically, new standards may have been a better option.

Bolting on extensions to existing protocols not designed to be secure, while improving the situation, has been so far unable to address all of the security concerns leaving major gaps. It's just a fact.

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

#83
post #80
post #57

Earlier quoted context omitted.

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

> every picture you'll ever take with your phone would be considered semi-public as phones are Internet connected

Correct.

https://en.wikipedia.org/wiki/2014_celebrity_nude_photo_leak

https://www.cybersecurity-insiders.com/glitch-makes-data-fro...

https://arstechnica.com/gadgets/2023/09/apple-patches-clickl...

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

#84
post #65

Earlier quoted context omitted.

This sort of all-or-nothing thinking isn't helpful. DNS points you to a server, TLS certificates help you trust that you've arrived at the right place. It's not perfect, but we build very trustworthy systems on this foundation.

But DNS is all-or-nothing. If you can't trust DNS, you can't trust TLS or anything downstream of it. Even banks are not bothering with EV certificates any more, since browsers removed the indicator (for probably-good reasons). DV certificate issuance depends on trustworthy DNS. Internet security is "good enough" for consumers, most of the time. That's "adequately trustworthy", but it's not "very trustworthy".

Bank websites like chase.com and hsbc.com and web services like google.com, amazon.com, and amazonaws.com intentionally avoid DNSSEC. I wouldn't consider those sites less than "very trustworthy" but my point is that "adequately trustworthy" is the goal. All-or-nothing thinking isn't how we build and secure systems.

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

#85

Earlier quoted context omitted.

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.

BGP hijacks unfortunately completely destroy that. RPKI is still extremely immature (despite what companies say) and it is still trivial to BGP hijack if you know what you're doing. If you are able to announce a more specific prefix (highly likely unless the target has a strong security competency and their own network), you will receive 100% of the traffic.

At that point, it doesn't matter how many vantage points you verify from: all traffic goes to your hijack. It only takes a few seconds for you to verify a certificate, and then you can drop your BGP hijack and pretend nothing happened.

Thankfully there are initiatives to detect and alert BGP hijacks, but again, if your organization does not have a strong security competency, you have no knowledge to prevent nor even know about these attacks.

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

#86
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.

100% - another for the BGP hijack!

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

#87

Earlier quoted context omitted.

> Our industry needs to finish what it starts. "Our industry" is a pile of snakes that abhor the idea of collaboration on common technologies they don't get to extract rents from. ofc things are they way they are.

Let's not fool ourselves by saying we're purely profit driven. Our industry argues about code style (:

Our industry does not argue about code style. There were a few distinct subcultures which were appropriated by the industry who used to argue about code style, lisp-1 vs lisp-2, vim vs emacs, amiga vs apple, single pass vs multi pass compilers, Masters of Deception vs Legion of Doom and the list goes on, depending on the subculture.

The industry is profit driven.

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

#88

Earlier quoted context omitted.

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 (^:

I would say that TLS/SSL doesn't depend on Internet PKI - browsers (etc) depend on Internet PKI in combination with TLS/SSL.

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

#89
post #67

Earlier quoted context omitted.

The fact PHP is used for any critical web infrastructure is concerning. I used PHP professionally years ago and don't think it's that awful but certainly not something I'd consider for important systems.

Wouldn't "eval" in any language result in RCE? Isn't that the point of eval, to execute the given string command?

Fully compiled languages don't even have an eval at all.

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

#90

Earlier quoted context omitted.

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 f…

Ok. You added OEMs to the list, but then just named the same three dominant players as clouds. Last I checked, every device on the planet supports IPv6, if not those other protocols. Everything from the cheapest home WiFi router, to every Layer 3 switch sold in the last 20-years.

I think this is a 20-year old argument, and it’s largely irrelevant in 2024.

Post reply on HN