The Cyber Doomsday Machine (Part 2)

In Part 1 of this article, I borrowed the antagonist from a Star Trek episode, the Doomsday Machine.

I introduced its corrollary in the Cyber world: the malevolent spawn of the criminal underworld we know as botnets. I explained how the machine fuels itself by exploiting security flaws and described several of the common and likely to be sought fuels for criminal attacks: Domain registration services, DNS (name service), IPv6, and homograph attacks. In Part 2, I identify actions the community must take to stave off destruction:-)

In The Doomsday Machine, the crew of the Star Ship Enterprise saves the day. In the Cyber version, no one is putting up enough of a defense. Measures that might prevent the Cyber leviathan from continuing to destabilize the Internet (or at least contain it) are known and not put into motion, including:

Secure domain registrations. Successful attacks against Comcast, CheckFree and other highly targeted domain accounts illustrate how much remains to be done to improve registration security measures and defeat social engineering and registrar phishing. The volumes of phish and spam registrations identified daily by APWG, PhishTank, Spamhaus, et. al., expose the less than adequate fraud protection measures employed by some registrars. To be clear, a good many registrars implement APWG and other registrar best practices to deter criminals. These companies are fighting the good fight and deserve applause. However, best practices are not uniformly embraced nor mandated through policy or contract, so the crooks take their business to a small but problematic number of registrars and resellers who, according to an ICANN GNSO report, lack competency and are unwitting participants in criminal activities, or appear to facilitate attacks. The conclusions from this report are corroborated by annual reports in which certain registrars have repeatedly been "named and shamed" as spam- and phishing-friendly.

What can be done? Registrars must improve verification measures at the time of registration. Confirmation of the registrant's email address is simple and obvious; seriously, will any registrant other than a miscreant really mind waiting a few minutes, visiting a confirmation URL and entering in a CAPTCHA response? Credit card verification should improve as well. Why not disallow third party use of a credit card unless verbal confirmation is obtained from the card holder's telephone number? Similar or additional measures could be introduced to protect domain accounts from DNS misuse and fraudulent transfer of domains. The ICANN and Internet communities must convince registrars that the entire registrar/reseller community has to take significant measures to prevent registration abuse uniformly or the communities must approve policy to require that they do so. The communities should also acknowledge that there's a cost to registrars and that domain holders are willing to pay more per registration so registrars can implement stronger protective measures. Raising the price of a domain isn't heresy. It's a good long term investment in a secure global name space and the cost is recoverable. Most Internet users and domain account holders understand that the values of their domain names far exceed the pittance they pay to register domains annually. Registrants and users like are all too familiar with how much damage and financial loss an attacker can inflict with a $1.99 domain name, especially when he's using false credentials or stolen credit cards to do so.

Secure the DNS. DNS name service operators must establish and implement best practices so that response modification, open recursion and orphaned DNS records are removed from the attacker's toolkit. Build from the recent increased interest in DNSSEC deployment (IANA has implemented an interim trust anchor, ITAR, dot gov is signed, and dot org is nearly there) and urge other gTLDs and ccTLDs to follow suit. Take note that the success of DNSSEC hinges on more secure registration services. Registrars must take the task of distinguishing good actors from bad from Internet users by assuring that zone data are not signed without sufficient credentials to prevent fraud, impersonation, or misuse.

Ask for IPv6. The fact that I am saying this says a great deal. I'm on record as an IPv6 Doubting Thomas. But the opportunity to choose an alternative has slipped away. Unfortunately, IPv6 has little besides "more address space" going for it, and despite distress signals calling attention to the depletion of the IPv4 space and the challenge of deploying a secured IPv6 infrastructure[1, 2], security technology vendors continue to ignore the rapid depletion of the IPv4 address space, arguing that the market isn't calling for IPv6. The possibility that the market's not migrating to IPv6 because users are reluctant to do so without security products is apparently not a sufficiently compelling argument, especially during an economic crisis. ICSA and other certification groups can play an important role by establishing a time line for IPv6 security readiness and a date beyond which firewalls and other security products tested must provide the equivalent features for IPv4 and IPv6 to continue to receive certification. Government procurement agencies and businesses should point to the certification time line and accept no products that are not IPv6 ready-to-secure.

Homograph attacks. All registries should implement ICANN IDN guidelines and disallow registration of domain names that use mixed scripts. These rules can only be enforced on TLD and second level labels. DNS hosting providers could help by applying the guidelines to 3rd level labels of domain names registrants attempt to include in zone files the registrar manages; specifically, if a registrar hosts the zone information for example.net, and the customer attempts to create an A record for a FQDN of the form <mixed.script>.example.net, the registrar ought to block this. Subdomain registration services should also adopt these to prevent further exploitation of third level labels. I'm out of my field here but I imagine there must be an opportunity for application and OS developers to distinguish products by providing measures to protect users from homograph attacks (essentially, detection software that alerts a user when mixed scripts appear in email, URLs, etc). Broad adoption of defenses of this sort of attack requires three investments we rarely make: time, education, and constant vigilance.

This is a daunting list. It may take an entire fleet of Star ships to tame the Cyber Doomsday Machine. It's not too late to add to the fleet. And it's common knowledge that defense spending will generate jobs and stimulate the economy:-)

Comments

[The Security Skeptic]

thanks for catching the typo, hope you enjoyed the article.