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.
There's an expired Internet Draft for this: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...
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.
Unfortunately, it isn't required for ccTlds, and there are plenty of non-ccTlds that aren't working.
https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
>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.
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.
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.
Everything is always going to be buggy and full of holes, just like our body is always full of battlefields with microbes.
If only the naysayers had listened and fixed their parsing, the post authors might've been spared.
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!
Oh cool they saved the logs in a database ! Wait... |sort|uniq|wc -l ?? But why ?
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.
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̶.
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.
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.
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.
But seriously, it was the most frustrating thing about the mobile web.
Is this TLD even worth a damn in 2024?
> Never Update, Auto-Updates And Change Are Bad
as the source of the problem a couple of times.
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.
- 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.
- Don't use any "TLS/SSL Certificate Authorities/resellers that support WHOIS-based ownership verification."
https://www.cloudflare.com/learning/security/what-is-remote-...
What? No.
eval($var . '="' . str_replace('"', '\\\\"', $itm) . '";');
PHP provides a built in escaper for this purpose
eval($var . '=' . var_export($itm, true) . ';');
${$var} = $itm;
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 verify)
4. Email, used for verification in this post, is also poorly protected against BGP hijacks.
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 (:
I don't want to live on this planet anymore
<< 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 >>
This is the approach taken by whois on Debian.
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.
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.
> 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.
> 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. 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.