KeyTrap ‘the most devastating vulnerability ever found in DNSSEC’

A security vulnerability in the DNSSEC standard that could crash DNS resolution in software such as BIND and services such as Cloudflare and Google Public DNS has been called “the most devastating vulnerability ever found in DNSSEC”.

Named KeyTrap, it enables attackers to overwhelm a DNS resolver’s CPU for as long as 16 hours, forcing it to process up to two million times its usual load, using a single malicious DNS packet, making for a potentially crippling denial-of-service attack.

The flaw was discovered last year by Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael Waidner from ATHENE, the German National Research Center for Applied Cybersecurity, and publicly disclosed last week after vendors were given time to develop and deploy patches.

While KeyTrap has been present in DNS software for almost a quarter-century, the researchers are not aware of it being exploited in the wild.

The vulnerability is actually baked into the DNSSEC technical standards, developed in the 1990s, rather than being specific to any one implementation of the specs, according to the researchers. In fact, in order to patch the problem vendors had to break with the standard RFCs.

KeyTrap works because DNSSEC is (believe it or not) designed to avoid causing downtime when it fails, so it tries too eagerly to validate cryptographic signatures by checking all the keys available to it. Exploiting this helpfulness, an attacker could trick a resolver into eating up all its CPU resources checking huge numbers of keys.

Schulmann wrote in an article explaining the vulnerability:

Our methods show a low-resource adversary can fully attack a DNS resolver with a Denial-of-Service (DoS) for up to 16 hours with a single DNS request. Members from the 31-participant task force of major operators, vendors, and developers of DNS/DNSSEC, to which we disclosed our research, dubbed our attack ‘the most devastating vulnerability ever found in DNSSEC’.

DNSSEC is designed to mitigate the risk of DNS cache-poisoning and man-in-the-middle attacks, but because its default behavior when the crypto fails is to refuse to resolve the affected domains, it can also lead to availability problems.

It’s not uncommon for entire TLDs to fail for hours when the registry screws up a DNSSEC key rollover. The web site you’re reading right now suffered downtime a few years ago due to a DNSSEC fail at the registrar level.

The KeyTrap researchers believe about 31% of web client devices currently use DNSSEC resolvers.

ICANN’s new conferencing software has a webcam security bug

ICANN can’t catch a break when it comes to remote participation security, it seems.
Having just recently made the community-wide switch away from Adobe Connect to Zoom, partly for security reasons, now Zoom has been hit by what many consider to be a critical zero-day vulnerability.
Zoom (which, irrelevantly, uses a .us domain) pushed out an emergency patch for the vulnerability yesterday, which would have allowed malicious web sites to automatically turn on visitors’ webcams without their consent.
Only users of the installable Mac client were affected.
According to security researcher Jonathan Leitschuh, who discovered the problem, Zoom’s Mac client was installing a web server on users’ machines in order to bypass an Apple security feature that requires a confirmatory click before the webcam turns on.
This meant a web site owner could trick a user into a Zoom session, with their camera turned on by default, without their knowledge or consent.
If you’re in the habit of keeping your webcam lens uncovered, that’s potentially a big privacy problem, especially if you do most of your remote coverage of ICANN meetings from the toilet.
It appears that Leitschuh, who reported the problem to Zoom three months ago, took issue with what he saw as the company’s ambivalent attitude to fixing it in a timely fashion.
When he finally blogged about it on Monday, after giving Zoom a 90-day “responsible disclosure” period to issue a patch, the problem still hadn’t been fully resolved, he wrote.
But, following media coverage, Zoom’s new patch apparently removes the covert web server completely. This removes the vulnerability but means Apple users will have to click a confirmation button before joining Zoom meetings in future.
Zoom is used now for all of ICANN’s remote participation, from sessions of its public meetings to discussions of its policy-making working groups.
I really like it. It feels a lot less clunky than Adobe, and it’s got some nifty extra features such as the ability to skip around in recordings based on an often-hilarious machine-transcription sidebar, which makes my life much easier.
One of the reasons ICANN made the switch was due to a bug found in Adobe Connect last year that could have been used to steal confidential information from closed meetings.
ICANN actually turned off Adobe Rooms for remote participants halfway through its public meeting in Puerto Rico due to the bug.
The switch to Zoom was hoped to save ICANN $100,000 a year.

More security issues prang ICANN site

ICANN has revealed details of a security problem on its web site that could have allowed new gTLD registries to view data belonging to their competitors.
The bug affected its Global Domains Division customer relationship management portal, which registries use to communicate with ICANN on issues related to delegation and launch.
ICANN took GDD down for three days, from when it was reported February 27 until last night, while it closed the hole.
The vulnerability would have enabled authenticated users to see information from other users’ accounts.
ICANN tells me the issue was caused because it had misconfigured some third-party software — I’m guessing the Salesforce.com platform upon which GDD runs.
A spokesperson said that the bug was reported by a user.
No third parties would have been able to exploit it, but ICANN has been coy about whether any it believes any registries used the bug to access their competitors’ accounts.
ICANN has ‘fessed up to about half a dozen crippling security problems in its systems since the launch of the new gTLD program.
Just in the last year, several systems have seen downtime due to vulnerabilities or attacks.
A similar kind of privilege escalation bug took down the Centralized Zone Data Service last April.
The RADAR service for registrars was offline for two weeks after being hacked last May.
A phishing attack against ICANN staff in December enabled hackers to view information not normally available to the public.

Domain hijacking bug found in Go Daddy

Go Daddy has rushed out a fix to a security bug in its web site that could have allowed attackers to steal valuable domain names.
Security engineer Dylan Saccomanni found several “cross site request forgery” holes January 17, which he said could be used to “edit nameservers, change auto-renew settings and edit the zone file entirely”.
He reported it to Go Daddy (evidently with some difficulty) and blogged it up, with attack code samples, January 18. Go Daddy reportedly patched its site the following day.
A CSRF vulnerability is where a web site fails to adequately validate data submitted via HTTP POST. Basically, in this case Go Daddy apparently wasn’t checking whether commands to edit name servers, for example, were being submitted via the correct web site.
Mitigating the risk substantially, attackers would have to trick the would-be victim domain owner into filling out a web form on a different site, while they were simultaneously logged into their Go Daddy accounts, in order to exploit the vulnerability, however.
In my experience, Go Daddy times out logged-in sessions after a period, reducing the potential attack window.
Being phishing-aware would also reduce your chance of being a victim.
I’m not aware of any reports of domains being lost to this attack.

TAS bug hit over 100 new gTLD applicants

It just keeps getting worse.
ICANN’s TLD Application System security bug could have revealed file names belonging to 105 new gTLD applicants to 50 other applicants on 451 occasions, according to the organization.
With 1,268 applicants in the system, those numbers certainly fit with the “a minority of applicants” description previously given, but it still shows that the bug was widespread.
The supplied numbers are “approximate”, but ICANN said it is “continuing to review system logs and packet-level traffic to confirm how many viewings actually did occur.”
The latest news means, for example, that 50 new gTLD applicants may have had the ability to see information belonging to other applicants on average nine times each.
While the new data may not strongly suggest that the bug was deliberately exploited by any applicant(s), it’s not inconsistent with that scenario.
It could mean that one applicant saw the details of 56 others (suggesting exploitation), but it could also mean that 50 applicants saw about two third-party file names each (suggesting accidental viewing).
Without further information, it’s impossible to know.
ICANN has not revealed, and is unlikely to reveal in the short term, whether any applicant was able to view the metadata of another applicant for the same gTLD.
The organization has however started to notify affected applicants whether they were affected as victim or beneficiary, according to the latest update from chief operating officer Akram Atallah.
Atallah also revealed that TAS had 95,000 file attachments in the system when it was taken down April 12.
At an average of 75 files per TAS account, this would support the idea that, on average, each TAS account was being used to file more than one application.
ICANN still plans to wrap up the notification process before next Tuesday, May 8, but there’s no word yet on when TAS will reopen for the final five days of the application window.

Beckstrom breaks TAS bug silence, says Big Reveal could be as late as Prague

ICANN may not reveal its list of new generic top-level domain applications until as late as the last week of June, according to CEO Rod Beckstrom.
In his first interview since ICANN took its TLD Application System offline due to a security bug, Beckstrom told DI that he “hopes” to host the Big Reveal before he steps down as ICANN’s CEO.
He said he expects to have the new gTLD program back on track before he hands the reins to the organization over to his successor at the end of the ICANN 44 meeting in Prague, June 29:

I’d like to see us obviously get the technical issues resolved, notify applicants, reopen the window and publish the strings before I pass the baton in Prague. That’s not a commitment at this point in time, it’s an indication as CEO that it’s absolutely my intention to push for a timely resolution of this issue… If we can get things done sooner, then the sooner the better.

That’s two months away, a full month later than anyone was expecting.
The Big Reveal was originally scheduled for today. However, the TAS delays made this impossible. Following an ICANN update on Friday, a late-May date for the Big Reveal was looking more probable.
But Beckstrom would not commit even to the Prague date. He said:

That’s my hope as a CEO, to get these issues resolved by that time-frame and have the string reveal in that time-frame. I haven’t committed the organization, I’m indicating to you volitionally my desire as CEO and the person who’s running the organization.

He framed the issue as a blip on a nine-year process (six years of policy development, one year of outreach and application filing, and up to two years of evaluation). He said:

In the context of nine-year program, a delay of between here and Prague of a few months is undesirable, it’s not what we want to have happen, but the quality of this program is more important to everyone involved than the specific date and time. We’re all focused on quality here and not just doing things in a hurry. This program is too important.

He said he is “sympathetic” to applicants that are burning through start-up funding waiting for ICANN to sort this out, but he noted that the same concerns have been raised over the years whenever the program has previously missed a launch deadline.

We know that some parties have been very patient and we know it’s got to be frustrating right now to see any delay in the program. At the same time, I’m sure that those parties are very concerned that this be done well and that the program be reopened and administered successfully.

Beckstrom reaffirmed ICANN’s promise to notify all applicants whether or not they were affected by the TAS bug – which revealed user names and file names to other TAS users – by May 8.
But TAS will not, it seems, reopen immediately after the notifications have been sent. As well as the log audit, ICANN is also working on performance upgrades.
While Beckstrom confirmed that the plan is to open TAS for five business days, to give applicants a chance to finish uploading their applications and confirm that their data has not been corrupted, he would not say when this window is due to open.

We’re going to share more precise dates when we have them. What I can tell you precisely right now is that the key thing we’re working on is combing through this large data set we have so that the parties that were affected are notified within the seven days. When we have clarity on the next milestone in the process we’ll communicate that openly.
…
We’re still doing system testing, we’re still looking at some of the performance issues. We have a whole set of things to do and feel comfortable that we’re ready and have full internal sign off. We’ll notify you and other parties when we have that clarity. Right now we have the clarity that we’re going to get the notification done in seven days – that’s the key dating item at this time.
…
We have very strong reason to believe we understand the bug and we’ve fixed the bug, but every day that we continue to test we gain a higher level of confidence in the system that this specific issue will not reappear.

While the first report of the bug was received March 19, it was not until April 12 that ICANN managed to “connect the dots” and figure out that the problem was serious and recurring, Beckstrom said.
ICANN saw the bug show up again repeatedly on April 12, as many TAS users logged in to finish off their applications, which was why it chose to take the system down with just 12 hours to go before the filing deadline.
ICANN is currently analyzing a 500GB log containing a record of every data packet that went into and out of the TAS between January 12 and April 12, to reconstruct every user session and determine who could see what and when, Beckstrom said.
He refused to comment on whether this analysis has revealed any attempts by TAS users to deliberately exploit the bug for competitive intelligence on other applicants.
He also declined to comment on whether ICANN has discovered instances of data leakage between two applicants for the same gTLD string.
The full packet capture system was introduced following a third-party security audit of the system conducted late last year, he said.
That audit, of course, did not reveal the data leakage vulnerability that continues to delayed the program.
When I put it to him that this is precisely the kind of problem ICANN wanted to avoid, due to the confidentiality of the applications, Beckstrom played down the seriousness of the bug.

Let’s be clear here: some user names and file names were visible, not the contents of applications and not the contents of those files. I think that if that had occurred it would be an even more undesirable situation and we have no indication that that occurred.
I wouldn’t call this a security issue, I’d call this… every major software system we use has bugs in it or bugs that are discovered over time. Whether that’s our operating systems or desktop applications or specific applications, you conduct the best tests you can. You assemble a testing suite, you assemble testers, you take various methods, but there’s never a guarantee that software is bug-free. The issue is that if and when bugs are encountered you deal with them appropriately, and that’s what we’re doing right now.

But Beckstrom admitted that the problem is embarrassing for ICANN, adding that sorting out the mess is currently the top priority.

Obviously any time you have a software problem or technical problem with any program you come under enhanced scrutiny and criticism, and I think that’s understandable, that’s fair. What we’re focused on is resolving this successfully and I think ICANN has dealt with many challenges in its past successfully and we’re committed to resolve this issue professionally.
…
I should tell you that this is our top priority right now internally right now. The resolution of this issue is our number one priority, the number one issue for me as CEO, number one for most members of the executive management team and for a large part of the organization. We’re extremely focused on this.

ICANN plans to reveal how many applicants were affected by the bug at the same time as it notifies applicants, Beckstrom said. It will not publish information about who could see what, he said.
Unfortunately for applicants, it seems they will have to wait well into next week before they have any more clarity on the timetable for TAS coming back online and the application window finally closing.
With Prague now emerged as a potential deadline for the reveal, the delays could in fact be much worse than anyone was expecting.
DI PRO subscribers can read a full transcript of the 30-minute interview.

New gTLDs now a month behind schedule

ICANN has announced yet another delay in its new generic top-level domains program.
Last night’s much-anticipated update on its efforts to deal with the fallout of the TLD Application System security bug merely deferred resolution of the problem for a week. Again.
The whole program is now essentially a month behind schedule.
Chief operating office Akram Atallah said in a statement:

ICANN will notify all applicants within the next seven business days whether our analysis shows they were affected by the technical glitch in the TLD application system.
…
Shortly after the notification process has been completed, we will announce the schedule for reopening the application system and completing the application period. We are mindful of the need to allow sufficient time during the reopening period for applicants to confirm the completeness of their submissions.

The seven business days for applicant notifications takes us to May 8.
It’s not clear whether TAS would reopen immediately after this, but I suspect we’re probably looking at a buffer of at least a day or two between the end of notifications and TAS coming back online.
ICANN has previously said that TAS will be open for five business days, to enable applicants to finish off their applications. This brings us to, at the very earliest, May 15.
The Big Reveal of the list of applications, I estimate, will come one to two weeks after that.
We’re essentially looking at a late May or early June finish to a process that should have ended in late April.
As a result, the entire timetable for evaluating, approving and delegating new gTLDs will likely also be pushed out by a month.
For applicants, the anticipated November 12 date for the completion of the first-batch Initial Evaluation phase is now likely to come some time in mid-December instead.
Unhelpfully, the deadlines for filing objections and requesting Extended Evaluation for first-batch applicants is now likely to fall around about January 1, 2013.
That’s assuming we do not see any more delays, of course, which I think would be optimistic.

ANA demands TAS bug probe

Never one to miss the chance for a bit of trouble-making, the Association of National Advertisers has demanded a full independent probe into ICANN’s TLD Application System bug.
Writing to ICANN today, ANA president Bob Liodice has pointed to the TAS outage – now in its 13th day – as an example of why the new gTLD program needs to be scaled back.
“Doesn’t this situation demonstrate the need for a pilot project/test roll-out of the new Top Level Domain process to resolve any such problems before a major roll-out?” he asks.
In a press release, he added:

We are urgently requesting that the Department of Commerce and its National Telecommunications and Information Administration (NTIA) exercise their oversight of ICANN and encourage ICANN to engage an independent IT expert to fully investigate this serious and inadequately explained vulnerability.

The ANA has of course been the loudest objector to the program, forming the Coalition For Responsible Internet Domain Oversight last year to lobby against the gTLD expansion.
Liodice’s latest letter puts 10 questions to ICANN, several quite sensible and precisely the kinds of things I plan to ask just as soon as ICANN changes its mind about doing media interviews.
But it also asks for the release of information ICANN has already provided or has said it intends to provide, such as the number of affected TAS users or the date of the first reported incident.
The ANA also does not appear to be aware that the ICANN board new gTLD subcommittee recently passed a resolution calling for more work on the defensive registration problem.
Liodice notes that ICANN has not responded to its demands for a “Do Not Sell” list that would enable brand owners to block others from registering their trademarks in the DNS.
You can read the letter in PDF format here.
ICANN currently plans to provide its next big update on the TAS outage before the end of Friday.

ICANN will alert gTLD security bug victims

ICANN plans to inform each new top-level domain applicant whether they were affected by the security vulnerability in its TLD Application System, according to its latest update.
The organization has also confirmed that it is still targeting April 30 for the Big Reveal day, when it publishes (deliberately) the gTLDs being applied for and the names of the applicants.
This morning’s TAS status update, penned by chief operating officer Akram Atallah, does not add much that we did not already know about the data leakage bug. It states:

An intensive review has produced no evidence that any data beyond the file names and user names could be accessed by other users.
We are currently reviewing the data to confirm which applicants were affected. As soon as the data is confirmed, we will inform all applicants whether they were affected.

ICANN staff and outside consultants have been working all weekend to figure out what went wrong, who it affected, and how it can be fixed.
The organization still intends to announce tonight whether it has fixed the problem to the point where it’s happy to reopen TAS to registered users tomorrow. It’s also sticking to is Friday extended submission deadline.