01/14/2010 03:18:15 PM

Trekkies will recall an episode in the original Star Trek series called The Doomsday Machine. The episode describes an encounter with, and ultimate destruction of, a machine that smashes planets which it consumes to fuel its journey from galaxy to galaxy.

I watched Star Trek faithfully as a teen. This episode intrigues me still. Why? Forty years later, The Doomsday Machine has an Internet analog, a fine example of life imitating art. In the Star Trek episode, beings from outside the galaxy constructed the planet eater as a deterrent, with no intention of actually unleashing it, and it appears to have consumed its galaxy of origin. In real life, the Internet community must contend with a Cyber Doomsday Machine, e-crime, that feeds on security flaws rather than planets, and this machine is on the verge of destabilizing the Internet.

The Star Trek Doomsday Machine looks like a giant metal worm. The Cyber Doomsday Machine is a worm of a different but similarly malevolent kind: a spawn of the criminal underworld, a vast array of networks of compromised computers called “botnets”. Botnets are herded by one set of criminals and leased to other criminals to facilitate fraud, theft, denials of services and other for-profit criminal enterprises today, and they are just as capable of enabling now and future cyber-warfare and cyber-terrorism. .

The Cyber Doomsday Machine corrupts from within. Botnet numbers can be deceiving: a net of as few as 5-10 bots can inflict considerable harm, undermining the security, stability and integrity of the Internet in a variety of ways:

Domain name registrations. Domain name registrars and resellers are particularly attractive targets for the Cyber Doomsday Machine. Registrar verification practices vary considerably. Lax practices allow attackers to steal identities and fraudulently use credit cards. When registrars place a premium on high transaction rate requirements for initial domain registration process, they often do so at the expense of measures that could result in the collection of more accurate registrant information. Proof of identity required? Nope. Confirmation that the email address submitted reaches a human? Nope. Does the registrant contact information match the contact information for the credit card used for the transaction? Not exactly. Even if the registrar does some checking, the attacker will try to change it later. Subsequent domain account support services (e.g., renewal or reconfiguration) depend nearly entirely on email corrspondence. This create opportunities for automated attacks from botnets: phishers impersonate registrars to lure a domain account holder into disclosing domain accounts. The unauthorized domain account access that follows typically results in domain hijacking, and DNS reconfiguration to support double flux attacks.

Name Service. The DNS and domain name registration services are under the most serious attacks. The Kaminsky exploit, DNS response modification, open resolvers, orphaned DNS records, double flux attacks, and attacks that undermine SSL via DNS are chipping away at the reliability and credibility of domain name resolution. Many such attacks employ botnets. DNSSEC is designed to mitigate many of these threats, but deployment is ponderously slow. Even if every top level domain zone were signed and ready to sign subordinate zones, there is no evidence yet that registration services will improve verification measures. Unless registrars uniformly improve registrant verification, there is a real danger that attackers will be able to ask and have their zone data signed. Experts may rightly say that distinguishing attackers from legitimate users is not “in scope” for DNSSEC, but I frankly don’t get a warm feeling when I’m told that a DNSSEC response will assure me that the resource records I’ve received contain exactly the data an attacker intended me to receive.

IP version 6. IPv6 is for practical purposes out of sensor range for most users and businesses but not for bot-based attacks. Indeed, some claim that the underground may be better prepared to deploy IPv6 than legitimate users. Bot herders have successfully injected malware onto incorrectly configured computers by tunneling IPv6 traffic past IPv4 intrusion detection systems for some time. The grim picture is that at the very least, the bad guys have some experience with IPv6. They don’t have to consider the risk in deploying v6 with fewer and less effective security services than are available for v4 networks. Moreover, they have a jump on many net admins by having already studied IPv6 enough to learn what security systems can be evaded. At the very worst, they have a green field of unexplored opportunities presented by a technology that is unfamiliar to most users and businesses, complicated, and has not been tested in the field anywhere close to the same extent and scale as IPv4.

Homograph attacks. The growing use of characters from local languages and scripts is evident on many if not most Internet web pages. Support for characters from local scripts at all levels of fully qualified domain names is an important step towards providing a complete “my language” experience for all users. IDN will no doubt extend the reach of the Internet to an even broader set of users. Bad news accompanies this good event. There are no policies in place for usage and display of domain registration data. The anticrime community may not be able to investigate attacks thoroughly and quickly when registration records may be recorded and displayed in 100s of character sets. “Internationalization” of the ‘net has and will continue to be an attractive fuel for the Cyber Doomsday machine. Internationalized domain names will undoubtedly be the target of intense scrutiny as bot-based attacks are likely to insert visually similar or unfamiliar glyphs in domain names to dupe users in traditional and as yet unseen IDN homograph attacks.

In The Doomsday Machine, the Star Ship Enterprise responds to intergalactic distress calls to halt the progress of the planet eating leviathan. Spock determines that a thermonuclear detonation of a Star ship’s impulse engines will destroy the Doomsday Machine. Kirk mans the helm of a damaged sister ship of the Enterprises and escapes at the last moment before the explosion destroys the Doomsday Machine. Is there a similar dramatic conclusion for The Cyber Doomsday Machine?

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:-)