DNS genius and ICANN key-holder Dan Kaminsky dies at 42

Security researcher Dan Kaminsky, best known for uncovering the so-called “Kaminsky Bug” DNS vulnerability, has reportedly died at the age of 42.

It has been widely reported that Kaminsky’s niece confirmed his death from serious complications from his longstanding diabetes.

On Twitter, she rebutted emerging conspiracy theories that his death was linked to the coronavirus vaccine, which he had received April 12, saying her uncle would “laugh” at such views.

During his career as a white-hat hacker, Kaminsky worked for companies including Cisco, Avaya, and IOActive.

He occasionally spoke at ICANN meetings on security issues, and was since 2010 one of IANA’s seven Recovery Key Share Holders, individuals trusted to hold part of a cryptographic key that would be used to reboot root zone DNSSEC in the case of a massive disaster.

But he was best known for his 2008 discovery of a fundamental flaw in the DNS protocol that allowed cache poisoning, and therefore serious man-in-the middle attacks, across millions of name servers worldwide. He worked with DNS software vendors in private to help them with their patches before the problem was publicly disclosed.

His discoveries led in part to the ongoing push for DNSSEC deployment across the internet.

The vulnerability received widespread attention, even in the mainstream media, and quickly came to bear his name.

For me, my standout memory of Kaminsky is one of his series of annual “Black Ops” talks, at the Defcon 12 conference in Las Vegas in 2004, during which he demonstrated to a rapt audience of hackers how it was possible to stream live radio by caching small chunks of audio data in the TXT fields of DNS records and using DNS queries to quickly retrieve and play them in sequence.

As well as being a bit of a DNS genius, he knew how to work a stage: the crowd went mental and I grabbed him for an interview soon after his talk was over.

His death at such a young age is a big loss for the security community.

IP lobby demands halt to Whois reform

Trademark interests in the ICANN community have called on the Org to freeze implementation of the latest Whois access policy proposals, saying it’s “not yet fit for purpose”.

The Intellectual Property Constituency’s president, Heather Forrest, has written (pdf) to ICANN chair Maarten Botterman to ask that the so-called SSAD system (for Standardized System for Access and Disclosure) be put on hold.

SSAD gives interested parties such as brands a standardized pathway to get access to private Whois data, which has been redacted by registries and registrars since the EU’s Generic Data Protection Regulation came into force in 2018.

But the proposed policy, approved by the GNSO Council last September, still leaves a great deal of discretion to contracted parties when it comes to disclosure requests, falling short of the IPC’s demands for a Whois that looks a lot more like the automated pre-GDPR system.

Registries and registrars argue that they have to manually verify disclosure requests, or risk liability — and huge fines — under GDPR.

The IPC has a few reasons why it reckons ICANN should slam the brakes on SSAD before implementation begins.

First, it says the recommendations sent to the GNSO Council lacked the consensus of the working group that created them.

Intellectual property, law enforcement and security interests — the likely end users of SSAD — did not agree with big, important chucks of the working group’s report. The IPC reckons eight of the 18 recommendations lacked a sufficient degree of consensus.

Second, the IPC claims that SSAD is not in the public interest. If the entities responsible for “policing the DNS” don’t think they will use SSAD due to its limitations, then why spend millions of ICANN’s money to implement it?

Third, Forrest writes that emerging legislation out of the EU — the so-called NIS2, a draft of a revised information security directive —- puts a greater emphasis on Whois accuracy

Forrest concludes:

We respectfully request and advise that the Board and ICANN Org pause any further work relating to the SSAD recommendations in light of NIS2 and given their lack of community consensus and furtherance of the global public interest. In light of these issues, the Board should remand the SSAD recommendations to the GNSO Council for the development of modified SSAD recommendations that meet the needs of users, with the aim of integrating further EU guidance.

It seems the SSAD proposals will be getting more formal scrutiny than previous GNSO outputs.

When the GNSO Council approved the recommendations in September, it did so with a footnote asking ICANN to figure out whether it would be cost-effective to implement an expensive — $9 million to build, $9 million a year to run — system that may wind up being lightly used.

ICANN has now confirmed that SSAD and the other Whois policy recommendations will be one of the first recipients of the Operational Design Phase (pdf) treatment.

The ODP is a new, additional layer of red tape in the ICANN policy-making sausage machine that slots in between GNSO Council approval and ICANN board consideration, in which the Org, in collaboration with the community, tries to figure out how complex GNSO recommendations could be implemented and what it would cost.

ICANN said this week that the SSAD/Whois recommendations will be subject to a formal ODP in “the coming months”.

Any question about the feasibility of SSAD would be referred back to the GNSO, because ICANN Org is technically not supposed to make policy.

Amid .club boom, one AV vendor is blocking the whole damn TLD

.club may be experiencing a mini-boom in sales due to the popular new Clubhouse app, but one antivirus vendor has reportedly decided to block the entire TLD.

According to Forbes, the free MalwareBytes Browser Guard plug-in will warn users attempting to visit .club sites that it’s a “suspicious top-level domain”, adding that .club is “frequently used by scam or phishing sites, but can be used by legitimate websites as well”.

Users can click through to dismiss the warning and visit the site if they choose.

It seems a lot like overkill or an algorithmic glitch to me — .club has never been a particularly malware-friendly TLD. According to SpamHaus, only 0.9% of the .club domains that it’s seen in the wild could be considered “bad”.

After a disappointing second half of 2020, which saw about 300,000 domains disappear from its zone file, .club has seen a bit of a recovery in the last two weeks, largely due to a popular new audio social media app called Clubhouse.

Since the app started getting media attention earlier this month, .club has become the latest TLD hit by domain investor speculation with .CLUB Domains CEO Colin Campbell describing sales on January 15 as “absolute pandemonium”.

While .club has added about 30,000 domains to its zone since then, it’s not yet enough to counteract last year’s decline in volume. Luckily for .CLUB, many of its sales have been of premium-priced names.

It’s unlikely that these latest registrations are related to the MalwareBytes block.

ICANN apologizes to “arms dealer” claim security firm after email goes missing

ICANN has apologized to the security company that claimed an accredited registrar was in league with malware distributors, after an email went AWOL.

You may recall that registrar GalComm was accused by Awake Security last month of turning a blind eye to abuse in a report entitled “The Internet’s New Arms Dealers: Malicious Domain Registrars” and that ICANN’s preliminary investigation later essentially dismissed the allegations.

ICANN had told GalComm (pdf) August 18 that Awake had not “to date” contacted ICANN about its allegations, but that appears to have been untrue.

GalComm’s lawyers had in fact emailed a letter to ICANN, using its “globalsupport” at icann.org email address, on August 6, as said lawyers testily informed (pdf) Global Domains Division VP Russ Weinstein August 20.

Weinstein has now confirmed (pdf) that a letter from Awake was received to said email address but “was not escalated internally”. He said he was “previously unaware” of the letter. He wrote:

I apologize for this inadvertent oversight and we will use this as a training opportunity to prevent such errors in the future.

GalComm has been threatening to sue Awake for defamation since the “arms dealer” report was published, so it looks like ICANN’s decision to eat humble pie is probably a prudent way to keep its name off the docket.

The letter from Awake’s lawyers (pdf) also includes a lengthy explanation of why the original report is not, in its view, defamatory.

The lesson for the rest of us appears to be that the ICANN email address in question is probably not the best way to reach ICANN’s senior management.

Weinstein said that abuse complaints about registrars should be sent to its “compliance” at icann.org address.

“Arms dealer” registrar probed by ICANN

ICANN’s top security thinkers are looking into hotly denied claims that an Israeli registrar collaborated with malware distributors.

Luckily for the registrar, GalComm, so far they’ve come up empty-handed and ICANN has told the company it does not consider it “malicious”.

ICANN told GalComm this week that its Security, Stability and Resiliency team is looking into a report published by security consultancy Awake Security in June entitled “The Internet’s New Arms Dealers: Malicious Domain Registrars”.

The report connected GalComm to over 100 malicious browser extensions, used to steal data, that have been installed 33 million times. GalComm was apparently the attackers’ registrar of choice.

While Awake did not report the registrar to ICANN, GalComm took it upon itself to write to ICANN to deny the allegations, saying that it merely acted as a neutral registrar and had no involvement in hosting or distributing the malware.

It also demanded that Awake retract its report and apologize or face legal consequences. The report is still available.

Now, ICANN has written back (pdf) to assure the registrar that its investigations to date has been “unable to corroborate the findings Awake Security presented and it does appear that Awake Security had an inaccurate picture of the total domains under management by GalComm”.

It added that the investigation is ongoing, however:

Based on the information we have been able to obtain to date, we have no reason to believe it appropriate for GalComm to be considered a “malicious domain registrar” as asserted by Awake Security. However, as noted in Awake Security’s report, the malicious actors behind the domains in question may be utilizing detection evasion techniques. As such, our investigations continue, and we appreciate GalComm’s cooperation and support of those investigations.

ICANN has previously told news outlets that it receives very few complaints about GalComm, none related to malware.

“Horrifying” Zoombombing attack on ICANN meeting, again

ICANN’s eleventh-hour decision to remove password requirements for ICANN 68 was proved wrong almost immediately after the meeting got underway on Zoom today.

According to participants and ICANN itself, several sessions were “zoombombed” this morning, with apparently pornographic content.

Zoombombing is where trolls disrupt public, open Zoom meetings with content designed to offend.

ICANN 68 is taking place on Zoom, but on Kuala Lumpur time. I was asleep during the attacks and ICANN has yet to post the recordings of any of today’s sessions, so I can’t give you any of the details first-hand.

But judging by a handful of social media posts that reference the attack, it seems to have been pornographic in nature. ICANN said it comprised “audio, images and video”.

One participant described it as “funny at first…until it was not”, while another said it was “horrifying” and left her feeling “completely vulnerable”.

ICANN said in a blog post that the trolls were swiftly removed from the sessions.

It added that it has changed the format of the remainder of ICANN 68, unplugging certain interactive components and requiring passwords to be entered before access is granted.

This means you’re going to have to register for each session and click emailed confirmation links, it appears.

Only the Governmental Advisory Committee is staying on the platform with its original vulnerable configuration.

ICANN had been planning to require passwords since a similar attack at an inter-sessional meeting in March, but changed its mind last week after security upgrades made by Zoom gave leaders a greater sense of confidence in the platform.

It appears that confidence was misplaced.

You won’t need a password for ICANN 68 after all

ICANN has ditched plans to require all ICANN 68 participants to enter a password whenever they enter one of the Zoom sessions at the meeting next week.

The org said today that it will use URLs with embedded passwords, removing the need for user input, after reviewing changes Zoom made last month.

These included features such as a waiting room that enables meeting hosts to vet participants manually before allowing them to enter the meeting proper.

ICANN said: “Please use these links cautiously, only share them on secure channels such as encrypted chat or encrypted e-mail, and never post them publicly.”

ICANN had said last month, before the Zoom changes, that it would require passwords in order to limit the risk of Zoombombing — where trolls show up and spam the meeting with offensive content. One ICANN Zoom session had been trolled in this way in March.

The org also said today that participants will be asked to give their consent to be recorded upon entry to a session.

“It is our hope that this small change empowers attendees by providing quick access and more control over the acceptance of our policies as it relates to attending virtual meetings,” ICANN lied, to cover for the obvious piece of legal ass-covering.

Refuse consent and see how far you get.

Irony alert! Data protection agency complains it can’t get access to private Whois data

A European data protection authority has complained to ICANN after a registrar refused to hand over one of its customers’ private Whois records, citing the GDPR data protection regulation, according to ICANN.

Compounding the irony, the DPA wanted the data as part of its probe into an alleged GDPR violation at the domain in question.

This is the frankly hilarious scenario outlined in a letter (pdf) from ICANN boss Göran Marby to Andrea Jelinek, chair of the European Data Protection Board, last week.

Since May 2018, registrars and registries have been obliged under ICANN rules to redact all personally identifiable information from public Whois records, because of the EU’s General Data Protection regulation.

This has irked the likes of law enforcement and intellectual property owners, who have found it increasingly difficult to discover the identities of suspected bad actors such as fraudsters and cybersquatters.

Registrars are still obliged to hand over data upon request in certain circumstances, but the rules are vague, requiring a judgement call:

Registry and Registrar MUST provide reasonable access to Personal Data in Registration Data to third parties on the basis of a legitimate interests pursued by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject pursuant to Article 6(1)(f) GDPR.

While an ICANN working group has been attempting to come up with a clearer-cut set of guidelines, administered by a central body, this so-called SSAD (System for Standardized Access/Disclosure) has yet to come to fruition.

So when an unidentified European DPA recently asked a similarly unidentified non-EU registrar for the Whois data of somebody they suspected of GDPR violations, the registrar told it to get stuffed.

It told the DPA it would “not act against a domain name without any clear and unambiguous evidence for the fraudulent behavior” and said it would respond to legal requests in its own jurisdiction, according to ICANN.

The DPA complained to ICANN, and now ICANN is using that complaint to shame the EDPB into getting off the fence and providing some much-needed clarity about when registrars can declassify Whois data without breaking the law.

Marby wrote that registrars are having to apply their “subjective judgment and discretion” and will most often come down on the side of registrants in order to reduce their GDPR risk. He wrote:

ICANN org would respectfully suggest to the EDPB that a more explicit recognition of the importance of certain legitimate interests, including the relevance of public interests, combined with clearer guidelines on balancing, could address these problems.

…

ICANN org would respectfully suggest to the EDPB to consider issuing additional specific guidance on this topic to ensure that entities with a legitimate interest in obtaining access to non-public gTLD registration data are able to do so. Guidance would in particular be appreciated on how to balance legitimate interests in access to data with the interests of the data subject concerned

ICANN and the EDPB have been communicating about this issue for a couple of years now, with ICANN looking for some clarity on this largely untested area of law, but the EDPB’s responses to data have been pretty vague and unhelpful, almost as if it doesn’t know what the hell it’s doing either.

Will this latest example of the unintended consequences of GDPR give the Board the kick up the bum it needs to start talking in specifics? We’ll have to wait and see.

After Zoom trolling, ICANN 68 will be password-protected

If you want to show up to ICANN 68, which will be held online next month, you’re going to need a password.

ICANN said this week that it’s updating its Zoom software and standard configuration to require passwords. In a blog post outlining a number of changes to its Zoom instance, ICANN said:

The most impactful change is the new requirement that all meetings be secured with a password. This is the first step recommended by security professionals to keep meetings secure, and one which we had largely adopted org-wide prior to making it a requirement for all. We will make another announcement in the coming weeks regarding how this may impact joining meetings during ICANN68, as we work towards the best overall solution.

Quite how this could work while maintaining the usual openness of ICANN’s public meetings — which have always been free to attend basically anonymously — remains to be seen.

At ICANN 67, Zoom sessions that were open to the public simply required you to enter a name. Any name. At in-person public meetings, I don’t think you even need to show ID to get a hall pass.

The changes come in the wake of a “Zoombombing” incident during a minor meeting in March, during which trolls showed up via a publicly-posted link and flooded the session with “inappropriate and offensive” audio and imagery.

ICANN meeting got “Zoombombed” with offensive material

An ICANN meeting held over the Zoom conferencing service got “Zoombombed” by trolls last month.

According to the organization, two trolls entered an ICANN 67 roundup session for Spanish and Portuguese speakers on March 27 and “shared inappropriate and offensive audio and one still image” with the legitimate participants.

The session was not password protected (rightly) but the room had (wrongly) not been configured to mute participants or disable screen-sharing, which enabled the offensive material to be shared.

The trolls were quickly kicked and the loopholes closed, ICANN said in its incident report.

ICANN appears to have purged the meeting entirely from its calendar and there does not appear to be an archive or recording, so I sadly can’t share with you the gist of the shared content.

Zoombombing has become an increasingly common prank recently, as the platform sees many more users due to the coronavirus-related lockdowns worldwide.