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

141–150 of 391 posts

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

#141

Post by playingalong »

declan_roberts wrote: post #102
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.…

Always use subdomains. Businesses only ever need a single $10 domain for their entire existence.

I think it's a sane practice to keep the marketing landing page on a separate domain than the product in case of SaaS.

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

#142

Post by amelius »

xp84 wrote: post #121
donatj wrote: post #64

I have written PHP for a living for the last 20 years and that eval just pains me to no end eval($var . '="' . str_replace('"', '\\\\"', $itm) . '";'); Why? Dear god why. Please stop. PHP provides a built in escaper for this purpose eval($var . '=' . var_export($itm, true) . ';'); But even then you don't need eval here! ${$var} = $itm; Is all you really needed... but really just use an array(map) if you want dynamic…

I mean no disrespect to you, but this sort of thing is exactly the sort of mess I’ve come to expect in any randomly-selected bit of PHP code found in the wild. It’s not that PHP somehow makes people write terrible code, I think it’s just the fact that it’s been out for so long and so many people have taken a crack at learning it. Plus, it seems that a lot of ingrained habits began back when PHP didn’t have many of it…

Replace PHP by C or C++ in your comment, and then read it again.

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

#143

Post by GTP »

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…

> Our computer security analogies are modeled around securing a home from burglars

Well, no home is burglar-proof either. Just like with computer security, we define , often just implicitly, a threat model and then we decide which kind of security measures we use to protect our homes. But a determined burglar could still find a way in. And here we get to a classic security consideration: if the effort required to break your security is greater than the benefit obtained from doing so, you're adequately protected from most threats.

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

#144

Post by tialaramex »

tetha wrote: post #76
devvvvvvv wrote: post #21

Earlier quoted context omitted.

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

CAA records are not addressed to end users, or to browsers or whatever - they are addressed to the Certificate Authority, hence their name.

The CAA record essentially says "I, the owner of this DNS name, hereby instruct you, the Certificate Authorities to only issue certificates for this name if they obey these rules"

It is valid, and perhaps even a good idea in some circumstances, to set the CAA record for a name you control to deny all issuance, and only update it to allow your preferred CA for a few minutes once a month while actively seeking new certificates for any which are close to expiring, then put it back to deny-all once the certificates were issued.

Using CAA allows Meta, for example, to insist only Digicert may issue for their famous domain name. Meta has a side deal with Digicert, which says when they get an order for whatever.facebook.com they call Meta's IT security regardless of whether the automation says that's all good and it can proceed, because (under the terms of that deal) Meta is specifically paying for this extra step so that there aren't any security "mistakes".

In fact Meta used to have the side deal but not the CAA record, and one day a contractor - not realising they're supposed to seek permission from above - just asked Let's Encrypt for a cert for this test site they were building and of course Let's Encrypt isn't subject to Digicert's agreement with Meta so they issued based on the contractor's control over this test site. Cue red faces for the appropriate people at Meta. When they were done being angry and confused they added the CAA record.

[Edited: Fix a place where I wrote Facebook but meant Meta]

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

#145

Post by adolph »

sebstefan wrote: post #94
account42 wrote: post #89

Earlier quoted context omitted.

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

Not with that attitude Start shipping the compiler with your code for infrastructure-agnostic RCEs

When you turn pro you call it security software and add it to the kernel.

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

#146

Post by mdaniel »

lambda wrote: post #100
account42 wrote: post #89

Earlier quoted context omitted.

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

No, but they have system or the like, which is effectively the same, just being evaluated by the shell. https://man7.org/linux/man-pages/man3/system.3.html

And thanks to the magic of "shoving strings from the Internet into a command line", poof, RCE! It bit GitLab twice

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

#147

Post by jonhohle »

dr_kretyn wrote: post #138
zoover2020 wrote: post #108

Earlier quoted context omitted.

This is why PHP is mostly banned at bigCo

Pretty sure there's plenty of PHP at Amazon and Facebook (just with slightly different names)

There is no PHP at Amazon (at least not 2009-2016). It was evaluated before my time there and Perl Mason was chosen instead to replace C++. A bunch if that’s still appears to exist (many paths that start with gp/) but a lot was being rebuilt in various internal Java frameworks. I know AWS had some rails apps that were being migrated to Java a decade ago, but I don’t think I ever encountered PHP (and I came in as a programmer primarily writing PHP).

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

#148

Post by svieira »

wwweston wrote: post #130
z3phyr wrote: post #87

Earlier quoted context omitted.

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.

> > Our industry argues about code style (: > Our industry does not argue about code style. QED

I'm pretty sure this is QEF.

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

#149

Post by jimt1234 »

candiddevmike wrote: post #28
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…

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.

In my 25+ years in this industry, there's one thing I've learned: starting something isn't all that difficult, however, shutting something down is nearly impossible. For example, brilliant people put a lot of time end effort into IPv6. But that time and effort is nothing compared to what it's gonna take to completely shut down IPv4. And I've dealt with this throughout my entire career: "We can't shut down that Apache v1.3 server because a single client used it once 6 years ago!"

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

#150

Post by dgoldstein0 »

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

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 browsers who can entirely force the issue. ... Maybe OS vendors could do it?

Quic is an end to end protocol so should be deployable without every network operator buying in. That said, we probably do need a reduction in udp blocking in some places. But otherwise, how can quic deployment be harder than TLS deployment? I think there just hasn't been incentive to force it everywhere.

Post reply on HN