"Universal Plug and Play" (UPnP) is a technology pioneered and developed by Microsoft. UPnP is implemented in recent Windows versions.
Windows XP comes with UPnP functionality out-of-the-box and enabled automatically, Windows ME has UPnP services disabled by default. Nevertheless, some OEMs choose to enable them. There is no support yet for Windows 2000 or Windows NT. Older DOS-based Windows versions are supported only via the Internet Connection Sharing (ICS) software delivered on Windows XP setup media. ICS is known to be installable on Windows 98 and 98SE systems for sharing Internet connections through a Windows XP box.
In a nutshell, the idea behind Universal Plug and Play is the ability to reconfigure the operating system in response to the detection of new, peripheral hardware that has been made available via a communications network. The implementation can be described as an extension of the well-known Plug and Play paradigm for PC hardware. In the early days, Windows operating systems were often unable to automatically detect PC internal hardware, such as network cards or graphic adapters, so users had to manually configure IRQ settings and the like. Since Windows 95, Plug and Play technology has defined a protocol that allows the operating system to automatically detect and configure hardware components. In the networked world of today, the big challenge now lies in the discovery and adoption of networked devices and/or services. Universal Plug and Play provides a framework for just that: imagine a simple home setup with several parties sharing a common Internet connection, for example through inexpensive router hardware. Here it might be worthwhile for any computer in the home network to automatically discover the router providing the Internet connection service and configure itself appropriately, in effect enabling Internet connectivity on any of the machines.
Implementation of UPnP functionality is provided through a set of TCP/IP services. The introduction of new network services and protocols has always caused the curious among computer users to start digging deeper into the actual workings of these services. Protocol compliance and vulnerability to attacks coming through the network are of particular interest. UPnP was no exception, and while Microsoft didn't exactly make a big public deal of the Universal Plug and Play functionality in Windows ME and XP, the first posting on the Bugtraq mailing list appeared on Thursday, November 1, 2001 . "Ken from FTU" submitted an email message with the description of "Three Windows UPNP DOS Attacks" [KEN]. He claims to have found these attacks while looking for Trojans on his girlfriend's computer (a Windows ME box). He eventually stumbled across a listening service on port 5000. Several quick attempts at sending forged data resulted in the service either crashing, eating up memory, or temporarily freezing the machine. In his mail to Bugtraq, a Word document is included which also contains proof-of-concept exploit code. We will further discuss this code below.
'Ken' reportedly sent his findings to Microsoft in August 2001. Microsoft released a security bulletin on November 1, 2001 [MS01-054] in response. The bulletin acknowledges the DOS attacks that 'Ken' describes and classifies them with low security risk for client machines. The bulletin denies any severity of these attacks for server systems. A patch was released, which is buggy on Windows ME systems, and finally updated on November 13, 2001 . The vulnerabilities were included as a candidate in the Common Vulnerabilities and Exposures database and assigned the identifier [CAN-2001-0721].
On December 20, 2001 , just in time for the holidays, eEye Digital Security released a security advisory titled "UPNP - Multiple Remote Windows XP/ME/98 Vulnerabilities" [EEYE]. The advisory describes more vulnerabilities in Microsoft's UPnP implementations. The first vulnerability is described under the title "The SYSTEM Remote Exploit". By sending malformed UPnP advertisements, the UPnP service on the target machine would eventually crash due to access violations. eEye claimed that there are several potential methods of exploiting this behavior, but no concrete examples are given, neither is there any exploit code released by eEye. The exploits that are hinted at would allow an attacker to execute code at a high privilege level on the target machine, which must of course be considered as critical.
The second vulnerability, a denial of service attack, is outlined as follows: by sending a certain forged UPnP advertisement, the target machine can be triggered to connect to an HTTP URL specified in the packet. If there is a malicious service running at the specified location, the target machine can be thrown into an endless loop, depleting system resources and finally requiring a restart. Since the UPnP service is also listening on broadcast addresses, a single packet can trigger many machines to connect to a specified HTTP location, essentially starting a denial of service attack against that location. In the advisory, eEye promises a more detailed paper on security issues in Microsoft's UPnP implementation. This paper has not yet been publicly released.
Microsoft acknowledged the findings and, on the same day, released a security bulletin describing the vulnerabilities found by eEye [MS01-059]. While Microsoft continues to deny that there is any security implication on server systems (because they classify servers as secured, usually behind a firewall, which would include the appropriate rules for services that are not outward facing by definition, such as HTTP, for example), these new vulnerabilities are labeled as medium to critical (critical for Windows XP systems, since UPnP is enabled by default). The bulletin also includes links to patches for the vulnerabilities, which supersede the patches released for [MS01-054]. CVE follows up with two candidates, namely [CAN-2001-0876], which references the buffer overflow exploit, and [CAN-2001-0877], describing the DoS and DDoS attacks. This second vetting of security problems in the self-described " most secure operating system ever" [CNET] got a lot of attention, with even the FBI releasing an advisory and contacting Microsoft to investigate their progress in providing patches [NIPC].
On December 24, 2001 a post to the Bugtraq vuln-dev mailing list [VULNDEV] presented exploit code that promised a denial-of-service against a target Windows box. On top of that, the same code included an option that would spawn a highly privileged shell process on a target machine. The poster is not the original author of the exploit, which is available on the qB0X website [QBOX1]. It could not be verified when this code was originally published. After some discussion on the mailing list, it was concluded that the exploit does not work as advertised. However, this exploit is commonly available in most exploit archives, such as the Packetstorm Security site [PSS]. We will discuss this exploit in the course of this paper, and show how it can be partially made work.
On January 9, 2002 , the author of the above mentioned exploit posted a message to the Bugtraq mailing list. The message included another exploit, implementing one of the denial-of-service scenarios described in the eEye advisory [MAGGIOTTI]. This exploit is also available from the author's website, qB0X [QBOX2] [QBOX3].
In this section we can only try to make a guess as to how serious the UPnP issues really are. The vulnerabilities are fairly new and, at least with respect to production machines, it is assumed that not a whole lot of XP systems can be found "in the wild" running as production server systems accessible remotely in some form or the other. So far, only the workstation and home user versions of Windows XP has been released; the server versions are supposed to ship in summer 2002. However, there are certainly a good number of Windows XP machines running in home or home office environments, and in such setups, these machines are often facing the Internet through DSL or cable modem hookups. On top of that, it is claimed that there are a considerable number of Windows ME or 98 machines running in a similar scenario. Having vulnerable machines exposed to the Internet can lead to many unintended effects. Assuming that the typical home user might not be a computer professional or power user, home user machines hooked up to the Internet often do not run firewall software to block unwelcome traffic. Therefore, these machines are often easily exploitable even for less experienced hackers. As a result, these often easily compromised machines can be used for distributed denial of service attacks, or simply to bounce off other attacks, covering the tracks of the actual attacker. Therefore, just because Windows XP is not yet a widely deployed server operating system, the impact of the vulnerabilities should not be overlooked.
DShield [DSHIELD] is a public web service that provides up-to-date information on the most commonly detected attacks throughout the Internet. A self-described "Distributed Intrusion Detection System", the site is gathering firewall log data from volunteers all over the world. The resulting database allows for very interesting queries: for example, the site provides a top ten list of IP addresses that are identified as executing some kind of attack.
DShield also provides summary reports based on specific port numbers. Since UPnP is implemented over ports 1900 and 5000 (more specifics below), a quick query against the DShield database produces the following results:
As can be seen from the graph, there is not a whole lot of activity reported on port 1900. For the query period, the maximum percentage of activity on port 1900 is only 0.12% out of all activity reported for all ports. More specifically, the maximum percentage is reported on January 13, 2002 , with a total of 1021 records containing activity on port 1900. The highest number of records for port 1900 is reached on January 23, 2002 , with a total of 2072 records.
The report for port 5000 doesn't change the picture much. Port 5000 never reaches more than 0.02 percent (on January 12, 2002 with 204 records) out of all reported activity on any given day. The highest number of records related to port 5000 is reached on January 24, 2002 with 1286 records.
A possible explanation on why the percentages max out around January 12 and 13 might be the release of the second UPnP exploit on the Bugtraq mailing list (see above). Although the exploit uses port 1900, it is possible that people were simply re-running the older exploit (which was against port 5000) as well.
The only conclusion that can be derived from these numbers is that in fact UPnP vulnerabilities are not yet a very common threat, compared to the severity of HTTP based-attacks against Microsoft IIS, for example. The sheer number of vulnerable machines around today simply does not appear to be high enough for attackers to include these attacks in their routine. Furthermore, as we will see, there is, as of now, simply no ready-to-use exploit available that could be used by the silent blackhat masses (i.e., script kiddies). See also the handler's diary entry on incidents.org from 12/21/2001 [INCIDENTS], which comes to a similar conclusion.
In this section, an attempt is made to explain the concepts and specifications behind UPnP as well as certain aspects of their implementation in Windows. Many details on UPnP are missing here, but the intent is to concentrate on the parts that are interesting with regards to the scope of this paper and the vulnerabilities covered.
From the UPnP website:
The Universal Plug and Play architecture offers pervasive peer-to-peer network connectivity of PCs of all form factors, intelligent appliances, and wireless devices. The UPnP architecture is a distributed, open networking architecture that leverages TCP/IP and the Web to enable seamless proximity networking in addition to control and data transfer among networked devices in the home, office, and everywhere in between. [UPNP1]
This brief blurb describes the intentions of Universal Plug and Play. Since more and more devices are networked, be it at home or in the office, there is a certain demand to enable these devices to enter meaningful relationships with each other. The primary goal behind UPnP is therefore to enable devices to connect and to exchange data, in order to offer or use each other's services. As new devices enter the market at a high rate, any given pre-existing device on the network should have a means of discovering services provided by newer devices and vice-versa, on the fly. UPnP describes a set of protocols that will allow devices to talk to each other even though device A might not have any a-priori knowledge of the services offered and protocols spoken by device B, as long as both devices speak a common dialect as specified in UPnP. In the words of the UPnP forum:
Media and device independence. UPnP technology can run on any medium including phone line, power line, Ethernet, RF, and 1394.
Platform independence. Vendors use any operating system and any programming language to build UPnP products.
Internet-based technologies. UPnP technology is built upon IP, TCP, UDP, HTTP, and XML, among others.
UI Control. UPnP architecture enables vendor control over device user interface and interaction using the browser.
Programmatic control. UPnP architecture also enables conventional application programmatic control.
Common base protocols. Vendors agree on base protocol sets on a per-device basis.
Extendable. Each UPnP product can have value-added services layered on top of the basic device architecture by the individual manufacturers. [UPNP1]
Essentially, this means that UPnP is using common connection technology such as Ethernet and so forth, running, over TCP/IP, protocols derived from HTTP (the most common protocol on the internet and foundation of the World Wide Web) that heavily rely on XML documents to exchange information.
Simply said: it is imagined that every possible device will run a TCP/IP stack and be networked accordingly. This is the often cited scenario of microwave ovens and coffee makers having IP addresses and tiny web server implementations built in for users to use their Internet browser in order to interact with these devices. Adding UPnP to the mix adds another layer of specifications for automatic data exchange and discovery in the network. There is nothing revolutionary in here, UPnP is just trying to achieve the same goal as for example Sun's Java-based JINI [ JINI ], just with a more Microsoft-centric approach.
Another technology that tries to connect disparate devices is Bluetooth [ BLUETOOTH ]. The Bluetooth approach is more geared towards wireless links and generally includes proprietary communications specifications which are much more hardware specific and lower level. Whereas UPnP builds on top of a combination of the most commonly used technologies (none of them developed by Microsoft), which some might call a "best-of-breed" approach, and tries to tie them together with some semi-proprietary extensions, mainly manifesting themselves in XML schemas. In Microsoft's eyes, UPnP will, for example, allow the next generation MP3 player to advertise a common interface to the central Windows XP home box, so that uploading and downloading files from and to the player can be handled without having to install any drivers or other device and OS specific things.
To delve into a more technical discussion, UPnP provides a specification called the Simple Service Discovery Protocol (SSDP) that allows devices to dynamically discover the services offered by each other. SSDP works on top of IP networks and is implemented using UDP. Walking through a typical scenario, the first step after powering on a device will be (per specification) to obtain an IP address. This is done either through DHCP (Dynamic Host Configuration Protocol), where a central server in the network is assigning IP addresses from a pool, or via AutoIP, if no DHCP is available. Using AutoIP, there is good change that the device will end up in the same network as the other, unmanaged devices. [ UPNP 2] Once an IP address is obtained, the device can talk via IP to other devices in the same network.
The next step for the device is to advertise its presence to the network. This is accomplished through SSDP Advertisements. These are UDP packets multicast via the 18.104.22.168:1900 multicast address. In this case, the protocol is called HTTPMU (HTTP Multicast over UDP). The target can of course be a unicast address as well, in which case HTTPU (HTTP over UDP) is spoken. There is an Internet Draft available that explains these HTTP [HTTP] extensions in more detail [GOLAND]. The number 1900 specifies the port that other devices need to bind to in order to receive these multicasts. The multicast address is assigned to SSDP by the IANA (Internet Assigned Numbers Authority) and therefore essentially hardcoded. The UDP packet contains a simple HTTP header with the NOTIFY HTTP method and the type of the SSDP message, which in this case is the header field nts: with the value ssdp:alive . The header has more interesting fields, but within the scope of the discussion, only the Location: header is of interest. It specifies a location from which any interested party can download more information on the device sending the announcement. For illustration purposes, here is the payload of a legal packet advertising the presence of a device:
NOTIFY * HTTP/1.1
As can be seen, this is a simple HTTP header with several header fields and the NOTIFY HTTP method. When using HTTPMU/HTTPU, the packets only contain HTTP headers, never any HTTP bodies. The request URI is *, which is a wildcard, but essentially a placeholder, since in the given context the HTTP semantics don't make a whole lot of sense. Since SSDP extends HTTP/1.1 the Host: field is mandatory, and needs to specify the exact same address as the one that used to send the packets (which is a multicast address in this case, of course). We can also clearly see the ssdp:alive value in the NTS: header field. Implementations of the protocol can derive the message type from this field and initiate further actions. One such further action is to look into the Location: header field. This field specifies a URL that implementations of interested devices can use to download more information on the service device. Obviously, using the location specified in the advertisement is a critical feature in the protocol. As we will see, this also has severe implications on the security of an UPnP implementation, since this address does not necessarily contain friendly data.
In addition to devices announcing themselves, the UPnP specification also defines a control-point role. A control point is essentially a device interested in services offered by other devices. The control point listens on the 22.214.171.124 multicast address, bound to port 1900. It will pickup any advertisement, such as the one detailed above, and take appropriate action, such as connecting to the specified location for more information.
The SSDP protocol contains much more than the few essentials covered here (see the "Universal Plug and Play Device Architecture" document [UPNP2]). Of course, there is also an SSDP message to sign-off the network when the device is powered down ( ssdp:byebye ). In addition, control points are supposed to regularly and actively search for devices, which is accomplished through M-SEARCH messages, another overloaded HTTP method. There are additional header fields that allow a more specific search by device type. Any device that finds itself fitting the description then replies, again via UDP, with a packet containing a HTTP/1.1 200 OK status code and an included Location: header field (which will be treated in the same way as for advertisements, as described above).
In Windows XP, the control point functionality is implemented as a service (a program that will run independent of users logging on or off the system, comparable to a daemon in Unix) in the dynamic link library SSDPSRV.DLL . The SVCHOST.EXE executable is used to load the code from the DLL into memory. This SDDP service is running by default on all Windows XP installations. SSDPSRV.DLL listens on ports 1900/UDP and 5000/TCP for all interfaces.
In Windows ME/98/98SE, which are based on MS-DOS and don't have the concept of services, there is a SSDPSRV.EXE executable essentially implementing the same functionality and listening on the same ports.
'Ken' from FTU describes three UPnP related vulnerabilities against "Windows XP and selected versions of WinME" [KEN]. While 'Ken' claims his findings apply to Windows XP and Windows ME, in his detailed paper he only deals with Windows ME machines. Windows ME does not ship with the UPnP services enabled, but certain OEMs are free to enable them in custom versions of Windows ME, which usually ship bundled with PCs. 'Ken's post to Bugtraq [KEN], which announced the vulnerabilities, includes exploit code for all the three vulnerabilities he discovered. These vulnerabilities are classified by CVE as [CAN-2001-0721].
'Ken's exploits work by sending malicious data to the Simple Services Discovery Protocol service on Windows ME machines, which is implemented in SSDPSRV.EXE ( SSDPSRV.DLL on Windows XP machines). SSDPSRV.EXE listens on ports 1900/UPD and 5000/TCP. 'Ken's exploits use port 5000/TCP, sending either a specially crafted SSDP discovery message or simply large amounts of random data.
Opening a TCP connection to port 5000 and sending a special data packet (a harmless SSDP M-SEARCH request, which is a discovery request used to trigger the target to respond with a list of UPnP services implemented by the target) crashes the SSDP service with a page fault in the MSVCRT.DLL - this is the Microsoft C-Runtime library, which is at the core of most programming done for Windows, both by Microsoft and other developers.
Here, a valid header followed by a large amount of random data (typically 'A's) is being sent to port 5000 again. Reportedly, if this is being done with only one connection at a time, again a page fault in MSVCRT.DLL can be observed. However, if the same data is being sent on multiple connections (according to 'Ken' the number is 200 connections), then the system will start using up a lot of CPU time and eventually the SSDP service will crash again.
The third and last exploit described by 'Ken' will simply open up a lot of connections (around 1000) to the SSDP service, which will make the service use up nearly all available CPU resources. According to 'Ken', if the system gets into this state, keyboard and mouse input will no longer be processed. Eventually, the system will correct itself and get back to normal.
eEye Security Advisory AD20011220 describes "UPNP - Multiple Remote Windows XP/ME/98 Vulnerabilities" [EEYE]. The affected operating systems are:
Windows ME does not ship with UPnP functionality, but certain OEMs might change their setup defaults to include it. Windows 98 and 98SE do not contain UPnP modules, however, if Internet Connection Sharing (ICS) is installed on these operating systems, the UPnP modules will also be installed. ICS can be installed from Windows XP setup media on these systems. The intent is to allow the older OSes to use a Windows XP box as a router to enable them to connect to the Internet. The vulnerabilities are classified by CVE as [CAN-2001-0876] (the buffer overflow) and [CAN-2001-0977] (the (D)DoS).
These exploits work over SSDP, the Simple Services Discovery Protocol. SSDP is an UDP-based protocol used for device announcements and discovery and is defined as part of Universal Plug and Play. SSDP uses the UDP port 1900. Announcements and discovery messages are typically sent to a broadcast address of 126.96.36.199, but can also be unicast to a specific IP address. SSDP uses HTTP-style headers as a payload. Please see above for more details regarding the protocol. On Windows XP systems, SSDP is implemented as a service in SSDPSRV.DLL , which is started via SVCHOST.EXE . On Windows ME systems, if UPnP is enabled, there is a SSDPSRV.EXE executable that implements the SSDP service.
The first vulnerability is described as a "SYSTEM Remote Exploit" [EEYE]. From all the vulnerabilities described in the context of UPnP, this appears to be potentially the most dangerous one. The SSDP service can be observed to crash under certain circumstances if the URL specified in the Location: header field in UPnP announcements is being forged and packets are being sent in a certain interval. eEye specifies the interval as being 10,000 microseconds. After a while, the service will crash with an access violation. eEye claims that
In one situation, The EAX and ECX registers will contain addresses that are pulled from the memory that was overwritten and the svchost.exe process will access an invalid memory address at a "mov" instruction. It throws an access violation due to the fact that the destination address is an overwritten pointer, but there is nothing interesting at 0x41414141. [EEYE]
Obviously, there are instances of stack and heap overflows, which are deemed exploitable. This is highly dangerous since the SSDP service runs with SYSTEM privileges, which is the highest local privilege on Windows XP systems. There is (as yet?) no working exploit available for this vulnerability.
The second part of the advisory discusses a problem that is caused more by the protocol design then by its implementation (as the possible buffer overflow discussed above clearly is). SSDP advertisements require control points in UPnP networks to download service descriptions from the URL specified in the Location: header field. At least on Windows XP machines, the SSDP service follows this instruction by the letter: it will connect to the host specified in the URL and it will try to issue an HTTP GET request to retrieve the file specified in the URI part of the URL. The service does not do any kind of checking towards the host that is specified, which leaves plenty of holes. For example, the host specified in the URL could run a chargen (character generator) service, which will simply return an infinite stream of characters as soon as a connection is being made. In fact, directing the Windows XP SSDP service to such a host will cause the XP machine's CPU usage to jump to 100% and to chew up memory, making the system unstable. Eventually, the machine needs to be rebooted.
Another exploit of the same problematic protocol design and implementation is that the XP host can be misused to perform various malicious HTTP requests, such as for example Unicode or double-decode exploits against yet another machine. Since the initiation of these requests is being done through simple UDP packets, attacks of this type do not leave many traces for others to determine their actual source.
On top of that, the SSDP service listens on a multicast address (as described above: 188.8.131.52:1900). Therefore, a single UDP packet can cause all machines running the service to connect to the URL specified in the Location: field at the same time, therefore enabling a Distributed Denial of Service attack scenario.
There is a publicly available exploit for the chargen scenario. Written by Gabriel Maggiotti of qB0x, this exploit contains two small C source files. One file implements a chargen service [QBOX3], for convenience, the other file sends a UDP packet with a user-defined location for the Location: header field [QBOX2]. Using this combination, one can easily verify the behavior presented in the eEye advisory: the XP machine will connect to the chargen and helplessly spin, eating up the data generated by the character generator service.
This is a set of two exploits. It is advertised to run on Windows XP and Windows ME machines. There is no CVE classification for this exploit.
This is again an exploit that is trying to exploit the SSDP service listening on port 5000. Please consult the description in 4.1 for more details.
When run with the -e option this exploit supposedly spawns a shell running cmd.exe, the Windows command line interpreter, bound to port 7788.
When run with the -f option, the exploit attempts to "freeze" the target machine with a technique very similar to the one used by 'Ken'.
Most of these attacks are relatively easy to detect: essentially, one just has to watch traffic on ports 1900/UDP and 5000/TCP. Since these ports are not really in widespread use so far, the following simple set of Snort [SNORT] rules should be helpful as well:
|# HOME_NET is the local network.
# Any UDP against port 1900 with a Location: header field.
alert udp any any -> $HOME_NET 1900 \
(msg:"UPnP\: SSDP with Location field"; content:"location\:"; nocase; classtype:attempted-dos;)
# Catch all: any UDP against port 1900.
alert udp any any -> $HOME_NET 1900 \
(msg:"UPnP\: UDP against port 1900";)
# This is for the buffer overflow exploit from qB0x.
alert tcp any any -> $HOME_NET 5000 \
(msg:"UPnP\: qB0x Buffer overflow attempt."; content:"|4D3F E377|"; classtype:shellcode-detect;)
# This is for the 'Ken' crash exploit on Windows ME.
alert tcp any any -> $HOME_NET 5000 \
(msg:"UPnP\: Crash against SSDPSRV.EXE"; content:"M-SEARCH"; nocase; classtype:attempted-dos;)
# Catch all: any TCP against on port 5000.
alert tcp any any -> $HOME_NET 5000 \
(msg:"UPnP\: port 5000 traffic";)
The rules will pick up all packets sent to port 1900/UDP that have a Location: header field specified. This header field specifies an HTTP URL from which the receiver is supposed to download more information. We have already seen that this is a dangerous feature, so the rule should be helpful here. The second rule will simply catch all UDP traffic against port 1900 in the local network. This is probably a noisy rule, since it will catch all advertisements and discoveries, including the harmless ones that the SSDP service sends on startup, so an administrator might want to disable this quickly after learning about that specific traffic in his network.
The third rule triggers on the jump code in the qB0x supposed root exploit. The fourth rule will detect the crash packet send to TCP port 5000 when the 'Ken' exploit is used with the -ca option. The fifth rule, finally, is again a catchall for all traffic against port 5000 in the local network, with the same noisiness as rule 2.
Microsoft acknowledges 'Ken's findings in Microsoft Security Bulletin 01-054 [MS01-054], and all of eEyes findings in Microsoft Security Bulletin 01-059 [MS01-059]. With both bulletins, patches have been made available to address these issues. The patch for [MS01-059] supersedes the patches released for [MS01-054]. Since there are numerous different patches available for the different operating systems, these patches are not discussed in detail here. Those details can easily be looked up in the referenced Microsoft Security Bulletins, which include the URLs for downloading the patches.
If for whatever reason one does not want to apply the patches, instructions are given on how to simply disable the UPnP services. In Windows XP, the "SSDP Discovery Service" needs to be stopped and disabled (via the "Services" control panel). In Windows ME (and 98/98SE), the "Windows Set-up" in the "Add/Remove Programs" control panel shows a "Communications" component. The details of that entry reveal the UPnP component. Unchecking the UPnP component will disable the service. Again, for more details please consult the quoted Microsoft Security Bulletins.
Most likely the quickest fix available for all the problems discussed here is to simply turn off UPnP support, since, at least for production machines, there doesn't appear to be any benefit in running the UPnP services at this point. On top of that, care should be taken to filter out UPnP related traffic on a company firewall so attacks cannot be tried from the outside of the network. The ports to block are 1900/UPD and 5000/TCP.
There is also a Microsoft Knowledge Base article available [MSKB-Q315056] that explains in how far the patches allow for circumvention of the relay or DDoS vulnerabilities. This is critical, since there cannot be a simple code-fix. The fact that the target machine is supposed to connect to another machine to get information about available services is designed into the protocol itself. On patched systems, there are several ways of regulating this behavior:
There is also a freeware tool called "UnPlug n'Pray", which is working for all versions of Windows and which is turning of the UPnP services [UNPLUG].
[BLUETOOTH] The Bluetooth Special Interest Group. The Official Bluetooth Website.
[CAN-2001-0721] Common Vulnerabilities and Exposures. CAN-2001-0721. 09/27/2001 .
[CAN-2001-0876] Common Vulnerabilities and Exposures. CAN-2001-0876. 01/31/2001 .
[CAN-2001-0877] Common Vulnerabilities and Exposures. CAN-2001-0877. 01/31/2001 .
URL : http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0877
[CNET] CNET News.com. FBI warns on Windows XP hole. 12/26/2001 .
[DSHIELD] Euclidian Consulting. DShield.org - Distributed Intrusion Detection System. URL: http://www.dshield.org/about.html
[CVE-2001-0333] Common Vulnerabilities and Exposures. CVE-2001-0333.
[CYGWIN] RedHat/Cygnus. Cygwin, a UNIX environment for Windows.
[DBGSYM] Microsoft. Windows Symbol Packages.
[EEYE] eEye Digital Security. UPNP - Multiple Remote Windows XP/ME/98 Vulnerabilities. eEye Advisory AD20011220. 12/20/2001 .
[ETHEREAL] Ethereal. The Ethereal Network Analyzer.
[FILEMON] SysInternal. FileMon for Windows NT/9x.
[MAGGIOTTI] Gabriel Maggiotti. UPNP Denial of Service. 01/09/2002 .
URL: http://www.securityfocus.com/cgi-bin/archive.pl?id=1&start=2002-02-07&end=2002-02-13&mid=249238&threads =1
[GOLAND] Yaron Y. Goland. Multicast and Unicast UDP HTTP Messages. 11/09/1999 . URL: http://www-old.ics.uci.edu/pub/ietf/http/draft-goland-http-udp-01.txt
[HTTP] R. Fielding et. Al. Hypertext Transfer Protocol - HTTP/1.1, 07/1999.
[INCIDENTS] Incidents.org. Handler's Diary 12/21/01 . 12/21/2001 .
[JINI] Sun Microsystems. Jini Network Technology.
[KEN] 'Ken' from FTU. Three Windows XP UPNP DOS attacks. Bugtraq, 11/01/2001 .
[MS01-054] Microsoft. Microsoft Security Bulletin MS01-054: Invalid Universal Plug and Play Request can Disrupt System Operation. 11/01/2001 .
[MS01-059] Microsoft. Microsoft Security Bulletin MS01-059: Unchecked Buffer in Universal Plug and Play can Lead to System Compromise. 12/20/2001 .
[MSKB-Q315056] Microsoft Knowledgebase. Preventing Distributed Denial-of-Service Attacks that Use the Universal Plug-and-Play Service (Q315056). 12/18/2001 .
[NETCAT] @Stake. NetCat 1.1.
[NIPC] National Infrastructure Protection Center. ADVISORY 01-030 "Universal Plug and Play Vulnerabilities". 12/20/2001 .
[NMAP] Fyodor. NMAP stealth port scanner.
[PSS] Packetstorm Security. Last 20 exploits. 01/01/2002 .
[PYNNONEN] Jouko Pynnonen. File extensions spoofable in MSIE download dialog. 11/26/2001 .
[QBOX1] Gabriel Maggiotti. WinME/XP UPNP dos & overflow.
[QBOX2] Gabriel Maggiotti. WinME/XP UPNP DOS.
[QBOX3] Gabriel Maggiotti. Chargen Server.
[SANS] The Sans Institute. Computer Security Incident Handling: Step-by-Step.
[SENDIP] SendIP. A commandline tool to allow sending arbitrary IP packets.
[SNORT] Snort. The Open Source Network Intrusion Detection System.
[UNPLUG] Stever Gibson. UnPlug n'Pray. 12/28/2001 .
[UPNP1] Microsoft Corporation. UPnP Forum. About Universal Plug and Play technology.
[UPNP2] Microsoft Corporation. Universal Plug and Play Device Architecture. 06/08/2000 .
[VULNDEV1] Bugtraq vuln-dev mailing list. Universal Plug and Play technology exploit code. 12/24/2001 .
[WINDBG] Microsoft. Microsoft Debugging Tools.