The Security Skeptic

Dan DiNicolo's "step-by-step methods for evicting invaders and keeping them out", published by PC Magazine, offers a neat and complete presentation of built-in and 3^rd party security solutions that can be implemented to make XP PCs more secure. DiNicolo does a nice job of explaining how to use XP's local security policy, how to secure IE, how to protect XP with a software firewall, and how to combat malware and spam. Dan also explains why patch management is important and even covers the advanced topics of file security using encryption and secure wireless networking.

If you are a regular visitor to my blog and read my SecurityPipeline and Live Security Service columns, these topics will undoubtedly seem familiar to you. In fact, if you've regularly visited my Windows XP Security Resources and read a good number of the columns posted or hyperlinked there, you probably know more about XP Security than you'll learn from Dan's book. This is less a criticism of the book than a conclusion about the appropriate audience for Windows XP Security Solutions.

Dan's 400+ page guide is true to it's sub-title. Every step required to configure each XP security solution is carefully documented. This is clearly useful for consumers and relatively non-technical users for several reasons. Each configuration is exacting enough and written in sufficiently simple terms to assure a high probability of success for even the least sophisticated user. Moreover, just about all the measures I'd recommend, and all the measures large organizations seek to implement, are discussed in a single location. Security-minded professionals are more than willing to search knowledge base after knowledge base to learn not only XP security basics but the nuances of many security features as well. Like many security professionals, I'll read everything I can find about a security measure, try alternative implementations, and whack at the result to see if I can break it. This is *much* more than we can expect from average consumer and non-technical user.

If you have followed the evolution of XP security over the past 9-18 months, you won't find much in DiNicolo's book that hasn't been written elsewhere, with more technical insight, or with an eye on enterprise implementation. But if you know friends and business colleagues who are earnestly interested in learning enough about XP to make informed decisions about security and who will take the time to read *one* chapter a day and follow the advice therein, you should consider recommending this resource.

Archived at http://www.securityskeptic.com/arc20051201.htm#BlogID485 by Dave Piscitello  

Chris Powell has written an eBook that provides a wealth of information and good advice to protect against phishing attacks. The book is written with non-technical Internet users in mind. Written in "plain speak", Online Predators Revealed makes powerful use of interesting analogies and provides plenty of simple-to-follow advice to help even school age children avoid phishing and web spoofing attacks.

Archived at http://www.securityskeptic.com/arc20051201.htm#BlogID484 by Dave Piscitello  

Gene Kim wrote a nice piece about unplanned work and its adverse affect on productivity. Unplanned work is a euphemism for "the daily dose of IT reality". It includes restoring service following a failure, responding to security incidents and configuration errors, and (my favorite) providing assistance "outside the help desk", also known as drive-by acts of kindness that tech-savvy staff invariably offer fellow employees (especially the attractive ones).

As the name suggests, unplanned work cannot be associated with authorized projects, procedures or change requests but divert staff attention away from planned activities. Gene and colleague Kevin Behr believe that unplanned work is "a remarkably accurate indicator and predictor of IT effectiveness".

Find the full article in the online version of this Tripwire Newsletter.

Archived at http://www.securityskeptic.com/arc20051201.htm#BlogID483 by Dave Piscitello  

I received an email from a someone in Paraguay today, inquiring about VLAN support on 3Com switches. He obviously tried very hard to communicate his needs in English, and his effort was no worse than I imagine my frequent efforts in Spanish to be, so I replied in English and Spanish. He immediately thanked me profusely, entirely in Spanish. Perhaps my Spanish isn't as bad as I think.

Fortunately, English and Spanish mostly share a common script. With the exception of the occasional tilde and umlaut mark, the majority of characters (glyphs) of Romance (New Latin) languages can be represented in basic ASCII. However, if I were to have received email in both native language and English from someone in Beijing, Seoul, Bankok, Tel Aviv, or Mosul, I'd need the ability to type and display characters from Chinese, Korean, Thai, Hebrew, or an Arabic language scripts in my email client or browser (and of course understand these languages). In some countries, many language scripts are used, so I might even need to understand how to read and type scripts of local dialects.

The problem of native and local language character representation has been solved in many operating systems and applications. Email and web, for example, use Multipurpose Internet Mail Extensions (MIME) to provide multilingual support for many languages and scripts. Unfortunately, the Domain Name System cannot easily accommodate national and local character sets for several reasons. Principal among these is that DNS labels must follow composition rules for ARPANET hostnames, and can only contain letters, digits, and hyphens (known as "LDH"). With this restriction, a tilde or umlaut used in certain New Latin scripts cannot be used in domain names, nor can any character or glyph of other known languages. Such languages require that domain names be represented to users in the Unicode Character Set.

Several problems exacerbate the problem. First, most Internet applications present - and expect users to submit - a domain name in the same representation (presentation syntax) as the DNS protocol uses as its "over the wire" (its *transfer* syntax). This is true even in MIME-enabled email: while you may be able to use the Spanish word baño or the Thai character ko kai (ก) in a message body or certain headers, you cannot do so in any host name part of an email address (you can probably confirm this by examining mail headers in certain spam messages you receive). Similarly, while you can place Unicode-encoded national language characters in a web page, you can't use them in a hyperlink.

A partial solution to this problem, generally referred to as Internationalized Domain Names (IDN), currently provides the ability to use national and local characters in all DNS labels other than the Top Level Domain (TLD) label (e.g., com, net, org, biz, info, and the "country code" TLDs). This solution is specified in RFC 3490, Internationalizing Domain Names in Applications (IDNA). IDNA describes how Internet applications can convert labels presented to users in Unicode characters to an "ASCII compatible encoding" that name servers can process (LDH), and how applications can convert a label from an ASCII-compatible-encoding into a native or local character string for presentation to an application user. (Interested readers should also consider two companion standards: RFC 3491, NamePrep and RFC 3492, Punycode).

IDNA is currently available for use in 2^nd level labels in domain names registered through IDN-capable registries, under LDH-encoded top level domains. This means that a registrant can register cuartodebaño.com today; more generally, anyone can use any Unicode-encoded national or local character set in a 2^nd level label, register that name under a generic TLD (com, biz, net...), have this resolve correctly by the authoritative DNS. ICANN provides guidelines governing the composition of such Internationalized Domain Names here. This document provides general label composition rules for registries, and in particular defines guidelines that try to thwart the deceptive use of visually confusable characters by would-be pharmers (at last, something security-related!). To appreciate this form of deception, consider the two domain names paypal.com and pаypаl.com. Visually, they appear identical; the first however uses the Roman small "a" and the second uses a Cyrillic (Russian) small "a" (Unicode hexidecimal 0430). ICANN's IDN guidelines prohibit the mixing of scripts in labels to prevent misuse by pharmers (Readers seeking a more detailed treatise on such practices should see Unicode Security Considerations).

Currently, ICANN's IDN-capable registries do not support national and local character sets in top level labels. This means that while a party can register cuartodebaño.com, the country of Spain could not use "españ" as friendlier alternative to the two letter country code "es", nor can countries use national and local scripts. This may seem a trivial matter until you consider that LDH glyphs are not universally recognized and not easily typed into certain keyboards, that some scripts are not written left-to-right, and that everyone should have the opportunity to use the Internet to communicate in languages they share, using the characters normally used to write and print those languages (see RFC 4185).

ICANN and the Internet community at large will consider two technical solutions for incorporating national and local characters in TLDs. The first attempts to apply the IDNA standards in the TLD; the second attempts to provide DNAME equivalence mappings for TLD strings.

Variants of the IDNA technique are currently used by "breakaway" root name services and registries to support TLD labels in several national characters and scripts. While these initiatives are providing native language TLDs today for the constituencies that subscribe to them, they have the undesirable effect of fracturing the single authoritative root name service: TLD labels registered in these languages are not resolved by the authoritative root name service but rather the "local root name service" operated by (or on behalf of) a country or constituency.

"Breakaway" root name services solve an immediate and localized need by adopting and deploying IDN technology in advance of international guidelines developed through a consensus-building process. Anyone who's built one of anything will agree that this is a much smaller set of problems to solve than the set facing ICANN and the Internet community at large. We must assure that domain names can be resolved consistently and correctly irrespective of characters used in name composition and geographic location. Breakaway root name services sidestep the challenging problems. To date, they don't attempt to solve multinational multilingual issues but instead spin off multiple root name services instead. The minor matters they choose not to solve include how to maintain cooperation among

• nations (North and South Korea are .kp and .kr respectively, but who decides what characters are used to globally represent "Korea" at the TLD label, who decides which scripts are used for generic TLDs, and how to handle duplicates?),

• among constituencies within nations (Sunnis, Shiites and Muslim tribes must agree on language preferences at *some* level), and

• between nations and private interests (coordinating and preserving intellectual property and protecting branding through registration processes) to establish globally acceptable guidelines.

Some attempt has been made to recognize multiple official languages and scripts, but the "policy" test case for this problem will be a country like India, which has twenty two official languages, 325 local dialects and numerous scripts.

It's somewhat promising that most interested parties attending the IDN workshops prior to and during the Vancouver ICANN meeting appear to be moving past whining and posturing over the injustice of the "IDN.ascii" (the pejorative acronym used to illustrate that TLDs are still restricted to LDH encoding) and appear to be looking for global answers.

While boning up on IDNs, I tried to surf the web using one of the IDN-capable breakaway root name services. (I had to learn some Cyrillic to complete one of my first programming assignments, a Cyrillic keyboard interface to a Burroughs L-series minicomputer). It wasn't long before I became frustrated at how hard it was to surf using unfamiliar languages and scripts. I can imagine how trying my Internet experience would be if this were a 24x7 circumstance. I can see how tempting a quick fix like a breakaway root name service might seem. Hopefully, these are interim solutions that do no permanent harm, and that a globally palatable alternative is identified soon.

Archived at http://www.securityskeptic.com/arc20051201.htm#BlogID482 by Dave Piscitello  

Nearly a decade after the disclosure of the exploit code for the original LAND attack, a remote variants of the attack have resurfaced (see Remote LanD Attack). One variant affects Microsoft W2K3 and XP SP2 when Windows Firewall is disabled (see CVE-2005-0688). Others appear to affect a wide range of consumer grade DSL/cable modems, broadband access routers, and even some enterprise entry-level firewalls, e.g., the kind you typically see used by businesses with T1 access circuits.

The original LAND attack sent a TCP SYN segment to an open port on the victim's host, setting both the source and destination address fields in the IP header to the victim's IP address (i.e., from 10.0.0.1:139 to 10.0.0.1:139). In 1997, this attack caused systems to crash, BSOD, or reboot. Justin Wray and friends discovered two variants to the remote LAND exploit that create denial of service conditions.

In the first case, an attacker sends a TCP segment with the Ack/Syn/Push/Urgent flags set. He sets the destination IP address to the external (public) IP address of a target cable modem or broadband router/firewall, and sets the source IP address to the *private* IP address assigned to target device. This attack causes the modem/access routers to fail in several ways (vendor dependent). The source address of many consumer grade broadband access devices is easily derived. Most such devices use the RFC 1918 reserved IP number 192.168.x.0/24 and set the router to 192.168.0.1, 192.168.1.1, ...

In the second case, the attacker again send a TCP segment with the Ack/Syn/Push/Urgent flags set, again setting the destination IP address to the external (public) IP address of a target cable modem or broadband router/firewall, but sets the source IP address to a broadcast address. This causes the hosts on the private network to flood the broadband access device with responses.

Both attacks can be performed using a packet composition utilities like hping2 (no special code required).

Strictly speaking, these attacks are different from a traditional LAND attack - the source and destination IP addresses aren't the same - but the addresses are assigned to the same host, and the attacks have similar impacts.

The Microsoft patches have been available for some time. Several vendor products require patching (find the list in the referenced URL). A workaround for firewalls and routers exploitable in this manner is to include an firewall rule or ACL that blocks all traffic arriving at the external interface with an internally assigned address (this should be Firewall 101 by now). But as Wray observes, if the modems are vulnerable, the traffic won't ever be delivered to the firewall/router.

I think this is an interesting exploit for several reasons. First, it illustrates how quickly one "generation" of programmers forget the lessons ,learned less than a decade ago, and emphasizes how desperately our industry needs to teach secure code techniques and invest more in quality assurance. Second, it is a unique example of an exploit that spans many classes of systems and operating systems. Third, it is an example of an attack that will probably succeed for a long time, since it exploits consumer grade technology, and as Wray observed in an email exchange, few consumers are savvy enough to perform a firmware upgrade on a network device, and many simply won't try. What a considerate pre-Christmas gift for broadband help desk operators.

Archived at http://www.securityskeptic.com/arc20051201.htm#BlogID481 by Dave Piscitello  

Michael Horowitz put a nice discussion of four of the most popular forms of trickery phishers use to lure victims to a fraudulent site, commonly to steal some identity or financial information. Michael's categorizes avenues of trickery as (1) technical tricks with the link, (2) exploitable browser vulnerabilities (bugs), (3) domain name deception, and (4) DNS poisoning.

Michael's Examples of Links that Lie is a worthwhile read for everyday users and practicing professionals as well. I'll add this to my Phishing and Fraud Prevention resources page shortly.

One method of deception Michael doesn't cover is the use of Unicode encoded characters that are visually similar to common Romance (New Latin) characters in domain names. The classic example of such visual deception is the use of a Cyrillic lower case "a" (unicode hex 0430) for a Roman character "a" in the domain name paypal.com. You can read about this and other visual security issues related to Unicode in Unicode Technical Report #36.

Archived at http://www.securityskeptic.com/arc20051201.htm#BlogID480 by Dave Piscitello  

Upon reading my blog entry 478, Harry Potter and the Group Password, Richard Cleaver of Access Manager contacted me with this comment:

Dave,

If you can let me have Albus Dumbledore's email, I'll send him our free password manager (www.AccessManager.co.uk).

:)

Thanks for a great blog.

Best wishes

Richard Cleaver

Well, Richard, I've tried to locate Albus' email but have failed.

Hogwarts must consider the Internet a "muggle thing". The domain name Hogwarts.edu does not resolve, nor does hogwartsschoolofmagic.edu. The second-level label "Hogwarts" is registered under .com, .net, .org, .biz, .info, .us, and .tv and all these domain names are parked, meaning someone has registered the names and is speculating on their value.

As of December 9^th 2005, Domain name speculators have not yet registered the second-level label "Hogwartsschoolofmagic" under all the popular gTLDs, so if you're looking for a clever web site name...

Archived at http://www.securityskeptic.com/arc20051201.htm#BlogID479 by Dave Piscitello  

Harry Potter is a thoroughly enjoyable read for children and adults alike. Harry is a thoroughly ethical young man and positive role model for many children worldwide. He'd make a good security practitioner.

If Harry *were* to set aside such attractive career paths as Auror or Professor of Defenses Against Dark Magic to become a security administrator at Hogwarts instead, his first act would undoubtedly be to eliminate the use of passwords as authentication credentials. For those of you who are unfamiliar with the Harry Potter series, Harry attends a school of magic called Hogwarts. Students who attend Hogwarts are placed into four "houses" by a magical Sorting Hat when they arrive for their first year. The Houses are named after the school founders: Ravenclaw, Hufflepuff, Gryffindor, and Slytherin. Harry is in Gryffindor.

The students of each house take residence in Towers. Each Tower has a magically protected entrance. In Gryffindor Tower, the entrance is hidden behind a large portrait of a fat lady in a pink silk dress. The students of Ravenclaw, Hufflepuff, Gryffindor, and Slytherin are told the "secret" password that gains them entrance to their respective Towers.

This is weak authentication in all its glory. The password is shared by every member of a House. It is a static password, changed annually. Moreover, the fat lady's password challenge never asks students for identity. I cannot recall any incident where a house ghost barred entrance to a student because he was a member of a different house and thus had no business entering. which could imply that facial recognition (biometric) is used. But if the house ghosts use a biometric, what's the purpose of the password?

Perhaps the password is a second factor to the biometric, to defend against impersonation. Remember, this is a school of magic, and JK Rowling describes many spells and potions, including Polyjuice Potion, which transforms a person into the physical form of another person for one hour. Now someone has to make the potion (difficult) and learn the password (trivial). But this still begs the question of why a group password is used instead of assigning one to each student.

Perhaps the ghosts can't remember that many passwords.

To understand why I am making such a fuss over passwords at Hogwarts, you need a bit more information. Hogwarts School of Magic is protected by all manner of powerful spells to repel evil spells, keep evil magicians from entering the school, and to hide the school from muggles (people who can't practice magic). This is an envious set of perimeter defenses. Within the perimeter, however, Hogwarts relies on group passwords to control access to individual houses, which is markedly less rigorous.

Does this sound like any networks you know?

Archived at http://www.securityskeptic.com/arc20051201.htm#BlogID478 by Dave Piscitello