UPnP

Just in case it’s of any interest to anyone…

My interest in UPnP was piqued. I found the odd useful bit of information on the internet about the protocol, and thought I’d try an experiment. The document I found suggested that a bit of HTTP stuff was sent to a particular multicast address and port over UDP, all UPnP server should respond with a little information about the services they offer. Since I know the address of the server I’m interested in, it occurred to me to see if it worked with unicast to its address. It worked!

The text I sent is this:

M-SEARCH * HTTP/1.1
HOST: 192.168.16.1:1900
MAN: ssdp:discover
MX: 10
ST: ssdp:all

The response was:

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
DATE: Mon, 10 May 2021 19:08:17 GMT
ST: uuid:e14b2388-2442-4bd4-8d4b-6b9dec72a6e1
USN: uuid:e14b2388-2442-4bd4-8d4b-6b9dec72a6e1
EXT:
SERVER: Linux/3.4.11 UPnP/1.0 MiniUPnPd/1.9
LOCATION: <a href="http://192.168.16.1:62518/e14b2388/rootDesc.xml">http://192.168.16.1:62518/e14b2388/rootDesc.xml</a>
OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
01-NLS: 1
BOOTID.UPNP.ORG: 1
CONFIGID.UPNP.ORG: 1337

Note that there’s a URL in there, so I pointed a browser at it and got some XML back. It was all in a single line, so I’ve added line breaks and indents:

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0" configId="1337">
 <specVersion>
  <major>1</major>
  <minor>0</minor>
 </specVersion>
 <device>
  <deviceType>urn:schemas-upnp-org:device:InternetGatewayDevice:1</deviceType>
  <friendlyName>BT HomeHub6DX</friendlyName>
  <manufacturer>BT</manufacturer>
  <manufacturerURL><a href="http://www.bt.com/">http://www.bt.com/</a></manufacturerURL>
  <modelDescription>BT Hub 6DX</modelDescription>
  <modelName>BT Hub 6DX</modelName>
  <modelNumber>1</modelNumber>
  <modelURL><a href="http://bthub.home">http://bthub.home</a></modelURL>
  <serialNumber>+091301+2025017531</serialNumber>
  <UDN>uuid:e14b2388-2442-4bd4-8d4b-6b9dec72a6e0</UDN>
  <serviceList>
   <service>
    <serviceType>urn:schemas-upnp-org:service:Layer3Forwarding:1</serviceType>
    <serviceId>urn:upnp-org:serviceId:L3Forwarding1</serviceId>
    <SCPDURL>/e14b2388/L3F.xml</SCPDURL>
    <controlURL>/e14b2388/ctl/L3F</controlURL>
    <eventSubURL>/e14b2388/evt/L3F</eventSubURL>
   </service>
  </serviceList>
  <deviceList>
   <device>
    <deviceType>urn:schemas-upnp-org:device:WANDevice:1</deviceType>
    <friendlyName>WANDevice</friendlyName>
    <manufacturer>BT</manufacturer>
    <manufacturerURL><a href="http://www.bt.com/">http://www.bt.com/</a></manufacturerURL>
    <modelDescription>BT Hub 6DX</modelDescription>
    <modelName>BT Hub 6DX</modelName>
    <modelNumber>1</modelNumber>
    <modelURL><a href="http://bthub.home">http://bthub.home</a></modelURL>
    <serialNumber>+091301+2025017531</serialNumber>
    <UDN>uuid:e14b2388-2442-4bd4-8d4b-6b9dec72a6e1</UDN>
    <UPC>000000000000</UPC>
    <serviceList>
     <service>
      <serviceType>urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1</serviceType>
      <serviceId>urn:upnp-org:serviceId:WANCommonIFC1</serviceId>
      <controlURL>/e14b2388/ctl/CmnIfCfg</controlURL>
      <eventSubURL>/e14b2388/evt/CmnIfCfg</eventSubURL>
      <SCPDURL>/e14b2388/WANCfg.xml</SCPDURL>
     </service>
    </serviceList>
    <deviceList>
     <device>
      <deviceType>urn:schemas-upnp-org:device:WANConnectionDevice:1</deviceType>
      <friendlyName>WANConnectionDevice</friendlyName>
      <manufacturer>BT</manufacturer>
      <manufacturerURL><a href="http://www.bt.com/">http://www.bt.com/</a></manufacturerURL>
      <modelDescription>BT Hub 6DX</modelDescription>
      <modelName>BT Hub 6DX</modelName>
      <modelNumber>1</modelNumber>
      <modelURL><a href="http://bthub.home">http://bthub.home</a></modelURL>
      <serialNumber>+091301+2025017531</serialNumber>
      <UDN>uuid:e14b2388-2442-4bd4-8d4b-6b9dec72a6e2</UDN>
      <UPC>000000000000</UPC>
      <serviceList>
       <service>
        <serviceType>urn:schemas-upnp-org:service:WANPPPConnection:1</serviceType>
        <serviceId>urn:upnp-org:serviceId:WANPPPConn1</serviceId>
        <controlURL>/e14b2388/ctl/PPPConn</controlURL>
        <eventSubURL>/e14b2388/evt/PPPConn</eventSubURL>
        <SCPDURL>/e14b2388/WANPPPCn.xml</SCPDURL>
       </service>
      </serviceList>
     </device>
    </deviceList>
   </device>
  </deviceList>
  <presentationURL><a href="http://bthub.home">http://bthub.home</a></presentationURL>
 </device>
</root>

Maybe someone else might be interested enough to try this and more. Maybe someone knows more about UPnP and can share?

The context for the above is that I have a bash script to renew my free SSL certificates prior to expiry (these are the ones I use for my AcornSSL server experiments), but I have to remember to map the router’s external port 80 to the Linux box for the duration of the script. It would be really cute to get the mapping done and removed in that same script. The router’s firewall rules page shows that two external ports have been mapped by UPnP to some devices on the LAN, so it should be technically possible. Now I know there’s a huge disconnect here, as the cert renewal is done on the Linux box, and my experiments were done on RISC OS, but that reflects (a) that my web searches didn’t turn up any Linux UPnP client that could do it, and (b) my technical curiosity. So it was just an interesting thing to try.

Although, I suppose, if I could get one box to control the other, the disconnect could be solved…

You should treat UPnP as a veracious form of sexually transmitted disease, just say no and turn it off at the router.

If it is left on any piece of Chinese junk on your network can completely by pass any protection your routers firewall may offer.

What you want for your script is port knocking.

Don’t confuse the UPnP as a whole with the specific instances of a UPnP service of routers to open ports which is part of the Internet Gateway Daemon Protocol (sorry, I forget the name).

UPnP itself is a horrendous mishmash of standards used in odd ways – it provides a service discovery system, service descriptions, RPC calls and event delivery. But… using HTTP-like requests over UDP as part of its service discovery to declare or discover services (simple service discovery protocol)… that’s nuts. It’s the only protocol that uses that HTTP+UDP ugliness. The responses describe where a device description can be found, which is a regular HTTP protocol, which responds are an XML formatted description of the devices and their capabilities, which give pointers to objects that you can communicate with (this is the big XML document you cited). The RPC interface that you use to communicate with them is SOAP, so it’s another XML encoded message, this time using SOAP to the same HTTP server.

There’s an event system for getting back messages unsolicited, but I think I had probably lost the will to live by that point and I don’t remember how any of the registration or delivery works.

The Internet Gateway Daemon is one of those services – ah, I see in your XML that’s what you’ve got (and that I got the name wrong – it’s Device, not Daemon) – and that’s usually your router. It doesn’t have to offer the option to open and forward ports. That, as Druck says, is the bad part of the use of the protocol.

UPnP is also used for media controls and sharing, and that’s a whole separate device type.

Horrible, horrible protocol – to implement, and to use. If you’re really interested, http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf is a good starting point (there are later revisions).

And I second his suggestion to turn that off on your router.

My interest in UPnP was piqued. I found the odd useful bit of information on the internet about the protocol, and thought I’d try an experiment.

I bet none of the information sources documented either the security holes¹ the Druck alluded to or the dogs breakfast of mixed ideas that Charles gives some of his precious keyboard time to commenting on.

Find a deep hole and bury it. If you can find it on your router – kill.
If you find it on a PC (SSDP service) – kill.
Oh and the person(s) that created the specification…

¹ It’s probably more hole than substance really

The person that created it. The devices that use it. The routers that allow it.

Kill.
Kill!
KILL!
KILLKILLKILLKILLKILLKILLKILLKILLKILLKILLKILLKILL!!!!!!!

I suspect that the reason that we haven’t heard of any exploits via UPnP in years, is that the devices out there are no longer as insecure/buggy as these old prejudices suggest.

I just managed to open external port 80 to my Raspberry Pi’s port 80 (on which there is no service) by means of a bit of BASIC, using the URL module, via the UPnP protocol. It took me an unreasonable amount of effort; but, as usual, it was interesting. One important take-away is that the BT SmartHub won’t allow opening ports to an internal client of an IP address other than that of the requesting client, which is why I had well-formed SOAP producing an “Action not authorized” error for many attempts until I read the suggestion on the Internet that that was what might be wrong.

So, it’s been interesting, but it still doesn’t solve the original requirement. Not that it really matters at all.

I suspect that the reason that we haven’t heard of any exploits via UPnP in years,

…is because you’re not paying attention.

is that the devices out there are no longer as insecure/buggy as these old prejudices suggest.

I take it you don’t read The Register?

Here’s a story of my own. https://heyrick.eu/blog/index.php?diary=20170617
This thing is still on sale (but less popular as it is VGA res), however there are numerous similar devices with holes and bugs and gaping chasms where common sense fell to its death years ago.

Seriously, huge amounts of domestic IoT kit is utter shit, security (if it ever existed) was added as an afterthought, and UPnP is the way that the device in question can make a problem on your LAN become globally accessible.

April 2018 – https://www.switchfast.com/blog/iot-and-upnp-a-dangerous-combination
July 2020 – https://www.minim.com/blog/the-upnp-security-exploit-affecting-millions-of-home-devices
November 2020 – PDF from ResearchGate (long URL)

Old, but a long list of problems with UPnP: http://www.upnp-hacks.org/

Note, also, that UPnP isn’t the exploit vector. It’s simply the mechanism by which some insecure piece of crap can punch a hole in your defences, and it’s that that gets exploited. If you find your toaster has been using your internet connection to bleat out spams using your own email address, you may well freak out and drop-kick the toaster across the garden long before you start asking “how did that even happen?”. Answer? Because it asked your router nicely if it could bypass any port blocking and firewall settings that might have been in place. Because UPnP let it.

It took me an unreasonable amount of effort; but, as usual, it was interesting.

I know how you feel. Things that aren’t straight web fetches can be… complicated.

using the URL module

That worked with UDP?

won’t allow opening ports to an internal client of an IP address other than that of the requesting client

Well, thank god it isn’t totally braindead!

Does your router not have a way to set up port forwarding making UPnP redundant?

It is slightly more work, but it’s more flexible. As devices that provide a web server think they are all port 80, which can be messy if several devices are telling the router that they’re all wanting port 80.

I take it you don’t read The Register?

Every weekday, without fail.

Seriously, huge amounts of domestic IoT kit is utter shit

The only IoT things in our house are either top brands (assuming that a television counts as IoT), or things that I’ve written.

Does your router not have a way to set up port forwarding making UPnP redundant?

UPnP appears to be the industry standard. There is a web page for firewall setup, of course; I just thought it would be really cute to automate this if I could, because it would be an interesting challenge.

(Renewing SSL cerver certs is done via certbot – look it up. I use it in standalone mode. To verify that I own my domain, the certbot server has to access a web page at the IP address that my domain resolves to. This requires that I open port 80 for the duration of the verification. The certbot client has its own web server – that’s what standalone is about. Once the verification is done, the port mapping is deleted.)

using the URL module

That worked with UDP?

UDP is necessary for the initial service discovery, because a client doesn’t know how many UPnP servers (if any) there are, or their addresses, so TCP is out of the question. The initial service discovery has to be through either multicast or broadcast. Multicast (239.255.255.250) was chosen for UPnP. Once the server(s) has/have replied, further communication is via TCP.

If you permanently want a device to be able to receive traffic on a particular port, port forwarding is what you use. For example one of my Raspberry Pi’s can accept ssh connections – but using a port number other than 22 to reduce the most obvious hacking attempts (it also has no root, keys only and sshguard running).

What Dave wants to do is only open the port for a limited time, that is where port knocking/triggering comes in. You set up your router so when your device accesses an out going address and port, it opens up an incoming port routed to the device, but only allowing that incoming connections from that address to use it for the duration the outgoing link is active.

Every weekday, without fail.

Good. :-)

The only IoT things in our house

One commercial domestic IP camera (having survived numerous attempts to hack it through common vulns). Everything else is something I have written based upon either RISC OS or an ESP32. While I cannot vouch that the ESP32 firmware doesn’t have faults, it’s ubiquitous enough that if there was something wrong I’d have heard about it.

UPnP appears to be the industry standard.

So is Word…

UPnP makes it “easy” for users who have never seen their router’s management pages (like, it was set up by a friendly app or CD that the ISP provided) to be able to install stuff that “just works”. Of course, the convenience of not needing to know what you’re doing comes with the downside of not knowing why what you’re doing is a bad idea.

because it would be an interesting challenge.

A perfectly acceptable reason.
The problem here isn’t that you’re writing something to work with UPnP, the problem is that you (still) have it running on your router. ;-)

UDP is necessary for the initial service discovery

Sorry, you misunderstood – I was expressing surprise that the URL fetcher supported UDP. Or did you do that bit as raw socket and switch to the URL fetcher afterwards?

that is where port knocking/triggering comes in.

Might be outside the capabilities of ISP-supplied routers, there. I don’t think my Livebox can do such a thing.

Maybe someone else might be interested enough to try this and more

Looking at what you have described in the first message, it seems quite similar to the IPP device capabilities report. A wonky HTTP request (binary payload!) that gets a big wodge of XML back.

I was expressing surprise that the URL fetcher supported UDP. Or did you do that bit as raw socket and switch to the URL fetcher afterwards?

The latter. I modified and re-purposed my old UDPTx app for the service discovery, and used Wiresalmon to capture the traffic. Once I read the information in the replies, I used that to write some code that used the URL module.

Very much a knife-and-fork process, but it’s all good experimentation :-)

I’ve also got an app to delete the mapping. It’s very similar – no surprise there – just a bit simpler.

During the course of the experiments, I discovered that the router changes its unicast port from time to time. (I have no idea how often, or what causes it to change – time, or some event – I’ve only seen one change.)

UPnP appears to be the industry standard.

So is Word…

and thanks to MS arrogance when presented with a proof of concept, so is the Concept macro virus and its descendants.

Along with work colleagues I tend to go with the idea that “it isn’t paranoia if they are out to get you”
Firewalls, can I get to… the first answer is no, the responding question is “why do you want to”? followed by, “please justify that”
Honestly, the proxy auto-response asks people to request and supply justification and that’s just the proxy filter…

A wonky HTTP request (binary payload!) that gets a big wodge of XML back.

I don’t know whether you’re referring to IPP or UPnP, but UPnP is all text-based AFAICS.

A little postscript.

There is one small way in which UPnP might actually be more secure than manually opening a port. That’s because my router, a BT SmartHub 6, doesn’t allow the remote party’s address to be specified when opening a port – it’s open to allcomers. UPnP allows the remote party to be specified, thus limiting the possibility of attacks.

Admittedly, it isn’t easy (if it’s possible at all) to know how often this field is filled in, so it might be no more than a theoretical advantage.

Any theoretical safety from limiting the incoming port is outweighed by any device inside your networking being able to open up anything it wants to all comers.

Where as port knocking, as I have described, is inherently limited to the incoming and outgoing address and port combinations which you choose to setup in to the router, so cannot be exploited by an arbitrary device¹.

¹ Which could even be something in your browser thanks to web sockets.

Another postscript, demonstrating my propensity to spend an inordinate time and effort on something inconsequential…

I’ve completed the process of scripting the opening and closing of the firewall pinhole, so the three operations (open pinhole, renew certs, close pinhole) are driven by one script. The first part is a Python prog to send a UDP message to the router, and parse a URL out of the response. The second part is to POST and XML body to that URL. The XML body is constant, so it’s in two files: one to open the pinhole, one to close it, so the easy way is to get the Python to launch wget.

Some observations of security, as I see it (and please feel free to try to persuade me I’m wrong):

• Port knocking would require me to make changes at both ends of the link, i.e. the cert renewal software and the router. I have that level of access to neither, so port knocking is out of the question.

• Control of UPnP is not available from the Internet – only from my internal network.

• The URL of the router’s UPnP control function has two fields that change – the port number, and a 32-bit “random” number. Presumably this is to make replay attacks more difficult.

• The router will only accept commands to open the firewall from the destination device.

• If a device is going to open the firewall up on behalf of a hacker, the device must already have been compromised, so it seems to me that UPnP doesn’t materially add to the risk. Chicken and egg seems to work in my favour here.

• I’m happy that what I have here is not a brain-dead UPnP implementation, despite its having been supplied to me from BT.

So there we are. I’ve spent far more time on this exercise than I would have, manually altering the firewall for all the remaining cert renewals for the rest of my life. But it has been interesting.

If a device is going to open the firewall up on behalf of a hacker, the device must already have been compromised, so it seems to me that UPnP doesn’t materially add to the risk.

If you read the details of the second wave of exploits on the log4j problem, you will see that these employ malicious code on a website that the user might visit.
Of course, if you don’t have anything other than RO devices on your LAN, then the lack of Java does limit the potential for that particular exploit route.

Interesting. So Java provides a bigger attack surface than UPnP?

So Java provides a bigger attack surface than UPnP?

Lots of coverage for the spread here and here and many others.

Let’s just say that although the main focus is on software using the v2.×.x version and suppliers are busy saying to customers “not affected” because their software uses an antique version 1.×.x¹ – it’s all vulnerable, perhaps not in the same way² but plenty of known holes.³

Work aplenty in all support setups…

¹ End of life 2015 link

o Java provides a bigger attack surface than UPnP?

Does it make sense to compare a programming language with a network protocol? Since you can do an UPnP implementation in Java, it is logical that Java is able to provide a superset of attack surfaces :-)

Anyway, the log4j problem Steve referred to is a log4j problem, not a Java problem (and sensible people use a logging facade so were able to switch to a different logger immediately after the problem became widely known). The way the various exploits work suddenly stop working if you encapsulate your server properly, which you should do anyway no matter what software (including the OS) you intend to run. And the good thing in Java/the JVM is that you can e.g. make sure that only properly signed code is ever loaded by the classloader and get executed by the JVM.

But you see where the problem is: you need to THINK about these security measures and then ACTUALLY IMPLEMENT them. This is the real reason why so many security problems exist in our wonderful IT world.

I was comparing what Java and UPnP provide. I wasn’t comparing Java and UPnP themselves.

Anyway, the log4j problem Steve referred to is a log4j problem, not a Java problem (and sensible people use a logging facade so were able to switch to a different logger immediately after the problem became widely known).

Which quickly puts various well known IT equipment and software manufacturers into the NOT sensible classification, along with a good chunk of the rest of the world.