Running XP on my network is like inviting the neighbor's children over for lunch. Not only do I have to prepare things that they like and clean up when they're done, but I have to worry about what they're doing when I'm not looking straight at them.
Like a precocious child with Attention-Deficit Disorder, XP doesn't ask my permission, opinion or guidance before it acts. It's only trying to be helpful, but even the FBI agrees that XP goes too far in searching out and attempting connections to far-flung network devices. What's more, XP also tries to predict my wants and needs and offer solutions I haven't asked for. Every time I turn around, there's another pop up. Sometimes it's a pop up urging me to get a Passport (shudder); another time it's insisting on activation.
Then there are the things I expect it to do and it doesn't. In my Windows 2000 domain, I've disabled the Encrypting File System, yet XP allows users to encrypt files anyway. Authorized users attempting connections are often refused or not given the right access. Programs that used to work across the network don't.
I'm sure those of you responsible for keeping your networks running have heard about these issues and others, or experienced some XP security-related quirk yourselves. Like me, perhaps you wonder what your options are. Well, a number of strategies are available to you: You could not buy it, not recommend it to your customers, nix approval of its purchase and fight its acceptance on your network. If new machines arrive with Windows XP installed, you certainly could remove it and install Windows 98, or Linux, or DOS.
But none of these options is realistic for most of us, and some of us see the positive potential of new XP security features that outweigh the risks of working with a new system. So instead of ranting, here is my solution to Windows XP's most notorious peccadillo to date -- the Universal Plug and Play flaw. For more help with XP security, tune in to the audio archive of my Feb. 14 presentation and discussion on "XP Security: Issues, myths and realities."
In December 2001, a Microsoft Security bulletin, press releases from eEye Digital Security (www.eeye.com), CERT advisories and the FBI detailed a serious vulnerability in XP's UPnP service.
UPnP devices advertise themselves and provide instructions to clients on how to connect. This "feature" makes it easier for the untutored masses to say, connect to, and use a network printer. With UPnP, the end-user does not need to understand device drivers, configurations or even know their locations.
While this sounds good, eEye found flaws in the implementation that would have made it possible for an attacker to, in the worst case scenario, take over the XP system. In other cases, an attacker could successfully initiate a Denial of Service attack on the XP system or engage it in attacking an UPnP device. Although Microsoft immediately issued a fix, the FBI recommended that users disable the service then later retracted that recommendation. The FBI's concern related to the service's default activity, which automatically seeks out and attempts connections with network devices that offer similar services.
Now what? The Bragg response
First of all, if you haven't already, immediately download and install the patch. The security bulletin is available as well and offers a link to the patch. Additionally, a patch for Windows 98 and Windows ME systems on which you have installed UPnP (it's not installed or enabled by default), is also available.
I'd also recommend you strongly consider disabling the service, not because, as the FBI initially stated, the patch isn't enough, but because it is one more service that most users of XP don't need. Standard security best practices tell us to run only those services and give away only those privileges that are warranted. Every additional process that you run on a system offers the potential of vulnerabilities, and every right you give out leaves you more open to its misuse or abuse. Furthermore, don't just disable the service -- restrict its management and install the patch. Disabling the service does not prevent its re-enablement by accident or malicious act. Setting security on the service help here and installing the patch gives you another layer of protection should someone break through your access controls.
To disable the service:
Open the services applet (StartAdministrative ToolsComputer ManagementServices and Applicationsservices) and double-click the SSDP Discovery Service (SSDP stands for Simple Service Discovery Protocol). Then on the General page, change the Startup Type to Disabled and click OK. Do NOT disable the Universal Plug and Play Device Host. The vulnerability is in the SSDP Discovery Service.
Why it works
It's always a good idea to research the fine points of a security problem and its patch. You may find that there is less reason for hysterical reaction, additional configuration choices that support your network configuration and some rebuttal for Joe User's authoritative diatribe.
The patch protects from the identified attacks in the following ways:
- It fixes the buffer overrun (first vulnerability) that might have allowed takeover of XP.
- The second vulnerability results from the way XP searches for and handles device descriptions and downloads. The patch limits where UPnP searches as well as applying several tests before downloading. After the patch is installed, UPnP will only search on its local subnet and then only if the device is only a few hops away. In addition, the patch prevents XP from continually attempting to download a device description. A table is used to collect information on failed attempts, the number of ongoing downloads and distance to the host. Each failure and each current download add to the delay (up to a maximum of four and one minute respectively) before a new download attempt can begin. Once the total of both delays is summed (in seconds), a random number between zero and the sum is generated. This is the actual delay.
Just as using your automobile's seatbelt won't protect you from every possible injury, these modifications won't prevent every possible DoS. There are risks involved when people or data travel from source to destination. Some of these limits are configurable. The knowledge base article Q3150056 (available at www.microsoft.com/technet) identifies additional XP registry values that can be entered and configured. (See sidebar above.)
Other methods to protect your systems:
- Attackers may attempt connections to the services ports or may carry out attacks using multicast and unicast messages. Many perimeter firewalls are configured to block multicast messages, unsolicited unicast messages, as well as all incoming port requests that are not explicitly allowed. This would protect XP systems inside the network from such attacks. However, explicit blocking of the ports used by UPnP (5000 and 1900) could also be configured.
- The Internet Connection Firewall (ICF), if enabled on XP, automatically blocks unsolicited unicast messages but not multicast or broadcast. It also does not allow connections to ports not explicitly allowed. While not complete, this does allow some protection from malicious attacks.
- Systems using Internet Connection Sharing are protected, as the Internet Gateway would not forward the attack packets. The gateway machine would be at risk.
Roberta Bragg MCSE, CISSP, MCT, MCP is a well-known Windows security consultant, columnist and speaker. Her publishing credits include ISA Training Guide, MCSE Windows 2000 Network Security Design and Windows 2000 Security.