UPnP

There is a difference between something that has retrospectively found have an exploitable defect (log4j), and something whose explicit purpose it to make it as easy as possible for a cheap IOT device to bypass any security you have on your home network (UPnP).

something whose explicit purpose it to make it as easy as possible for a cheap IOT device to bypass any security you have on your home network (UPnP).

While that might be a (ab)use of UPnP, it isn’t the actual “explicit purpose”.

While that might be a (ab)use of UPnP, it isn’t the actual “explicit purpose”.

Indeed.

Let’s look at the IoT devices I have. There’s an Amazon Alexa, and TVs by Samsung and Panasonic. Reasonably respectable, I’d have thought, i.e. not to be classed along with any “cheap IoT device”. There’s a WD MyCloud drive, which does use UPnP for the very good reason that its reason for being is to be available via the Internet. I say “does”, but in fact it doesn’t any more, as WD have repeatedly emailed me (and presumably all owners of similar devices), as they’re out of support and WD considers them vulnerable, so I’ve disabled access from the outside world.

I’ve got three Sonoff devices, but I used Tasmotizer on them immediately they arrived. So I think they’re safe too.

I suppose the heating controller should be classed as IoT, but I programmed that myself, and I believe it to be fairly secure.

So the IoT stuff looks to me to be OK from a security PoV.

Except that, of course, anything on the LAN can go out and bring in whatever it wants – and the televisions very definitely do, by the bucketload. They are then free to spray anything around the rest of the LAN devices. That sounds to me to be a hugely riskier issue than UPnP. I’ve never heard of a way to isolate them from the rest of the LAN, other than a separate LAN segment, which would be a major challenge and would require a separate wifi AP AFAICS.

Does the team not think that any rogue device on a LAN can import whatever it wants, without needing to use UPnP?

Does the team not think that any rogue device on a LAN can import whatever it wants, without needing to use UPnP?

A device within the local network needs to open connections, and devices can be limited (in time or abilities) plus ports and addresses can be blocked (depending on the capabilities of your router).

I still have my insecure IPcam running from time to time. The Livebox knows its MAC and is under strict instruction to disallow any external access.

UPnP, on the other hand, is a little piece of rope that says “Pull me!” permitting any old device to not only bypass the firewall but also open external ports and set up port forwarding, so a device could happily expose, say, port 1234 at your IP and sit waiting for whoever and whatever externally to connect.
Turn the damn thing off!

and the televisions very definitely do, by the bucketload

I have no experience with smart televisions (the very idea sounds unpleasant), but… perhaps PiHole might be of use to tame what a foreign company knows about your viewing habits?
https://pi-hole.net/

One of the TVs is used exclusively for Internet TV (SWMBO won’t allow an aerial cable for this one) so the providers know everything. SWMBO also uses Netflix.

As for turning UPnP off, I keep coming back to the same chicken-and-egg point: if there’s no rogue/compromised device on the LAN, then UPnP cannot be used and thus the firewall won’t be opened. If OTOH there is a rogure/compromised device, it doesn’t need UPnP – it can perfectly well allow stuff in anyway, in fact it can go and get it, and can keep a connection open as long as it wants. If at some point a device is compromised, it wasn’t UPnP that did it. You’d have to find some other way to compromise the device before it was able to abuse UPnP.

I say “UPnP cannot be used” because I believe that to be true of a respectable modern implementation, and I believe that’s what I have here. I recognise that some earlier implementations were insecure, but, from what I read (perhaps more accurately, what I don’t read), UPnP is no longer a problem. Come on, guys, we’ve moved on many years since those bad old days.

Except that, of course, anything on the LAN can go out and bring in whatever it wants – and the televisions very definitely do, by the bucketload.

That is far less of a problem than an IOT device instructing your router to open an incoming port which allows any external entity probe it’s vulnerabilities. It massively increases your attach surface.

As for turning UPnP off, I keep coming back to the same chicken-and-egg point: if there’s no rogue/compromised device on the LAN, then UPnP cannot be used and thus the firewall won’t be opened. If OTOH there is a rogure/compromised device, it doesn’t need UPnP – it can perfectly well allow stuff in anyway, in fact it can go and get it, and can keep a connection open as long as it wants. If at some point a device is compromised, it wasn’t UPnP that did it. You’d have to find some other way to compromise the device before it was able to abuse UPnP.

All it needs is for someone to compromise a firmware update for any device (lots of shoddy certificate checking which allows MIM attacks) and with UPnP enabled, that device can then serious pop your security bubble. A few bytes to setup UPnP can easily be added a very simple device, one which would not be suitable for running malware payloads which could attack your network from the inside.

I say “UPnP cannot be used” because I believe that to be true of a respectable modern implementation, and I believe that’s what I have here. I recognise that some earlier implementations were insecure, but, from what I read (perhaps more accurately, what I don’t read), UPnP is no longer a problem. Come on, guys, we’ve moved on many years since those bad old days.

That would be the case as long as you only have devices on your network where you’ve written every shred of code from the boot loader upwards.

I’ll just leave this here…

https://www.upguard.com/blog/what-is-upnp

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.

This neatly sums up the whole situation of nowadays IT – non-professional, dangerous, amateurish…the log4j problem however could have been also prevented by those operating these software packages, it was not only a manufacturer problem.

Since you often mention the dire situation wrt misconfigured webservers, I guess our opinion about these things is very similar.