The Security Skeptic

The typical security presentation invariably has a once clever, now tired, firewall icon. Marcus Ranum knows a fair bit about firewalls, and contends that not only does the conventional icon fail to convey "firewall" to the uninformed, it "looks like something a cat would sleep on".

Marcus claims that if you really want to convey "fire" wall, you need some fire. Visit Marcus' page, The Ultimate Firewall, and consider one of the compelling visuals you'll find in this article for your next security presentation. Alternatively, you can clear some open space, gather some flammable material and #2 Diesel fuel, and roll your own...

Archived at http://www.securityskeptic.com/arc20090301.htm#BlogID724 by Dave Piscitello  

Shining a humorous light on IPv6 Adoption to attract a large, interested audience is a laudable effort. But technology, like humor, resonates with some audiences and not others. For example, picture a British comedian doing a 10 minute stand up routine about cricket for the residents of Azure, Montana in January: not a lot of folks around, fewer who'll attend, fewer still who'll have a clue what cricket is, and even fewer who'll care. The witty Brit has a better shot at finding an appreciative audience if he performs at the London or Marylebone Cricket clubs.

Lesley Daigle's slide, Today's Topic

It's no surprise, then, that the Internet Society chose to host an expert panel to discuss the need to adopt Internet Protocol version 6 at the 74^th meeting of the IETF. The IETF is unquestionably a better venue than Azure to discuss IPv6. The number of IETF attendees is greater than the number of residents in Azure. Many will attend, some merely to congratulate themselves again for advancing the version number 15 years ago. A fair number of them know what IPv6 is, and some portion of those who know, care. The panel experts offered a number of interesting comments:

• Jari Akko posited that "most of the deployment effort is practical: training, vendors, plans, configuration".
• Lorenzo Colitti suggested "Do it in stages: IPv6 needn't be as capable as IPv4 on day one".
• Alain Durand explains how we must acknowledge that IPv4 - and IPv4 only hosts - will be around for a very long time so we need an IPv6 transition bridge. Kurtis Lindqvist corroborated Alain's claim, saying "the gap between IPv4 “islands” and IPv6 “ islands” needs to be bridged". Both discuss a dual-stack Lite" scenario, where stub networks use and share IPv4 addresses to gateways that support IPv4/IPV6 tunneling and provider NAT.
• Sebastian Bellagamba suggested that governments set up an industry/government/academic outside group of advisors and tasking them with producing an action plan and talk to their IT suppliers to ensure continuity of supply in the transition to IPv6.

I confess that I'm left a bit empty by the presentations and would have asked a few questions had I been in the audience:

• Jari, isn't it both late in game and disingenuous to dismiss the expensive and time consuming aspects of building networks as merely the "practical matters"? Why hasn't the outreach from RIRs and IETF moved beyond lamenting IPv4 address exhaustion to include training and deployment/configuration best practices over the past five years?
• Lorenzo, IPv4 is a lamentable mess with respect to security yet you suggest v6 needn't be as capable? I can't imagine any organization stepping from the frying pan into the fire. Comments like this are more likely to stimulate an IPv4 black market than IPv6 adoption.
• Alian and Kurtis, thanks for showing some common sense by acknowledging the long tail *and* NAT, can you please shake the same sense into the heads of the "you must adopt IPv6 pervasively to restore the end-to-end communications model" zealots? They are scaring my users.
• Sebastian, isn't IETF the "industry/government/academic outside group of advisors"? It was 20 years ago. Where's the action plan, folks? More importantly, why haven't governments been insisting on IPv6 for the last 10 years?

I know the answer. So does Russ...

Russ? Only Russ Housley among the expert panelists understands the real problem. I saved Russ Housley's comment for last: "until the IPv4 addresses are actually scarce, there is little economic incentive to actually deploy IPv6". This is truer in today's economic crisis than in years past and the clock is ticking. Fortunately, even at the eve of exhaustion, there's good reason to believe IPv6 adoption will succeed. The single biggest reason for optimism that IPv6 will work is that it really didn't push the envelope past IPv4 in the most critical areas: DNS and routing. IPv6 is simply not that different from IPv4 that it will take eons to deploy. The IETF might have made the situation less urgent by dealing with mundane, "practical" matters. The IPNG winners could have taken fewer victory laps and paid more attention to a tractable transition plan. But in fairness, the IETF and in general folks who do standards don't always decide which projects to fund. So we come full circle, and arrive again at Russ' assertion that there's no economic incentive to deploy IPv6.

Of course, we are experiencing an unusual economic time, and the rallying cry of every economist seems to be "stimulus". Only scant months ago,the Internet Security Alliance urged the Obama administration to assist in securing the nation’s cyber infrastructure by providing market incentives (see my blog #714). While governments get serious about securing the infrastructure, surely they could earmark a few billion more so that the infrastructure provides connectivity to the next generation of users, including the next gen inhabitants of Azure, Montana. Think of the jobs, the spending, the stimulus!

Archived at http://www.securityskeptic.com/arc20090301.htm#BlogID723 by Dave Piscitello  

Colleague Laura Mather begins a series of blogs describing how e-crime affects people every day. Laura makes an important observation at the outset of this series. Online scams are highly sophisticated now. In the past, security pundits could look at an e-scam and pompously conclude, "Jeez, only an idiot could fall for that". Today, educated, intelligent and computer-savvy individuals are *targets* because they usually have savings, assets, or credit. The criminals recognize they are smarter than the low hanging fruit and they've spiced up their attacks to deceive this more cautious, thoughtful class of victims.

Laura will highlight two cases of fraud in this series: a Nigerian inheritance scam and an online work-from-home drop-ship scam. My reaction is, "An educated, intelligent, computer savvy individual fell for one of these?" I'm eager to learn more. I encourage you to visit Silver Tail Blog, read Laura's introduction, and look for the case studies as Laura publishes them.

Archived at http://www.securityskeptic.com/arc20090301.htm#BlogID722 by Dave Piscitello  

In Part 1 of this series, I borrowed the antagonist from a Star Trek episode, the Doomsday Machine, and 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 to late to add to the fleet. And it's common knowledge that defense spending will generate jobs and stimulate the economy:-)

Archived at http://www.securityskeptic.com/arc20090301.htm#BlogID720 by Dave Piscitello  

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?

Archived at http://www.securityskeptic.com/arc20090301.htm#BlogID719 by Dave Piscitello  

When a first responder or law enforcement agent identifies a phishy or spammy domain name, they often check WHOIS to see who's registered the name. Often, the contact information they find is incomplete or inaccurate. At this point, the responder or LEA tries to contact the sponsoring registrar identified in the WHOIS. This field is populated by the registrar and is mostly accurate. The registrar is in the strongest position to suspend the domain name. Unfortunately, getting contact information for someone at a registrar who can handle abuse and criminal complaints is not always easy; in fact, in some cases it's ridiculously hard.

ICANN's SSAC has written a recommendation that "registrars should publish abuse contact information, that the information a registrar publishes for the abuse point of contact should reach staff able to process an abuse claim, and that registrars make the information available in a uniform, machine readable format. Lastly, SSAC recommends that ICANN maintain a public repository for registrar abuse points of contact and should periodically verify that the contact information is accurate." I gave a short presentation at the ICANN meeting in Mexico City on this recommendation. During the Q&A, some registrars objected to the recommendation, claiming that a published abuse contact email would get a lot of spam. Many registrars already publish abuse point of contact information. Some were in attendance for my presentation and none indicated that spam interfered with their abuse operations. We all get spam and deal with it with varying degrees of success. I can't imagine that any registrar is incapable of filter spam delivered to abuse@registar.tld. I hope the ICANN community will adopt the recommendation and that all registrars will help expedite phish domain takedowns.

Archived at http://www.securityskeptic.com/arc20090301.htm#BlogID721 by Dave Piscitello