Conficker Attacks UPnP
The Conficker worm behavior has been analyzed by many security professionals who have shared their findings with the community (the paper from SRI is a great example). One of the common findings is that Conficker will connect to the local route/gateway via UPnP and make changes to the firewall, if the firewall supports unauthenticated UPnP. If so, it uses UPnP to open a high numbered port in the firewall, allowing access to that port from the Internet. It then opens the same port on the infected host, and uses it to distribute the worm further across Internet. The use of UPnP as well as insecure UPnP devices can be detected by Tenable's Nessus and PVS products.
Identify UPnP With Nessus
To test how Nessus identifies UPnP, I setup a Linksys WRT54G V8 router, running the factory firmware, with UPnP enabled. I used Nessus to scan the WRT54G and two plugins detected the presence of UPnP on hosts and devices. There are other Nessus plugins that detect UPnP, but the following two provided the most interesting information. The first is plugin 35711, "UPnP discovery", which connects to UDP/1900 and tests to see if the host supports UPnP. This port is associated with SSDP, or Simple Service Discovery Protocol, used by systems implementing UPnP to advertise the services they are offering.
The above plugin queries the device and retrieves the UPnP configuration. Notice that the URL, http://192.168.1.65:2869/IGatewayDeviceDescDoc is hosting an XML file which contains the complete UPnP configuration and supporting features. If this exists, Nessus plugin 35709, "UPnP Internet Gateway Device", will connect to the TCP port found hosting the XML file (in this case 2869/TCP) and attempt to create a new firewall rule using UPnP. If successful, you will see an entry as shown in the following report:
Detect UPnP with PVS
The Tenable Passive Vulnerability Scanner (PVS ) can passively detect UPnP activity on the network. Below you can see the UPnP activity flagged in a summary report on the Tenable Security Center:
You can also view the details on this alert to see which host triggered it:
Detecting Change With LCE
The Tenable LCE (Log Correlation Engine) will also detect if a firewall supporting UPnP rules is updated. Most firewall/SOHO routers will generate a log entry as follows:
Fri Mar 13 08:32:09 2009 D-Link Systems DIR-825 System Log: UPnP added entry 255.255.255.255
126.96.36.199:47944 192.168.2.100:47944 TCP timeout:-1 'uTorrent (TCP)'
Fri Mar 13 08:32:09 2009 D-Link Systems DIR-825 System Log: UPnP added entry 255.255.255.255 188.8.131.52:47944 192.168.2.100:47944 UDP timeout:-1 'uTorrent (UDP)'
This particular entry comes from a Dlink DIR-825 and shows IP address and port pairs, displayed in bold, that were opened using UPnP. Both TCP and UDP ports 47944 were opened from host 184.108.40.206 to host 192.168.2.100. The application name is included at the end of each entry, in this case uTorrent. uTorrent is the application running on 192.168.2.100 and most likely opens the specified ports to allow BitTorent traffic (uTorrent is a popular BiTorent client). If this device is is configured to send logs to the LCE, you will see the change detected as shown below:
The above graph depicts the detected change as occurring 163 times in a 24 hour period. If the device is a firewall, as in this example, this is a significant number of changes for the time frame and deserves further investigation.
The availability of UPnP services poses a risk to your network as it can allow unauthenticated requests change device settings. Enterprise firewalls often do not support this feature (although most support TFTP which also does not have authentication built-in). This does not mean UPnP is absent from corporate networks, users could bring UPnP capable devices to work, and other embedded devices will typically support UPnP (network-based web cameras for example). Don't just rely on your firewalls to make sure UPnP is not enabled in your environment: scan your network to make sure.