The Security Skeptic

My ICANN SSAC committee published an advisory in June describing how phishers were impersonating domain name registrars and resellers. A registrar-impersonating phisher tries to lure a registrar's customer to a bogus copy of the registrar's customer login page. If the bogus registration page is a convincing one, the customer may unwittingly disclose his account credentials. The phisher will then use these credentials to modify or assume ownership of the customer's domain names.

Phishers use an anticipated correspondence from registrars and resellers as the lure, such as a domain name order confirmation, DNS modification confirmations and WHOIS data accuracy reminders. In some cases, it appears that phishers will attempt to impersonate ICANN rather than registrars or resellers.

Here's a sample of a recent phishing attack where the phisher attempted to impersonate ICANN:

From: ICANN [mailto:icann at icannresolve dot com]
Sent: Tuesday, June 24, 2008 12:22 AM
To: [REDACTED]
Subject: ICANN - Domain Upgrade Notice

Dear Domain Account Holder,

You are being sent this notice from ICANN due to the fact that you
currently own an active domain name. ICANN is currently upgrading all
domains from their registry database.

The upgrade will introduce new control options for your domain and
easier access. The new upgrade is required by the registry. All domain
users are expected to submit their domain information manually at
http://www dot icannresolve dot com/email/link.php?M=27952&N=5&L=1&F=T with the
required information for ICANN to apply the required updates.

The upgrades will be applied to accounts on a first come, first serve
basis. You have until July 25, 2008 to submit the required information
to avoid service and domain interruption.

Thank you for your time.

Sincerely,

ICANNResolve
ICANN.org Resolutions Department

This turned out to be a rather pheeble phish attempt. Domain portfolio holders who recognize the name ICANN are most likely to detect that this message is bogus. Those domain name holders who don't recognize ICANN would have been more likely to fall prey to this attack if the phisher had impersonated an ICANN-Accredited Registrar. A recipient of this scam message who did visit the embedded link would have landed on the following forms page:

This page is not a domain account management page but a faked copy of the ICANN Paris Meeting registration page.

If only all phishers were this lame. Sadly, as lame as this attack seems, some recipients were duped into disclosing all the information requested at the hoax site.

Archived at http://www.securityskeptic.com/arc20080801.htm#BlogID702 by Dave Piscitello  

Eugene Schultz wrote a nice piece in the August 2008 issue of the ISSA Journal on Identity Management. What I like about this particular article is that it is it's neither hype nor hard sell. Instead, Schultz gets to the heart of the hard realities of deploying identity management. Let me quote some of the good insights from this article and explain why they are spot on.

Schultz claims that it's critically important to achieve "a genuine understanding of the fundamental difference between identity management and identity management technology". I agree. Many IDM projects start and fail with the proposition that the organization simply needs new identity management technology to improve its security. A war story shared by one of my colleagues serves as a good lesson for any organization that's about to launch an IDM initiative. My colleague's organization had several minor incidents, all related to password sharing. How was this problem presented to management? "We have too many passwords to remember so staff often ask colleagues to share accounts when they forget their own." The organization introduced a slick RADIUS/AAA appliance to implement single sign-on but retained a user accounts policy that allowed short, static passwords. In this scenario, the organization had done as much to make an attacker's life simpler as it has to eliminate the problems created by password sharing. Password related incidents continued and with graver results. The lesson? Identity management requires careful planning at several levels - policy, education, technology, and implementation - to assure that the organization makes considerable gains in the security's Triple-As while continuing to meet the information networking needs of the organization.

Schultz also claims that an Identity management effort is "good only to the degree that the resulting mechanisms and processes are pervasive..." and that it must affect "every access to every system, network, application and database - with no exceptions." I strongly agree. An organization can't enforce an identity policy that applies to staff but makes exceptions to executives, or a policy that fails to address the challenges that guests, contractors, and mobility introduce. Similarly, an organization can't enforce an identity policy that is readily circumvented by staff who choose to ignore policy for expediency's sake, install a departmental database, and use the built-in user account system.

I'd also encourage Schultz and readers to consider expanding his notion of pervasive to apply to every access, by every user, from any endpoint. The most prevalent and pernicious activities besieging the Internet today are impersonation attacks. Thus, I strongly encourage anyone who is considering Identity Management to consider identities beyond the traditional Triple-A (Authentication, Authorization, Auditing) but also in the contexts of authenticity (data integrity and data origin verification) and admission control (verifying that an endpoint device poses no threat to an organization's information and networking asset before granting a user access via that endpoint device). For more on this Quint-A approach, read Improve your branch office security, one "A" at a time.

I've only scratched the surface of the many good insights Schultz offers in his article. He emphasizes the importance of developing requirements, setting criteria to assure that the identity solution scales well and is not overly complex, and determining that the solution is compatible with the existing IT environment (remember, it must be pervasive!). A very good read, indeed.

Archived at http://www.securityskeptic.com/arc20080801.htm#BlogID701 by Dave Piscitello  

The Internet Society recently published a report on the issue of Trust and the Future of the Internet. Within the context of trust, ISOC has elected to focus on three areas it deems critically important:

• "Advancing Internet architecture by supporting the implementation of open trust mechanisms throughout the full cycle of research, standardization, development, and deployment
• "Strengthening the current Internet model by focusing on the mitigation of social, policy, and economic drivers that could hinder development and deployment of trust-enabling technologies, and
• "Facilitating end users’ ability to manage personal data and ensure personal security by elevating identity to a position as a core issue in network research and standards development".

The report is a nicely prepared summary of the discussions among industry experts during an ISOC-sponsored retreat. The experts considered technology, sociological, and economic issues. One discussion I would have dearly loved to attend attempted to define trust and trustworthiness. During this discussion, it was suggested that “behaves as expected in a given context” might be a useful formulation for what it meant to be trustworthy.

Behaves as expected in a given context...

If this is a principle of trustworthiness the ISOC truly seeks to embed in the future Internet, there are possibly no two areas more desperately needing attention and redress than the following:

Informed consent. A short list of actors who do not behave as expected in their particular contexts includes:

1. ISPs who modify DNS name error responses "on the fly" and substitute self-serving ad or search pages. I know of no circumstances where ISPs who engage in this behavior explain what they are doing nor do they seek consent.
2. Registrars and DNS operators who add synthesized DNS responses to zone files of domains they manage on behalf of registrants and customers. An obscure clause in a terms of service web page that claims a right by default to perform so-called error resolution is hardly an adequate means of providing notice and seeking consent. Moreover, in both this case and (1), I have yet to find any terms of service agreement that mentions the unintended consequences of such practices (read SSAC's Preliminary Report on DNS ResponsModification for the ugly details).
3. Spyware, adware, and 3^rd party cookies: need I say more?
4. Domain name front runners and so-called customer protection services. The former is just wrong and the latter is just as wrong when the details of the practice are not readily displayed and when the target audience is not technically astute enough to appreciate the implications of this behavior when they opt-in.

Opt-in versus opt-out. No behavior on the Internet today is more frequently associated with suspicious or often reprehensible behavior than Opt-out. Opt-out puts the decision in the hands of someone who is offering a service. The provider chooses rather than the customer. This might actually be desirable in some situations except for the small fact that the details and consequences of the provider's actions are rarely fully disclosed and easily acquired. This is especially true at the moment the service is performed. Ask yourself, "why is this so?", you have to wonder, "what are they hiding?".

Perhaps it's because they aren't behaving as expected in a given context. Perhaps they aren't trustworthy.

The report concludes with a list of directives for ISOC's Trust Initiative. The first directive is "Promote the stand that trustworthiness is crucial for the long-term growth and success of the Internet." Now, ISOC speaks for the Internet users, and in addition to promoting trustworthiness, I'd dearly love to ISOC say, "don't do business with parties who don't behave as you expect in a given context" and "help us by calling them out".

Archived at http://www.securityskeptic.com/arc20080801.htm#BlogID700 by Dave Piscitello  

The title of this post is a quote from Craig Labovitz, who has published a thoughtful and insightful article on the state and future of IPv6 at the Arbor Networks Security Blog. Craig begins his article, The End is Near, but is IPv6?, by reviewing nearly a year's worth of hype and F.U.D. over the exhaustion of the IPv4 address space and the imminent collapse of the Internet to set the stage for investigating how far along IPv6 deployment truly is. Craig asserts that "as an industry we don’t have a good measure on the relative adoption success of IPv6 with respect to Internet traffic", but he extracts a number of anecdotal statistics from an Arbor Networks' technical report that are sufficient to reinforce my hitherto uncorroborated opinion that IPv6 deployment languishes still.

The traffic trends Arbor Networks observed from the impressive data set it accumulated indicate that IPv6 represents less than one hundredth of 1% of Internet traffic. I checked my firewall logs: traffic representing port scans of my network exceed that figure by several orders of magnitude and I'm confident that this is one of those cases where your mileage won't vary. On the positive side, however, inter-domain IPv6 traffic is growing steadily. The China Next Generation Internet is hosting the China Olympics using IPv6 and global interest in this event should dramatically change both these percentages.

Arbor Networks determined that only 0.4% of Alexa Top 500 websites are reachable using IPv6. Now, 0.4% is an admittedly better figure than the figure I reported on September 11, 2007, when I determined that none of Netcraft's 100 most visited sites supported IPv6, so we can claim progress in this case, albeit small.

Craig next discusses factors inhibiting IPv6 deployment and citing lack of support for IPv6 MPLS VPN, SNMP, and IPv6 flow export. He also cites the "only one in three commercial firewalls support IPv6" result from my SSAC IPv6 firewall survey. He closes the article by offering observations why, despite measurements that suggest deployment is mired in muck, IPv6 remains the only viable answer. My favorite is, "No one has the stomach to spend another twenty years replacing IPv6 with something else."

Read the article and read the comments posted at the blog. Some offer additional, useful insights.

Archived at http://www.securityskeptic.com/arc20080801.htm#BlogID699 by Dave Piscitello