Security Researcher Exposes Critical WHOIS Vulnerability (arstechnica.com) 21
A security researcher has exposed a critical vulnerability in the WHOIS system. Benjamin Harris, CEO of watchTowr, gained unprecedented access by registering an expired domain once used for .mobi's authoritative WHOIS server. His rogue server received millions of queries from thousands of systems, including government agencies, certificate authorities, and major tech companies. ArsTechnica adds: The humor aside, the rogue WHOIS server gave him powers he never should have had. One of the greatest was the ability to dictate the email address certificate authority GlobalSign used to determine if a party applying for a TLS certificate was the rightful owner of the domain name the certificate would apply to. Like the vast majority of its competitors, GlobalSign uses an automated process. An application for example.com, for instance, will prompt the certificate authority to send an email to the administrative email address listed in the authoritative WHOIS for that domain. If the party on the other end clicks a link, the certificate is automatically approved. When Harris generated a certificate signing request for microsoft.mobi, he promptly received an email from GlobalSign. The email gave him the option of receiving a verification link at whois@watchtowr.com. For ethical reasons, he stopped the experiment at this point. The vulnerability stems from outdated WHOIS client configurations, which underscores systemic weaknesses in internet infrastructure management.
Simple solution (Score:2)
Never reuse the domain name of any WHOIS server.
Re: (Score:3)
Never reuse the domain name of any
LOL - I mean sure; but that 'fix' applies to a huge range of network services! Start apply it to liberally and it will not take long before we have more "retired" names in popular names spaces than allowed ones.
We either need a better trust model or we need the CAs to go back to doing their actual jobs and verifying just exactly who they are issuing too. Go back to charging a couple hundred dollars, collecting all the tax and D&B numbers, and verifying the party can get receive real paper mail at the ad
Re:Simple solution (Score:5, Insightful)
This is kind of a pointless FA anyway, if any domain expires and I acquire it, of course I am going to get all the domain traffic, including web, whois or anything else. It's been done before for nefarious purposes so nothing new here and nothing specific to whois. Maybe a better idea would be not to let your critical domain registrations expire...
Re: Simple solution (Score:1)
Re: (Score:2)
I looked it up, pretty cheap but OTOH, pretty easy to script for free and put in a cron job.
outhouse of tech (Score:2)
Have to agree that the communication protocols, low-level server processes and stack o' crud making up today's internet need a reboot with all new technology and none of the legacy garbage.
And, until there is a WW outage for months of some major component, nothing is likely to get replaced 100%.
Re: outhouse of tech (Score:2)
And the "new technology" will be free of garbage and it won't start accumulating technological debt since the beginning, I presume?
Fat chance
It will need years, possibly decades, to match the usefulness of what we have now.
Yes decades (Score:2)
No one wants to be the first to start a whole new ecosystem around what is now the unstable stack of internet web technologies.
We cannot even get a general purpose language to replace the mess of JavaScript in the browser, though google's Dart (12 years old now), 'will just about any day now' make it into all browsers and replace JavaScript.
I'd expect only a worldwide failure of months of outages to force some change.
I'd expect, we need to form our own New Web Standards Group or something, because EMCA/w3c
Re: Oh the irony!! (Score:2)
Don't put TCP/IP (the network protocol) in your rant. It's a solid and battle-hardened piece of work. Yes, it has its technical debt, but nothing unsurmountable. And it has nothing to do with the issue we're discussing.
Not a technical vulnerability (Score:3)
Sadly, it's social engineering problems are not ones that are easily fixed. In this case, it's a human convenience problem which practically guarantees it won't be fixed. (Or at the very least not properly fixed.) The "solution" here will probably be someone pruning the domain list again. But the real fix would be to stop relying on the internet to establish identity and authenticate it all in one shot. Especially when your service is used for authenticating others.
Re:Not a technical vulnerability (Score:5, Informative)
This isn't a vulnerability in WHOIS. It's a vulnerability in the procedures of various CAs and DNS services. I.e. It's a social engineering problem not a technical one.
Yes and no. The vulnerability in WHOIS is that records are completely unsigned, so there's no way to verify that the WHOIS server really is legitimate. And this is pretty much fundamental [rfc-editor.org] in the protocol design. It was never designed to be used for any sort of purpose where security matters, and the very fact that WHOIS is being used for any sort of authorization is in itself a flaw, but that doesn't mean that the protocol itself shouldn't be rethought to fix the underlying flaw.
There's no good alternative for domain name transfers other than using WHOIS to reach out to the owners by email, but because registrar disallow outgoing transfers without pre-authorization at the registrar level, there's not really a security issue there unless someone also cracks your account at the registrar (in which case you have bigger problems than not getting the notification email).
For other uses of WHOIS, requiring people to put content on the web server or in the DNS record to prove that something is authorized is a reasonable means of authentication, and WHOIS really shouldn't be used at all. Any use of WHOIS data for anything other advisory purposes is fundamentally a design flaw, because data from WHOIS should be considered fundamentally untrusted.
Of course, WHOIS data is also not intended to be consumed by software in the first place. WHOIS servers return an arbitrary human-readable blob of text. If I wanted to, I could create a WHOIS server that, in response to a query, serves up an ASCII art version of Star Wars Episode IV, and it would be a technically valid response. And if I could somehow get real systems to point at it and try to parse the results like this security researcher did, doing so would probably create absolute chaos, with crashing processes on certificate authority servers all over the place, and who knows what else.
What we really need is a modern WHOIS protocol that provides structured data in a computer-parseable format, with proper delegation through a tree of DNS records, where the gTLD server has something similar to a glue record for each domain that says which registrar currently maintains it and either A. provides all of the data that would be served by WHOIS or B. provides the hostname for a server at the registrar that can return the data in some reasonable, machine-parseable format.
Or you could make the glue record contain a reference to the domain name of the registrar (delegation) whose glue record then points at the correct hostname for the WHOIS 2 server. This is probably the cleanest approach with the fewest opportunities for things to go horribly wrong.
Either way, at that point, as long as the registrar doesn't fail to push its glue record changes to the root servers, and as long as any server uses TLS to verify that the registrar server is legitimate (using HTTPS for WHOIS 2 seems like the most straightforward approach with the least integration pain), this sort of attack shouldn't be possible.
Re: (Score:2)
What we really need is a modern WHOIS protocol that provides structured data in a computer-parseable format
I always thought RDAP was supposed to be that new and improved replacement, but I'm not hearing much about that lately.
Re: (Score:3)
The vulnerability in WHOIS is that records are completely unsigned
A digital signature is just as worthless as the one your least favorite politician uses to sign their latest pork legislation. A massive rush to sign all the things isn't going to fix the underlying issue. Which is that someone used stale information to validate the thing. Which is not a technical failure. Even if that data was signed, it would have still been wrong at the time it was used, and still have led to a successful exploitation.
It was never designed to be used for any sort of purpose where security matters, and the very fact that WHOIS is being used for any sort of authorization is in itself a flaw,
Agreed. Which is why they shouldn't have been using it for security i
Re: (Score:2)
The vulnerability in WHOIS is that records are completely unsigned
A digital signature is just as worthless as the one your least favorite politician uses to sign their latest pork legislation. A massive rush to sign all the things isn't going to fix the underlying issue. Which is that someone used stale information to validate the thing. Which is not a technical failure. Even if that data was signed, it would have still been wrong at the time it was used, and still have led to a successful exploitation.
They used a stale list of whois host domains, apparently. Having that information be part of DNS records for the domain you're looking up would eliminate that risk, because the folks doing the lookups would be able to look up each individual record in DNS to authoritatively find out what servers provide WHOIS data, rather than querying a bunch of possible candidates from a static list.
It was never designed to be used for any sort of purpose where security matters, and the very fact that WHOIS is being used for any sort of authorization is in itself a flaw,
Agreed. Which is why they shouldn't have been using it for security in the first place. Again, that's a design flaw. Which makes it a social engineering issue (no accountability for a flawed design) not a technical one (an implementation bug in the software based on the design).
It is *both* a design flaw in the protocol *and* a design flaw in how it is used. Social engineering was not involved in a
Re: (Score:1)
This isn't a vulnerability in WHOIS. It's a vulnerability in the procedures of various CAs and DNS services. I.e. It's a social engineering problem not a technical one.
Yes and no. The vulnerability in WHOIS is that records are completely unsigned, so there's no way to verify that the WHOIS server really is legitimate. And this is pretty much fundamental [rfc-editor.org] in the protocol design. It was never designed to be used for any sort of purpose where security matters, and the very fact that WHOIS is being used for any sort of authorization is in itself a flaw, but that doesn't mean that the protocol itself shouldn't be rethought to fix the underlying flaw.
There's no good alternative for domain name transfers other than using WHOIS to reach out to the owners by email, but because registrar disallow outgoing transfers without pre-authorization at the registrar level, there's not really a security issue there unless someone also cracks your account at the registrar (in which case you have bigger problems than not getting the notification email).
For other uses of WHOIS, requiring people to put content on the web server or in the DNS record to prove that something is authorized is a reasonable means of authentication, and WHOIS really shouldn't be used at all. Any use of WHOIS data for anything other advisory purposes is fundamentally a design flaw, because data from WHOIS should be considered fundamentally untrusted.
Of course, WHOIS data is also not intended to be consumed by software in the first place. WHOIS servers return an arbitrary human-readable blob of text. If I wanted to, I could create a WHOIS server that, in response to a query, serves up an ASCII art version of Star Wars Episode IV, and it would be a technically valid response. And if I could somehow get real systems to point at it and try to parse the results like this security researcher did, doing so would probably create absolute chaos, with crashing processes on certificate authority servers all over the place, and who knows what else.
What we really need is a modern WHOIS protocol that provides structured data in a computer-parseable format, with proper delegation through a tree of DNS records, where the gTLD server has something similar to a glue record for each domain that says which registrar currently maintains it and either A. provides all of the data that would be served by WHOIS or B. provides the hostname for a server at the registrar that can return the data in some reasonable, machine-parseable format.
Or you could make the glue record contain a reference to the domain name of the registrar (delegation) whose glue record then points at the correct hostname for the WHOIS 2 server. This is probably the cleanest approach with the fewest opportunities for things to go horribly wrong.
Either way, at that point, as long as the registrar doesn't fail to push its glue record changes to the root servers, and as long as any server uses TLS to verify that the registrar server is legitimate (using HTTPS for WHOIS 2 seems like the most straightforward approach with the least integration pain), this sort of attack shouldn't be possible.
You won't believe it, but we conducted a study on a new class of vulnerabilities in two-factor authentication in our college. I managed to complete my work with the help of https://essays.edubirdie.com/java-assignment [edubirdie.com] but It was an amateur study . To be honest, I found it quite difficult to find some factors, but this service handled everything, for which I am sincerely grateful.
Infosec person wants attention (Score:2)
Please give his infosec company money. He is an expert, clearly. I bet his advice for securing a building is to brick up all the windows and doors with everyone inside.
How vulnerable can whois be? (Score:2)
Or worse you find it's a GoDaddy hosted server so now whois is double useless.
Re: (Score:2)
Meh all around (Score:2)
Also I don't agree that WHOIS is totally to blame. CA's that want to use email verification should have the domain side of the email address locked. That's what a few CA's for wildcards do. No WHOIS lookup. You want a CA for example.com? They aren't asking a WHOIS to see if example.com is actually managed by billy@yahoo.com. Your option
Re: (Score:2)
I'm not downplaying the malice that can come from a compromised WHOIS setup. Not at all. My comments were about how I don't think CA's should be relying on WHOIS to begin with. There are better ways than relying on WHOIS. From the article and summary:
One of the greatest was the ability to dictate the email address certificate authority GlobalSign used to determine if a party applying for a TLS certificate was the rightful owner of the domain name the certificate would apply to.
Just use a DNS record to dictate the same email address list(s).