In this article we told our readers of a Dutch student who had found a bug in the UPnP-protocol.
Today, at the SANE Conference, he’s telling the world what the flaw is. While he is in the Netherlands telling those people how it works, we are proud to present it to you, our readers. In addition to my detailed discussion below NIST.org has additional information and discussion on the subject.
Introduction
In February of this year, a student from the University of Utrecht in the Netherlands reports a flaw in the UPnP protocol to Linksys. In January he had told Microsoft about the bug and Broadcom was informed in March 2006. Microsoft’s response to him was that the bug only exists if a router was configured incorrectly. Broadcom didn’t respond to him until he wrote his Proof of Concept paper in April. Recently he was informed that Linksys made a new firmware available for some their devices, but not all of them, that corrects this problem.
Do the flaws Armijn found really only exist in routers with incorrect configurations? Or is Microsoft wrong and are the flaws as bad as Armijn Hemel says they are?
The UPnP Protocol
Most readers are at least aware of the UPnP Pprotocol. It is used in a lot of SOHO type routers and is used by some popular client applications such as MSN Messenger and Microsoft’s XBOX-Live. The UPnP protocol is not only used to configure routers. UPnP is also used, for example, in VoIP-applications to dynamically open ports on the router.
The UPnP-protocol uses well know Internet standards, like XML, HTTP and SOAP. Because of the scope of the flaws Armijn found we are going to focus on the way UPnP opens ports and forward ports to devices.
How UPnP Works
For UPnP-devices to find each other discover messages are used. These messages are being send to 239.255.255.255 port 1900 UDP in XML format. In response to a discover message a response message is sent with a location where a XML file can be downloaded. When a connection is made, a UPnP-device can ask another device (e.g. a router) to configure some things.
Configuring of Port Maps
The following can be uses to configure a portmap from a router to a devices with IP-address 10.0.0.151:
Adding a port mapping for the machine located at the IP
address 10.0.0.151 can be done with the following code:
soapaction2=”urn:schemas-upnp-org:service:WANPPPConnection:
1#AddPortMapping”
server._sa(soapaction2).AddPortMapping(NewRemoteHost=”",
NewExternalPort=8080,
NewProtocol=”TCP”,
NewInternalPort=80,
NewInternalClient=”10.0.0.151″,
NewEnabled=1,
NewPortMappingDescription=”internal webserver”,
NewLeaseDuration=0)
When we look at this we see that port 8080 on the router is being forwarded to port 80 on client 10.0.0.151. Not a big deal, isn’t it? And nice UPnP let’s you do it.
But wait, I didn’t mention any authentication, did I?
The flaw
Ok, I mentioned it above. There is no authentication. Of course, the UPnP Forum defined a security model, but is it used? Let’s take some examples that Armijn has written about in his paper:
Exposing Internal Machines to the Internet
Port forwarding / port mapping is a nice feature available to the UPnP-protocol, and it can be configured by an easy command, as mentioned above. Let’s look at this example:
(c)Armijn Hemel
The above example shows us one of the flaws Armijn told me about. What if a piece of spyware tells the router to open a port to a SMTP Daemon? Will it be able to send out emails through our host on the inside network? Armijn says it can, and I beleave him.
But if you think this is bad, let’s look at another example:
I’ll quote Armijn for this one:
Using UPnP to Create Proxies and Hijack Ports
At least one implementation of an Internet Gateway Device (router) profile allows anyone on the internal network to set the Internal Client parameter as used by the AddPortMapping SOAP function to any machine on the Internet. This implementation was developed by Broadcom for their router platform. It can be found in certain revisions of the Linksys WRT54G(S) and a lot of other Linux-based routers and access points (the hardware list on the OpenWrt Wiki gives a good indication which devices are based on the platforms Broadcom makes).
The problem with the Broadcom implementation is that the Gateway Device doesn’t check if the InternalClient parameter is a machine on the inside LAN. Because of this error, the Gateway will perform NAT on the incoming packages to the InternalClient even if it is on an external interface.
This means that all traffic on ports on the Gateway can be forwarded to other machines that are also on the external interface. An attacker can exploit this bug to have his own traffic routed to the internet and creating his own onion routing system.
And it can still be worse!
Let’s Create Chaos!
Aside from adding a port mapping other actions can be performed on an Internet Gateway Device, including deleting port mappings. Deleting existing portmappings can disrupt the correct working of programs.
The focus in Armijn’s paper is on the Internet Gateway Device profile in general and the WANIPConnection and WANPPPConnection profiles in particular. But there are probably a lot of other opportunities which he didn’t test. Hacks he could think about to create chaos are:
- shutting down routers by using the LANHostConfigManagement subprofile
- injecting false DNS-records by using the LANHostConfigManagement subprofile
- abuse HVAC controls with UPnP
- remotely control IP cameras, of which some seem to be using the UPnP AV profile
Conclusion
I hope that we have cleared stuff up a bit, and want to thank Armijn Hemel for providing his paper on such a short notice. If you want to learn more about this vulnerability we hope to put up Armijn’s email address and his SANE paper on the forum as soon as he gives us his permission.
)