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

251–260 of 391 posts

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

#251

Post by defen »

Andrew_nenakhov wrote: post #243
varun_ch wrote: post #199

Earlier quoted context omitted.

I can think of two reasons: 1. it's immediately clear to users that they're seeing content that doesn't belong to your business but instead belongs to your business's users. maybe less relevant for github, but imagine if someone uploaded something phishing-y and it was visible on a page with a url like google.com/uploads/asdf. 2. if a user uploaded something like an html file, you wouldn't want it to be able to run j…

Wouldn't usercontent.github.com work just as well?

A completely separate domain is more secure because it's impossible to mess up. From the browser's point of view githubusercontent.com is completely unrelated to github.com, so there's literally nothing github could accidentally do or a hacker could maliciously do with the usercontent site that would grant elevated access to the main site. Anything they could do is equally doable with their own attacker-controlled domain.

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

#252

Post by spathi_fwiffo »

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

It is defined in the article the first time it is used in the text.

Maybe they read your comment and fixed it?

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

#253

Post by bobince »

Andrew_nenakhov wrote: post #243
varun_ch wrote: post #199

Earlier quoted context omitted.

I can think of two reasons: 1. it's immediately clear to users that they're seeing content that doesn't belong to your business but instead belongs to your business's users. maybe less relevant for github, but imagine if someone uploaded something phishing-y and it was visible on a page with a url like google.com/uploads/asdf. 2. if a user uploaded something like an html file, you wouldn't want it to be able to run j…

Wouldn't usercontent.github.com work just as well?

Script running on usercontent.github.com:

- is allowed to set cookies scoped to *.github.com, interfering with cookie mechanisms on the parent domain and its other subdomains, potentially resulting in session fixation attacks

- will receive cookies scoped to *.github.com. In IE, cookies set from a site with address "github.com" will by default be scoped to *.github.com, resulting in session-stealing attacks. (Which is why it's traditionally a good idea to prefer keeping 'www.' as the canonical address from which apps run, if there might be any other subdomains at any point.)

So if you've any chance of giving an attacker scripting access into that origin, best it not be a subdomain of anything you care about.

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

#254

Post by llasse »

liquidgecka wrote: post #213
yumraj wrote: post #205

Earlier quoted context omitted.

> If you're a business and you're looking to pick up a new domain because it's only $10/year, consider that you're going to be paying $10/year forever, because once you associate that domain with your business, you can never get rid of that association. Please elaborate... Also, what about personal domains? Does it apply there as well?

My brother used to own .com and wrote on it a bunch. Eventually he bailed out and let it expire. It turned into a porn site for a few years and now its for sale for like $2k from some predatory reseller.

Same happened to my personal website for which I purchased the domain when I was 14 (long time ago) and at some point decided that a .com domain is ridiculous for a personal website. Chinese porn site it was thereafter …

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

#255

Post by codazoda »

Andrew_nenakhov wrote: post #243
varun_ch wrote: post #199

Earlier quoted context omitted.

I can think of two reasons: 1. it's immediately clear to users that they're seeing content that doesn't belong to your business but instead belongs to your business's users. maybe less relevant for github, but imagine if someone uploaded something phishing-y and it was visible on a page with a url like google.com/uploads/asdf. 2. if a user uploaded something like an html file, you wouldn't want it to be able to run j…

Wouldn't usercontent.github.com work just as well?

I think one reason is that a subdomain of github.com (like username.github.com) might be able to read and set cookies that are shared with the main github.com domain. There are ways to control this but using a different domain (github.io is the one I'm familiar with) creates wider separation and probably helps reduce mistakes.

I read about this a while back but I can't find the link anymore (and it's not the same one that op pointed to).

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

#256

Post by codethief »

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…

> 4. Email, used for verification in this post, is also poorly protected against BGP hijacks.

Do mail servers even verify TLS certs these days instead of just ignoring them?

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

#258

Post by [deleted] »

post-it wrote: post #101

Obviously there are a lot of errors by a lot of people that led to this, but here's one that would've prevented this specific exploit: > As part of our research, we discovered that a few years ago the WHOIS server for the .MOBI TLD migrated from whois.dotmobiregistry.net to whois.nic.mobi – and the dotmobiregistry.net domain had been left to expire seemingly in December 2023. Never ever ever ever let a domain expire.…

[deleted]

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

#259

Post by tptacek »

dgoldstein0 wrote: post #150
colmmacc wrote: post #40

Earlier quoted context omitted.

If you look at say 3G -> 4G -> 5G or Wifi, you see industry bodies of manufacturers, network providers, and middle vendors who both standardize and coordinate deployment schedules; at least at the high level of multi-year timelines. This is also backed by national and international RF spectrum regulators who want to ensure that there is the most efficient use of their scarce airwaves. Industry players who lag too muc…

IPv6 deployment is extra hard because we need almost every network in the world to get on board. Dnssec shouldn't be as bad, but for dns resolvers and software that build them in. I think it's a bit worse than TLS adoption in part just because of DNS allowing recursive resolution and in part DNS being applicable to a bit more than TLS was. But the big thing seems to be that there isn't a central authority like web br…

No. IPv6 deployment is tricky (though accelerating), but not all that scary, because it's easy to run IPv4 and IPv6 alongside each other; virtually everybody running IPv6 does that.

The problem with DNSSEC is that deploying it breaks DNS. Anything that goes wrong with your DNSSEC configuration is going to knock your whole site off the Internet for a large fraction of Internet users.

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

#260

Post by tptacek »

8organicbits wrote: post #116
quesera wrote: post #99

Earlier quoted context omitted.

I am definitely not arguing in favor of DNSSEC. However, I don't think it's reasonable to call DNS, as a system, "very trustworthy". "Well-secured" by active effort, and consequently "adequately trustworthy" for consumer ecommerce, sure. But DNS is a systemic weak link in the chain of trust, and must be treated with extra caution for "actually secure" systems. (E.g., for TLS and where possible, the standard way to re…

Is certificate pinning common? On the web we used to have HPKP, but that's obsolete and I didn't think it was replaced. I know pinning is common in mobile apps, but I've generally heard that's more to prevent end-user tampering than any actual distrust of the CAs/DNS. I think you're "well-secured" comment is saying the same thing I am, with some disagreement about "adequate" vs "very". I don't spend any time worrying…

Certificate pinning is more or less dead. There are mobile apps that still do it, but most security engineers would say that's a mistake. WebPKI integrity is largely driven through CT now.
Post reply on HN