Verisign has revived its old name collisions security scare story, publishing this week a weighty research paper claiming millions are at risk of man-in-the-middle attacks.
It’s actually a study into how a well-known type of attack, first documented in the 1990s, might become easier due to the expansion of the DNS at the top level.
According to the paper there might be as many as 238,000 instances per day of query traffic intended for private networks leaking to the public DNS, where attackers could potentially exploit it to all manner of genuinely nasty things.
But Verisign has seen no evidence of the vulnerability being used by bad guys yet and it might not be as scary as it first appears.
You can read the paper here (pdf), but I’ll attempt to summarize.
The problem concerns a virtually ubiquitous protocol called WPAD, for Web Proxy Auto-Discovery.
It’s used by mostly by Windows clients to automatically download a web proxy configuration file that tells their browser how to connect to the web.
Organizations host these files on their local networks. The WPAD protocol tries to find the file using DHCP first, but fails over to DNS.
So, your browser might look for a wpad.dat file on wpad.example.com, depending on what domain your computer belongs to, using DNS.
The vulnerability arises because companies often use previously undelegated TLDs — such as .prod or .global — on their internal networks. Their PCs could belong to domains ending in .corp, even though .corp isn’t real TLD in the DNS root.
When these devices are roaming outside of their local network, they will still attempt to use the DNS to find their WPAD file. And if the TLD their company uses internally has actually been delegated by ICANN, their WPAD requests “leak” to registry or registrant.
A malicious attacker could register a domain name in a TLD that matches the domain the target company uses internally, allowing him to intercept and respond to the WPAD request and setting himself up as the roaming laptop’s web proxy.
That would basically allow the attacker to do pretty much whatever he wanted to the victim’s browsing experience.
Verisign says it saw 20 million WPAD leaks hit its two root servers every single day when it collected its data, and estimates that 6.6 million users are affected.
The paper says that of the 738 new gTLDs it looked at, 65.7% of them saw some degree of WPAD query leakage.
The ones with the most leaks, in order, were .global, .ads, .group, .network, .dev, .office, .prod, .hsbc, .win, .world, .one, .sap and .site.
It’s potentially quite scary, but there are some mitigating factors.
First, the problem is not limited to new gTLDs.
Yesterday I talked to Matt Larson, ICANN’s new vice president of research (who held the same post at Verisign’s until a few years ago).
He said ICANN has seen the same problem with .int, which was delegated in 1988. ICANN runs one of .int’s authoritative name servers.
“We did a really quick look at 24 hours of traffic and saw a million and a half queries for domain names of the form wpad.something.int, and that’s just one name server out of several in a 24-hour period,” he said.
“This is not a new problem, and it’s not a problem that’s specific to new gTLDs,” he said.
According to Verisign’s paper, only 2.3% of the WPAD query leaks hitting its root servers were related to new gTLDs. That’s about 238,000 queries every day.
With such a small percentage, you might wonder why new gTLDs are being highlighted as a problem.
I think it’s because organizations typically won’t own the new gTLD domain name that matches their internal domain, something that would eliminate the risk of an attacker exploiting a leak.
Verisign’s report also has limited visibility into the actual degree of risk organizations are experiencing today.
Its research methodology by necessity was limited to observing leaked WPAD queries hitting its two root servers before the new gTLDs in question were delegated.
The company only collected relevant NXDOMAIN traffic to its two root servers — DNS queries with answers typically get resolved closer to the user in the DNS hierarchy — so it has no visibility to whether the same level of leaks happen post-delegation.
Well aware of the name collisions problem, largely due to Verisign’s 11th-hour epiphany on the subject, ICANN forces all new gTLD registries to wildcard their zones for 90 days after they go live.
All collision names are pointed to 127.0.53.53, a reserved IP address picked in order to catch the attention of network administrators (DNS uses TCP/IP port 53).
Potentially, at-risk organizations could have fixed their collision problems shortly after the colliding gTLD was delegated, reducing the global impact of the vulnerability.
There’s no good data showing how many networks were reconfigured due to name collisions in the new gTLD program, but some anecdotal evidence of admins telling Google to go fuck itself when .prod got delegated.
A December 2015 report from JAS Advisors, which came up with the 127.0.53.53 idea, said the effects of name collisions have been rather limited.
ICANN’s Larson echoed the advice put out by security watchdog US-CERT this week, which among other things urges admins to use proper domain names that they actually control on their internal networks.
The 1,000th new gTLD from the 2012 application round was delegated yesterday.
It was either .shop or .realestate, appropriately enough, which both appear to have been added to the DNS root zone at about the same time.
Right now, there are actually only 999 new gTLDs live in the DNS. That’s because the unwanted .doosan was retired in February.
During its pre-launch planning for the new gTLD program, ICANN based its root zone stability planning on the assumption that fewer than 1,000 TLDs would be added to the root per year.
In reality, it’s taken much longer to reach that threshold. The first few new gTLDs were added in late October 2013, 945 days ago.
On average, in other words, a new gTLD has been added to the root slightly more than once per day.
Over that same period, nine ccTLDs — internationalized domain names applied for via a separate ICANN program — have also gone live.
The 1,000th new gTLD to be added to the IANA database was .blog.
There are 1,314 TLDs in the root all told.
In a surprising move towards further transparency, the ICANN board of directors has decided to start publishing transcripts and possibly recordings of its meetings.
It passed a resolution during a meeting in Amsterdam this week stating:
the Board directs the President and CEO, or his designee(s), to work with the Board to develop a proposed plan for the publication of transcripts and/or recordings of Board deliberative sessions, with such plan to include an assessment of possible resources costs and fiscal impact, and draft processes to: (i) ensure the accuracy of the transcript; and (ii) for redaction of portions of the transcript that should be maintained as confidential or privileged.
Transcription services can be picked up dirt cheap, so I can’t see money getting in the way of this proposal becoming a reality.
A question mark of course hangs over the “confidential or privileged” carve-out, of course. ICANN is sometimes over-generous with what it considers redactable material.
Still, it’s great news for the ICANN community, which has been calling for greater board transparency for years.
When I started covering ICANN back in 1999, board sessions at the then four-times-a-year public meetings were conducted in the open; all the thinking was done aloud.
At some point in the early 2000s that stopped, however, and the board’s public sessions became a case of rubber-stamping resolutions that had already been debated behind closed doors.
Minutes, staff-prepared briefing materials and broad-stroke narrative reports have been published, but they give limited insight into the depth of the discussions.
Chair Steve Crocker has even stated in recent years that its goal was to make these public sessions “as boring as possible”.
That’s obviously no good for those of us who’d like to know how top-level decisions at ICANN actually get made.
The plan is for new CEO Goran Marby, who starts on Monday, to come up with a proposal before the Helsinki meeting next month, with a view to start publishing transcripts not long thereafter
ICANN has confirmed that its 57th public meeting will not be held, as originally planned, in Puerto Rico.
Instead, it is asking community members to instead head to Hyderabad, India, this November.
Those Las Vegas rumors turned out not to be true. However, on the up-side, those Las Vegas rumors turned out not to be true!
The decision was to relocate made to the a “state of emergency” being declared in Puerto Rico due to the Zika virus.
Zika is spread by mosquitoes and male sexual partners and can cause devastating birth defects in kids.
Latest figures from the US Center for Disease Control put infections in US territories at 701, three of whom were travelers.
ICANN said in a blog post this evening:
This decision was based on available research and information and the fact that Puerto Rico has declared a state of emergency due to the ongoing Zika virus outbreak. We believe that the Zika virus poses a significant enough threat that we need to postpone going to Puerto Rico for the health and safety of our community and our ICANN team, just as we had to postpone ICANN52 and relocate from Marrakech to Singapore due to the Ebola virus outbreak in 2014.
It’s the second of this year’s meetings to be relocated due to Zika. June’s Panama meeting has been moved to Helsinki.
ICANN said that the new venue for ICANN 57, which takes place from November 3 to 9 this year, is the Hyderabad International Convention Centre.
It’s said that ICANN will take a seven-figure hit to its bank balance in order to cancel the PR meeting.
ICANN has proposed new anti-harassment guidelines for its community that would ban “unwelcome hostile or intimidating behavior”.
It wants your comments on the changes to its longstanding “Expected Standards of Behavior” document, which applies to both its in-person meetings and online discussions and mailing lists.
The proposed addition to the document reads like this:
Respect all members of the ICANN community equally and behave according to professional standards and demonstrate appropriate behavior. ICANN strives to create and maintain an environment in which people of many different backgrounds and cultures are treated with dignity, decency, and respect. Specifically, participants in the ICANN process must not engage in any type of harassment. Generally, harassment is considered unwelcome hostile or intimidating behavior — in particular, speech or behavior that is sexually aggressive or intimidates based on attributes such as race, gender, ethnicity, religion, age, color, national origin, ancestry, disability or medical condition, sexual orientation, or gender identity.
The definition of harassment has been borrowed almost directly from the Internet Engineering Task Force’s policy on harassment, which was signed off in 2013.
ICANN has added the words “ethnicity” and “medical condition” to the IETF’s list of protected characteristics, but has not included the IETF’s list of examples:
the use of offensive language or sexual imagery in public presentations and displays, degrading verbal comments, deliberate intimidation, stalking, harassing photography or recording, inappropriate physical contact, and unwelcome sexual attention.
The changes were prompted by a recent allegation of sexual harassment at an ICANN meeting which divided the community on whether the alleged incident amounted to sexual harassment or not.
ICANN’s Ombudsman, Chris LaHatte, concluded that whatever took place “cannot be considered serious”, but he did not make a formal finding.
LaHatte has already endorsed the proposed change to the expected standards document.
It does not seem unreasonable to me, at first glance, either.
What do you think? ICANN has opened a public comment period that closes June 25, to find out.