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:<p>> 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.<p>Never ever ever ever let a domain expire. 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 <i>never</i> get rid of that association.
I have the feeling that any day now I’m gonna wake up in the morning and I’ll find out that there just isn’t internet anymore because somebody did something from a hotel room in the middle of nowhere with a raspberry pi connected to a wifi hotspot of a nearby coffee shop.
Why are tools using hardcoded lists of WHOIS servers?<p>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:<p><pre><code> dig _nicname._tcp.fr SRV +noall +answer
_nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr.
</code></pre>
Edit:<p>There's an expired Internet Draft for this: <a href="https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-01" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...</a>
I’ve seen so many teams that fail to realize that once you use a domain in any significant way, you’re basically bound to renewing it until the heat death of the universe – or at least the heat death of your team.<p>Whether it’s this sort of thing, a stale-but-important URL hanging out somewhere, someone on your team signing up for a service with an old domain-email, or whatever, it’s just so hard to know when it’s truly okay let an old domain go.
The real solution to WHOIS is RDAP.<p>Unfortunately, it isn't required for ccTlds, and there are plenty of non-ccTlds that aren't working.<p><a href="https://en.wikipedia.org/wiki/Registration_Data_Access_Protocol" rel="nofollow">https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...</a><p><a href="https://resolve.rs/domains/rdap-missing.html" rel="nofollow">https://resolve.rs/domains/rdap-missing.html</a>
Very cool work.<p>>The dotmobiregistry.net domain, and whois.dotmobiregisry.net hostname, has been pointed to sinkhole systems provided by ShadowServer that now proxy the legitimate WHOIS response for .mobi domains.<p>If those domains were meant to be deprecated should be better to return a 404. Keeping them active and working like normal reduces the insensitive to switch to the legitimate domain.
I think the whole computer approach is doomed to failure. It relies on perfect security that is supposed to be achieved by SBOM checking and frequent updates.<p>That is never going to work. Even log4j, 40% of all downloads are vulnerable versions. Much less when a vendor in a chain goes out of business or stops maintaining a component.<p>Everything is always going to be buggy and full of holes, just like our body is always full of battlefields with microbes.
I love the overall sense of we didn't want to this but things just keep escalating and they keep getting more than they bargained for at each step.<p>If only the naysayers had listened and fixed their parsing, the post authors might've been spared.
>You would, at this point, be forgiven for thinking that this class of attack - controlling WHOIS server responses to exploit parsing implementations within WHOIS clients - isn’t a tangible threat in the real world.<p>Let's flip that on its head - are we expected to trust every single WHOIS server in the world to always be authentic and safe? Especially from the point of view of a CA trying to validate TLS, I would not want to find out that `whois somethingarbitrary.ru` leaves me open to an RCE by a Russian server!
> $ sqlite3 whois-log-copy.db "select source from queries"|sort|uniq|wc -l<p>Oh cool they saved the logs in a database !
Wait... |sort|uniq|wc -l ??
But why ?
Conjecture: control over tlds should be determined by capture the flag. Whenever an organization running a registry achieves a level of incompetence whereby its tld is captured, the tld becomes owned by the attacker.<p>Sure there are problems with this conjecture, like what if the attacker is just as incompetent (it just gets captured again), or "bad actor" etc. A concept similar to capture the flag might provide for evolving better approaches toward security than the traditional legal and financial methods of organizational capture the flag.
It's grotesquely insecure and not authoritative to rely on rando, unsecured WHOIS in the clear scraping contact details to "authenticate" domain ownership rather than ask the owner to provide a challenge cookie by DNS or hosted in content.
> We recently performed research that started off "well-intentioned" (or as well-intentioned as we ever are) - to make vulnerabilities in WHOIS clients and how they parse responses from WHOIS servers exploitable in the real world (i.e. without needing to MITM etc).<p>R̶i̶g̶h̶t̶ o̶f̶f̶ t̶h̶e̶ b̶a̶t̶, S̶T̶O̶P̶. I̶ d̶o̶n̶'t̶ c̶a̶r̶e̶ w̶h̶o̶ y̶o̶u̶ a̶r̶e̶ o̶r̶ h̶o̶w̶ "w̶e̶l̶l̶-̶i̶n̶t̶e̶n̶t̶i̶o̶n̶e̶d̶" s̶o̶m̶e̶o̶n̶e̶ i̶s̶. I̶n̶t̶e̶n̶t̶i̶o̶n̶a̶l̶l̶y̶ s̶p̶r̶i̶n̶k̶l̶i̶n̶g̶ i̶n̶ v̶u̶l̶n̶e̶r̶a̶b̶l̶e̶ c̶o̶d̶e̶, K̶N̶O̶W̶I̶N̶G̶L̶Y̶ a̶n̶d̶ W̶I̶L̶L̶I̶N̶G̶L̶Y̶ t̶o̶ "a̶t̶ s̶o̶m̶e̶ p̶o̶i̶n̶t̶ a̶c̶h̶i̶e̶v̶e̶ R̶C̶E̶" i̶s̶ b̶e̶h̶a̶v̶i̶o̶r̶ t̶h̶a̶t̶ I̶ c̶a̶n̶ n̶e̶i̶t̶h̶e̶r̶ c̶o̶n̶d̶o̶n̶e̶ n̶o̶r̶ s̶u̶p̶p̶o̶r̶t̶. I̶ t̶h̶o̶u̶g̶h̶t̶ t̶h̶i̶s̶ k̶i̶n̶d̶ o̶f̶ r̶o̶g̶u̶e̶ c̶o̶n̶t̶r̶i̶b̶u̶t̶i̶o̶n̶s̶ t̶o̶ p̶r̶o̶j̶e̶c̶t̶s̶ h̶a̶d̶ a̶ g̶r̶e̶a̶t̶ e̶x̶a̶m̶p̶l̶e̶ w̶i̶t̶h̶ t̶h̶e̶ U̶n̶i̶v̶e̶r̶s̶i̶t̶y̶ o̶f̶ M̶i̶n̶n̶e̶s̶o̶t̶a̶ o̶f̶ w̶h̶a̶t̶ n̶o̶t̶ t̶o̶ d̶o̶ w̶h̶e̶n̶ t̶h̶e̶y̶ g̶o̶t̶ a̶l̶l̶ t̶h̶e̶i̶r̶ c̶o̶n̶t̶r̶i̶b̶u̶t̶i̶o̶n̶s̶ r̶e̶v̶o̶k̶e̶d̶ a̶n̶d̶ f̶o̶r̶c̶e̶ r̶e̶v̶i̶e̶w̶e̶d̶ o̶n̶ t̶h̶e̶ L̶i̶n̶u̶x̶ k̶e̶r̶n̶e̶l̶.<p>EDIT: This is not what the group has done upon further scrutiny of the article. It's just their very first sentence makes it sound like they were intentionally introducing vulnerabilities in existing codebases to achieve a result.<p>I definitely can see that it should have been worded a bit better to make the reader aware that they had not contributed bad code but were finding existing vulnerabilities in software which is much better than where I went initially.
The cost of managing a domain portfolio is like compound interest — the more domains you add, the higher the renewal costs climb year after year.<p>It’s tempting to hold onto every domain ‘just in case,’ but cutting domains without a proper risk assessment can open the door to serious security issues, as this article points out.
I still remember when websites would redirect you on your phone to their .mobi website, completely screwing up the original intent. They didn't show you the mobile version of whatever Google let you towards, they just lazily redirected you to the .mobi homepage. I bet they asked a non-dev to do those redirects, that one IT neckbeard who shoved a redirect into an Apache2 config file and moved on with life. :)<p>But seriously, it was the most frustrating thing about the mobile web.<p>Is this TLD even worth a damn in 2024?
The article puts the blame on<p>> Never Update, Auto-Updates And Change Are Bad<p>as the source of the problem a couple of times.<p>This is pretty common take from security professionals, and I wish they'd also call out the other side of the equation: organizations bundling their "feature" (i.e. enshittification) updates and security updates together. "Always keep your programs updated" is just not feasible advice anymore given that upgrades as just as likely to be downgrades these days. If that were to be realistic advice, we need more pressure on companies to separate out security-related updates and allow people to get updates only on that channel.
Entertaining and informative read. Main takeaways for me from an end user POV:<p>- 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.<p>- Don't use any "TLS/SSL Certificate Authorities/resellers that support WHOIS-based ownership verification."
As a reminder, RCE = remote code execution (it’s not defined in the article).<p><a href="https://www.cloudflare.com/learning/security/what-is-remote-code-execution/" rel="nofollow">https://www.cloudflare.com/learning/security/what-is-remote-...</a>
I have written PHP for a living for the last 20 years and that eval just pains me to no end<p><pre><code> eval($var . '="' . str_replace('"', '\\\\"', $itm) . '";');
</code></pre>
Why? Dear god why. Please stop.<p>PHP provides a built in escaper for this purpose<p><pre><code> eval($var . '=' . var_export($itm, true) . ';');
</code></pre>
But even then you don't need eval here!<p><pre><code> ${$var} = $itm;
</code></pre>
Is all you really needed... but really just use an array(map) if you want dynamic keys... don't use dynamically defined variables...
Great write-up - the tip of the iceberg on how fragile TLS/SSL is.<p>Let's add a few:<p>1. WHOIS isn't encrypted or signed, but is somehow suitable for verification (?)<p>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)<p>3. DNS root & TLD servers are poorly protected against BGP hijacks (adding that DNSSEC is optional for CAs to verify)<p>4. Email, used for verification in this post, is <i>also</i> poorly protected against BGP hijacks.<p>I'm amazed we've lasted this long. It must be because if anyone abuses these issues, someone might wake up and care enough to fix them (:
>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.<p>I don't want to live on this planet anymore
This is a fantastic exploit and I am appalled that CAs are still trying to use whois for this kind of thing. I expected the rise of the whois privacy services and privacy legislation would have made whois mostly useless for CAs years ago.<p><< maintainers of WHOIS tooling are reluctant to scrape such a textual list at runtime, and so it has become the norm to simply hardcode server addresses, populating them at development time by referring to IANA’s list manually. Since the WHOIS server addresses change so infrequently, this is usually an acceptable solution >><p>This is the approach taken by whois on Debian.<p>Years ago I did some hacking on FreeBSD’s whois client, and its approach is to have as little built-in hardcoded knowledge as possible, and instead follow whois referrals. These are only de-facto semi-standard, i.e. they aren’t part of the protocol spec, but most whois servers provide referrals that are fairly easy to parse, and the number of exceptions and workarounds is easier to manage than a huge hardcoded list.<p>FreeBSD’s whois starts from IANA’s whois server, which is one of the more helpful ones, and it basically solves the problem of finding TLD whois servers. Most of the pain comes from dealing with whois for IP addresses, because some of the RIRs are bad at referrals. There are some issues with weird behaviour from some TLD whois servers, but that’s relatively minor in comparison.
TLDR<p>> While this has been interesting to document and research, we are a little exasperated. Something-something-hopefully-an-LLM-will-solve-all-of-these-problems-something-something.