|
On December 20, 2001, eEye Digital Security, the security firm that gave the Code Red worm its name, announced the discovery of “major security vulnerabilities”[1] in Microsoft’s flagship operating system, Windows XP. Specifically, the vulnerabilities were discovered in Microsoft’s Universal Plug and Play feature, which ships by default with XP. On that same day Microsoft released a patch [2] that resolved the issue; however, it was a dismal ending to a year that saw security flaws in Microsoft products announced in the press on a weekly basis [3] and exploited in hundreds of thousands of computers worldwide.
This article will examine what UPnP is, what the Microsoft UPnP vulnerability is, how it can be exploited, what the impact on a network could be and what users should do to protect themselves.
What is UPnP?
According to the UPnP Forum, “UPnP defines common protocols and procedures to guarantee interoperability among network-enabled PCs, appliances, and wireless devices.” [4] The purpose of UPnP is to establish seamless peer to peer networking between disparate devices on a TCP/IP network. The goal of the UPnP Forum is to bring ubiquitous computing to the home and SOHO [5] market so that devices like coffee makers, refrigerators and room temperature controls can be networked together with computers, printers, routers and other networking devices.
There are six distinct functionalities to UpnP [6]; device discovery, addressing, description and activation, event messaging and a control interface. When a device first comes on line, it announces its presence to the network by a broadcast message and obtains an IP address either through DHCP or by selecting from a list of available IPs. Control points can then address the device to obtain a description of the services it provides, determine its current status and transmit commands to control its behavior. All messaging (status, control and presentation) is conducted over variations of HTTP [7] using XML.
At present, UPnP is being developed for home appliances and other devices such as CD ROM changers, but development is underway to extend UPnP to include industrial machine tools as well. It’s not hard to imagine extensions of UPnP reaching into many different areas. The idea of being able to control a large number of diverse devices through one common protocol is attractive. From its original design of extending the home network, UPnP could easily be further extended to include power plant controls (coal-fired, hydraulic and nuclear), power distribution across a regional or even national grid, entire manufacturing plant processes, large transportation systems (through the use of wireless technologies) or traffic movement across a metropolitan area (through traffic control devices.) Many more uses for such a protocol could easily be envisioned, and new uses are being discussed every day.
In principle, UPnP sounds like a worthwhile goal. However, its implementation raises serious security concerns. In the technical description of their discovery, eEye promised to publish a “detailed paper” discussing these problems, stating, “We at eEye believe that there are several security issues with the UPNP protocol itself; however, these more generic issues are out of the scope of this advisory.” [8] Among these will most likely be concerns about device authentication, authorization and spoofing, and multiple HTTP weaknesses (cross-site scripting issues, iframe vulnerabilities, active content parsing, etc.), all of which can lead to DoS and DDoS attacks as well as compromise of a single device or possibly an entire network.
The UPnP Vulnerability
When eEye announced the discovery of the UPNP vulnerability [9], they described three attack scenarios; a remotely exploitable buffer overflow, a Denial of Service attack and a Distributed Denial of Service attack. Of these three, the buffer overflow is by far the most serious. It could lead to a remote compromise of a machine, surrendering complete control of the machine (and possibly an entire network) to its attacker.
Buffer overflows are one of the most common security problems found in software. Their security implications have been known for well over twenty years, yet they remain one of the most frequently discovered security vulnerabilities in software.
In order to understand buffer overflows you must understand how arrays work. Arrays are a software form of storage, a place where data can be “parked” so it can be used when needed. Think of them as a long line of boxes, each one capable of holding one piece of information. If the line of boxes numbers 256, when you have 257 pieces of information, there’s no place to put the last one. All the boxes are full. Physically, you solve this problem by getting another box, but arrays don’t work that way. Their size is fixed, and when you come to the end of an array, you don’t get to decide where the next piece of information goes, the computer does.
This can lead to very interesting results. Often the next piece of information will be placed in a “box” that a program needs in order to run. The information that was in that “box” is summarily discarded and replaced with the information that should have been in the array. Sometimes this can lead to odd results in a program, but many times it will lead to a program crash. When a program crashes, a cleverly written exploit can often take advantage of the crash in such a way that it can take over control of the computer.
The buffer overflow that eEye discovered is related to the NOTIFY event message. When a device experiences an event, it sends a NOTIFY message, using HTTPMU, to all the control points that are monitoring it. (Control points are computers that have “subscribed” to various devices in order to monitor them and control their behavior.) The data encapsulated in a NOTIFY message is:
NOTIFY * HTTP/1.1 Host: 239.255.255.250:reservedSSDPport (1900) NT: blenderassociation:blender NTS: ssdp:alive USN: someunique:idscheme3 AL:
The Exploits
When a NOTIFY message is constructed carefully and sent at certain speeds, access violations begin to occur in the control point’s SSDP (Simple Service Discovery Protocol) service. eEye found that “there are multiple points of exploitation. We found instances of stack overflows and heap overflows, both of which were exploitable. In the case of the heap overflow we saw pointers being overwritten for both buffers and functions.” [11]
These problems, eEye points out, affect the “SSDP service [which] also listens on multicast and broadcast addresses. Therefore gaining SYSTEM access to an entire network of XP machines is possible with only one anonymous UDP SSDP attack session.” [12] In other words this is the first known exploit that can compromise an entire network with just one attack!
Both the DoS and the DDoS exploits also take advantage of a weakness in the NOTIFY messaging system. It is possible to construct a NOTIFY message so that a control point will open a session to another computer, connecting to its chargen service. The resultant read/malloc loop will consume 100% of the control point’s CPU and allocate all of its physical memory, forcing a physical reboot. This is possible because no error checking is done on the LOCATION URL that is sent by the NOTIFY message. The DDoS exploit uses this same vulnerability, taking advantage of the broadcast and multicast nature of SSDP to direct an attack from multiple “devices” against a single victim or against a range of victims.
How This Affects Networks
The impact of this vulnerability on networks could be devastating. In the case of a DDoS attack, it is possible to force the physical reboot of every vulnerable machine on a network. The man-hours required to restore operations would be costly, and without added protection the same machines would fail repeatedly. However, the damage this would do to a network pales in comparison to the havoc that could be wreaked by taking over the SYSTEM accounts of every vulnerable machine.
The SYSTEM account in Windows is the most privileged account in the operating system. Essentially, it has access to the entire OS. Compromising the SYSTEM account amounts to turning Windows XP into a system similar to Windows 98 and ME, where there is no security at all. The attacker can then do anything they want, from launching attacks on other networks to stealing and/or deleting all the data on a machine. Using the broadcast and multicast aspects of the SSDP service to launch an attack would allow an attacker to roam freely throughout the network, picking and choosing the data to steal, marshalling an army of robots to attack other sites and damaging the reputation of the attacking network in the process. When the attack was completed, the attacker could then erase all evidence, disappearing without a trace and leaving the network owners to explain (and pay for) the damage.
How To Protect Your Network
The first thing network administrators should do is block port 1900/UDP and port 5000/UDP at the edge of their network. There are few compelling reasons for computers on a network to be able to detect external devices and even fewer compelling reasons to control internal devices from an external location. If this need does exist, it should be addressed through VPN, dedicated lines isolated from the Internet or similar methods of protecting critical network functions from external access.
Once the network is protected from external attacks, network administrators need to determine the extent of vulnerable computers that they have. Obviously every Windows XP machine is at risk. Windows 98 and 98 SE machines are also at risk if they have Internet Connection Sharing installed. (Although this is unlikely to be the case in a large network, it may be common in the home and SOHO area.) Windows ME is also at risk since it ships with native support for UPnP. Although Microsoft sets the default to service being turned off, many OEM computer manufacturers ship it enabled.
Next, they should patch every vulnerable computer and then decide, for each one, whether they really need the SSDP service running. A fundamental principle of security is to disable all unnecessary services. Certainly SSDP qualifies as a candidate for this remediation in many cases, and it should be the preferred method of protection if at all possible. You should never assume, however, that because you turned off a service it will remain off. Therefore, every system should be patched, whether or not its designed use includes UPnP.
Finally, methods should be put in place to ensure that no new, un-patched devices will be added to the network Scanning for devices listening on port 1900 and 5000 should be added to the routine scans that security personnel perform, and routine network inventory checks should include searching for machines that are un-patched. If a network uses “smart” switching, deciding whether to route SSDP traffic internally should be considered carefully. After considering all the above steps and implementing them correctly as needed network administrators can be assured that their network is well protected against this extremely critical vulnerability.
References
[1] http://www.eeye.com/html/press/PR20011220.html
[2] MS01-059
[3] Microsoft released 60 security-related patches in 2001
[4] http://www.upnp.org
[5] SOHO is an acronym for “single office, home office”
[6] For a more detailed description of UPnP, see EDN Access
[7] HTTPMU (HTTP Multicast UDP), HTTPU (HTTP Unicast UDP), GENA (General Event Notification Architecture), SSDP (Simple Service Discovery Protocol) and SOAP (Simple Object Access Protocol)
[8] http://www.eeye.com/html/Research/Advisories/AD20011220.html
[9] The vulnerability also affects some versions of Windows 98 and Windows ME
[10] More information about UPnP specifications may be found here
[11] http://www.eeye.com/html/Research/Advisories/AD20011220.html
[12] ibid.
|