The Security Skeptic

Default installations of Windows XP Home and Professional Editions boot with a number of services that are not necessary for correct operation in home and many enterprise offices. Some of these pose security problems because they advertise services or solicit connections from anonymous (read: unauthenticated) hosts. Others simply waste RAM.

If you administer a firewall and have blocked all outbound services except those you authorize, you will "discover" PCs running XP on your trusted interface by the appearance of DENIED traffic to port 1900, the SSDP Discovery Service. If you aren't administering a firewall, run LAN analysis software like Ethereal on internal networks to see if SSDP is blathering on your LANs. If you are unwilling to do either, there is little point in reading further.

XP uses the Simple Service Discovery Protocol to gather information about Universal Plug and Play (UPnP) devices like a networked printer on a network. UPnP device responses provide lots of useful information but also provide a vector for DOS and DDOS attacks (Google "UPnP vulnerabilities"). If you are certain you don't have UPnP devices, you can safely disable this service, eliminate port 1900-directed traffic, and save some RAM. If you don't see traffic at Port 5000 (read on) you probably don't have UPnP devices on your network.

If you disable SSDP, you can also disable the companion UPnP Device Host service, which supports the UPnP peer-to-peer exchanges using Port 5000. This unfortunate port "assignment" collides with a remote administration tool (RAT, a form of trojan program) called Sockets de Troie, and lots of Internet Chess servers. If you do disable UPnP and still see traffic at port 5000, investigate further!

I've discussed SSDP/UPnP in the context of XP, but ME also has this service, and patches exist to add these to Windows 95/98.

One last point. UPnP is not the same OS function as Plug and Play, which manages device discovery on your PC.

This single act of pruning saves a bit of RAM, a fair amount of noise on your LAN, and improves your risk profile. If I've whetted your appetite and you want to learn how to prune-and-tune your PC, download Black Viper's excellent paper on XP services configurations.

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID112 by Dave Piscitello  

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID111 by Dave Piscitello  

Business continuity planning is an activity whereby an organization attempts to emulate the Energizer Battery Bunny: BCP defines what it takes to "keep running and running and running..." even when s--t happens.

We've seen ample evidence that U.S. utilities need Infrastructure Continuity Planning. Our power grids are antiquated and need an estimated $105 BILLION upgrade. Curiously, the power companies, which have been rock-solid, perennially dividend-yielding investments for as long as I can remember, give us every indication that consumers will bear the brunt of this financial burden.

Can it be that these companies have managed to let their infrastructures deteriorate decade after decade, while reaping consistent profits? Can it be that they've failed to earmark cash year after year to invest in the network upgrades on which their company's continuing existence hinges?

What kind of management teams have we here?

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID110 by Dave Piscitello  

If you custom build a PC, you will probably choose to forego the floppy drive (and buy extra memory). But you may bump into programs that just can't grok the notion that a PC doesn't have a floppy drive! Fortunately,

One such program is Windows Terminal Services Client Creator for Windows 2000 Advanced Server. Here's my workaround for this problem.

• Create the floppies from the client creator software at your server.

• If you have USB ports on your server and client PC, copy the floppies onto a removable drive or compact flash card in two folders, DISK1 and DISK2 (no spaces).

• Open the folder DISK1, run SETUP.EXE, and the installer will automagically look for the folder DISK2 in the same drive/location.

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID108 by Dave Piscitello  

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID109 by Dave Piscitello  

Microsoft's finally getting the message?

For years, Windows operating systems overwhelmingly have opted in favor of ease of use and effectively, against security as the default setting for networking services. Security experts criticized Microsoft soundly and often for this lame security posture.

This philosophy extends to Microsoft's Automatic Updates, which are voluntary because the hue and cry from users was that they didn't trust Microsoft to muck with their systems.

Now, with a slew of worms in the span of only weeks, users may finally be coming to the conclusion, "better the near-monopolistic software giant you know than the malware writer you don't know". Yes, Microsoft can write more secure code. But the mistrust is misguided, and users should realize that if they buy into Windows, they ought to buy into the best available process for securing Windows: automatic updates of security patches without user explicit consent.

For a very large population of Windows users, updates, especially security-related ones, are incomprehensible, so they ignore them. These users are virus carriers waiting to be infected, again and again. Microsoft can take two paths: make security updates mandatory, or make the default setting of security updates "implicitly accept and install". I truthfully don't care which, as they accomplish the only interesting goal of reducing the window of infection.

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID106 by Dave Piscitello  

In his newsletter, Insider Attacks are a Thorny Problem, Mitch Kabay cites a Gartner prediction | myth | perception} that by 2005, 60% of security incidents will be instigated or assisted by insiders. Mitch adds that "insider crime is even harder to defend against than external attacks".

The last time I cared to investigate this claim, I relied on the trustworthy - and likely more reliable - 2001 CSI/FBI Crime Survey, which reported that 68% of incidents were insider attacks, so either Gartner's overlooked some folks and factors in their research (ya think?) or security measures to prevent insider attacks is improving<.

But I am curious whether insider attacks are actually harder to defend against, or whether organizations are, in general, way too lax in protecting assets. Actually, I'm not wondering any longer. I'm certain this is the case. Here's a quick list of reasons why I believe we are simply even more lame at protecting assets from insiders than outsiders:

• Many organizations think perimeter firewalls are all (OK, 90% of) the protection they need, and they are overly permissive about what they allow outbound. Such policies allow attacks from inside hosts that have been compromised. For example, a trojan or rootkit has been installed on a client computer (it's likely it was delivered as a mail attachment). The trojan communicates back to the attacker over a TCP Port "f00". If the organization blocked all but approved outbound ports, this attack would have been thwarted. This is an outsider attack, facilitated by an insider.

• Many organizations are too generous with access controls at servers. Groups authorization levels are implemented for convenience, and little auditing or control is exercised over the groups. Eventually, insiders without a need to know have access to sensitive information, creating temptation where there should be none (Eve's dilemma).

• Many organizations don't audit interior networks. They can't distinguish rogue MAC and IP addresses from authorized ones, because they don't know their network.

• Organizations are overly fond of single sign on. Being able to authenticate once is attractive. It's also a practical concession to our cultural inclination to circumvent security if it's inconvenient. But having single sign on doesn't mean that, once authenticated, an individual should have access to every asset in the corporation!

• Too few organizations make use of proxy mail applications, split-DNS, and other measures that hide internal network information from outsiders. Attackers can gather lots of information about an organization's "trusted" networks from mail headers forwarded without modification from internal mailservers; similarly, they can learn a great deal about internal naming and addressing if an organization publishes these indiscriminately.

• The same organizations that have permissive outbound traffic policies may use the nefarious ANY, as in "allow any traffic, from any source IP". With a little routing savvy, an insider can route entire subnets through a firewall so configured!

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID107 by Dave Piscitello  

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID104 by Dave Piscitello  

My wife and I finished reading Monty Roberts' autobiography, The Man Who Listens to Horses: The Story of a Real Horse Whisperer. Our family has grown to love horses and Monty's real-life stories and insights into the language horses speak (one we can learn!) was a wonderful reading experience for us all. ISBN 0-345-42705-X, find it here at Amazon.com

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID103 by Dave Piscitello  

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID102 by Dave Piscitello  

Operating System (OS) fingerprinting is a method whereby an attacker or pen-tester attempts to identify the operating system running on a host based on the responses that system returns. The comparison of this analysis technique to fingerprinting is based on the fact that Windows and *NIX Operating Systems, as well as router, switch and even security system software respond differently to received packets when unexpected and erroneous information is encoded in the packet (commonly though not exclusively TCP and IP) headers.

Fyodor's nmap is the most widely used and flexible tool for performing OS fingerprinting proactively. But fingerprinting by actively scanning, even if done as stealthily as imaginable, leaves evidence (hmmm... you might say it leaves fingerprints!). It also changes traffic patterns.

Techniques to fingerprint Operating Systems passively - based entirely on packets received rather than returned - are very interesting alternatives for security auditing purposes. Several projects demonstrate you can successfully identify OSs based on captured packets that give an accurate signature of popular operating systems.

Kevin Trimm provides a nice overview of passive OS fingerprinting in a column at SecurityFocus.com. He mentions two tools, Siphon and p0f. Give 'em a look.

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID101 by Dave Piscitello  

Hendrik Hertzberg offers the best characterization of Right Wing Radio I've read in a long long while in the August 11, 2003 issue of New Yorker Magazine. In his Radio Daze comment in the Talk of the Town section, he explains that

"...right-wing radio is niche entertainment for the spiritually unattractive. It succeeds because a substantial segment of the right-wing rank and file enjoys listening, hour after hour, as smug, angry, disdainful middle-aged men spew raw contempt at reified enemies, named and unnamed. The radiocons seldom offer analysis or argument. To the chronically resentful, they offer the sadistic consolation of an endless sneer..."

Let's see. The radio conservatives includes Bob "could my voice be any more irritating" Grant, Rush "to the refrigerator" Limbaugh, Mark "if I were any more right I couldn't be wrong" Levin, and Michael "how appropriately surnamed" Savage.

I'd say Hendrik's hit the mark, spot on...

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID98 by Dave Piscitello  

Woody Allen provides one of the best "Back Pages" I've read in New Yorker Magazine (August 11, 2003, an issue worth the price of the annual subscription all by itself).

"Physics has all the answers."

"I awoke Friday and because the universe is expanding it took me longer than usual to find my robe".

"Compared to the amount of atoms in the Andromeda Galaxy I actually earn quite little."

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID99 by Dave Piscitello  

What's the most appropriate course of action when one discovers a software flaw that makes an operating system, client or server application vulnerable to an attack?

The answer to this question is the heart of the Disclosure Debate that continues within the security community. One constituency believes that full and immediate public disclosure of the flaw is necessary: I call this the *stick* approach (e.g., carrot or stick) because in theory, it embarrasses the software company into a response. The problem with this approach is that it often broadcasts an exploitable flaw that may be present in hundreds if not thousands of production hosts before> a patch or recommended way to circumvent the problem is prescribed. These systems become targets of a broader base of attackers than they might otherwise attract.

A second constituency believes that the flaw should be disclosed to software vendors first, who ought to be afforded some opportunity to provide a patch or recommended workaround. If the vendor is unresponsive after 30 days, for example, information about the flaw may be released to the public. This is the *carrot* approach.

Whether you believe in the stick or the carrot, you should take time to review and comment on the Draft Security Vulnerability Reporting and Response Process by Organization for Internet Safety (OIS).

How vulnerabilities are reported affects all netizens.

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID97 by Dave Piscitello  

SecurityFocus News reports that a recent study by Qualsys concludes that "Software security holes never die, they fade from the Internet at a rate of 50% every thirty days after a patch is released".

Stated in another way, disclosure of an exploitable flaw in software, formal or otherwise, causes a wave of attacks seeking out systems that remain vulnerable. This wave abates dramatically 30 days after disclosure. (Living on a barrier island, I think the correct analogy is *tidal surge*... OK, a small matter.)

My initial reaction to this statement is was, "did they ignore CodeRed and Nimbda?" When I reviewed my web logs over the past 6 months, I confirmed that I have a very consistent rate of attempts to exploit these IIS vulnerabilities.

Reading on, I find that Qualsys believes these fall into a different category: instead of decaying in a predictable manner, they return and become prevalent again. Qualys CTO Gerhard Echelbeck attributes this phenomenon, bug-immortality, to attackers seeking out "network administrators cloning new systems from old, unpatched images".

IMO, this is an oversimplified characterization. Staff with little security expertise are thrown into systems administration daily. Many barely understand how and what to do to get a host and web services operational, much less, secure, and they are pressed to do so in haste. Most probably don't know how to create a system image and simply build a Windows server from OEM or Microsoft CDs; in fact, a great many of these folks would be hard pressed to repeat the process they used to create their first server environment.

Exploitable bugs are immortal because our culture tolerates a level of hygiene when it comes to server security that modern societies would consider medieval if the same were applied to viruses and diseases.

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID96 by Dave Piscitello  

Stuart Vance, a former colleague and really good guy, has begun a campaign to derail the gubernatorial recall election in California. He's created a web site where you can learn how to add a candidate to the ballot. His objective is to basically launch a denial of election attack by exceeding the number of candidates that can conceivably fit on the CA ballot.