I am not defending them for not keeping their stuff up-to-date, but it is very common practice for embedded systems to be hopelessly outdated. I've done what OP describes with IPMI/BMC systems for $mainboardmanufacturer1 and $mainboardmanufacturer2 (both really big name brands), and their BMC systems were equally outdated. It was almost comical, but really sad at the same time.
Moral of the story is to firewall things off really well, I suppose.
At $oldjob, I designed an upgrade mechanism to do A/B image updates so things were always up to date, or at 2-3 weeks out of date. See [1].
For small embedded systems that do not have enough space/bandwidth, this may not be feasible though.
Even if it didn’t have the intentional backdoor… you probably should be treating it as hostile anyway.
Even where not intentionally hostile, not intentionally privacy invading, not trying to fetch updates so it can show you more ads, not… most of this stuff is so hopelessly out-of-date and full of security vulnerabilities it’s only not hostile out of luck.
I don’t connect anything to WiFi unless absolutely necessary. And by that I don’t mean “the device demands it” (I just won’t buy the damn thing) but “it’s a core part of the functionality I’m asking of it”. I’ll prefer zwave/zigbee, Bluetooth, or something else wherever possible when communication is required. (If I were forced to use this bed and it had no manual controls I would definitely have used Bluetooth, avoiding this whole issue.)
And even for the devices that do get a WiFi connection… they run entirely isolated, on a separate SSID and VLAN from my normal devices and traffic, and with a whitelist for what traffic is allowed.
As far as I’m concerned the only difference between this bed and the other devices is that we know about the issues with this bed. We have no reason to believe that the other devices are any better, and in fact a pretty large body of evidence suggesting that they’re probably not.
> And even for the devices that do get a WiFi connection… they run entirely isolated, on a separate SSID and VLAN from my normal devices and traffic, and with a whitelist for what traffic is allowed.
This is what I do today, and honestly I'm about to give up. We lost. Trying to get stuff like airplay / DLNA to work via mDNS is already impossible across subnets, and telling family to switch networks if they want to control X with their phones is just a shit solution. I have to disable 90% of my vehicle's "infotainment" screen to not feel spied upon, and which breaks the app I can use for remote starts, etc.
Maybe when the "Mega-Hack of 2025" happens and all IoT devices go nuclear something will change. But for now, if you buy a device it expects to be on one giant /24 and anything different creates problems. I'm starting to spend way more time than I want maintaining all the various pieces of networking glue that keeps my devices and home automation functioning. It's no longer fun, and I'm tired of fighting it.
I still have an ancient sleep number bed, with no connectivity. It's leaking, and old enough to drink. I'd like to replace it, but still can't bring myself to do it because of articles like this.
I've never felt more like Abe Simpson yelling at a cloud.
> This is what I do today, and honestly I'm about to give up. We lost. Trying to get stuff like airplay / DLNA to work via mDNS is already impossible across subnets, and telling family to switch networks if they want to control X with their phones is just a shit solution. I have to disable 90% of my vehicle's "infotainment" screen to not feel spied upon, and which breaks the app I can use for remote starts, etc.
I guess I never really specified, but I was only referring to "this random IoT/embedded crap" when I said devices.
My main network has all of our computers, phones, tablets, etc. None of it is really restricted or isolated for the reasons you mention.
The main network _also_ has things like the Apple TV. On the balance, it's (1) a device from a reputable vendor that (2) gets regular patches and updates and (3) would be an absolute pain in the dick to isolate.
(The whole reason I own the Apple TV in the first place is because I was never going to hook the Smart TV crap up to the network because I have zero trust that it will be secure or receive useful updates (I'm sure they'll find a way to shove more ads in it...) and it works fine as a TV without it.)
If I were to try and boil this sort of intuitive sense down to a somewhat useful heuristic... if it has a keyboard or has somewhere I can plug one in it's probably going on the main network by default.
My isolated network (well, networks) are for everything else.
There's one for my IP cameras that has no external routing. It only allows communication from Blue Iris to individual cameras and vice-versa. These are all cheap cameras full of security holes and a compromise has a high impact on my privacy (someone literally watching me in my house). Additionally, since most of them are wired this provides some protection against somebody pulling a camera off my wall and connecting a different device to that cable.
Another is for my home automation stuff. I've managed to build it out almost entirely with zwave, but there are still a few things on wifi. This also has no external routing, only allowing communication between Home Assistant and devices. I didn't achieve this by carefully curating firewall rules, but carefully choosing what I purchased. When I needed an air quality monitor, I ended up buying from a less well-known German company at a higher price specifically because "operating with no internet connection or app" was one of their supported use cases. Generally, anything that Home Assistant lists as needing the manufacturer's API for the integration just gets no further consideration.
Not to get too engineering-manager-y, but look at each risk in terms of the likelihood, impact, and effort to mitigate:
- The likelihood of the Apple TV being compromised is pretty low. The impact if it were is maybe moderate, everything within the network is still _secure_ in other ways. The effort to mitigate this through network isolation (as you're saying) is very high. Screw it, main network. We'll mitigate as much as we can ensuring that updates are being installed.
- The likelihood of one of our computers being compromised is moderate. The impact to the network is moderate. The effort to mitigate this through network isolation is, again, very high.
- The likelihood of this $20 Chinese IP camera being chock full of vulnerabilities is 100% (I've found vulnerabilities myself!). The impact is very high (someone watching me in my home). The effort to mitigate is very minimal (totally isolate from the network and greater internet, use my own DVR instead of their broken mobile app and cloud service). It's getting isolated.
- The likelihood of this wifi door lock being insecure is pretty high (though the likelihood of it being compromised by someone with physical access to my house is low). The impact is moderate. The effort to mitigate by buying a zwave lock instead is... pretty near nil. Risk avoided entirely!
As far as effort and risk, this strikes the right balance for me. It may or may not for you. The only advice I'd give is don't let the perfect be the enemy of the good. Don't burn yourself out chasing perfect and fall back to "bad" if "good enough" is an option.
I am not defending them for not keeping their stuff up-to-date, but it is very common practice for embedded systems to be hopelessly outdated. I've done what OP describes with IPMI/BMC systems for $mainboardmanufacturer1 and $mainboardmanufacturer2 (both really big name brands), and their BMC systems were equally outdated. It was almost comical, but really sad at the same time.
Moral of the story is to firewall things off really well, I suppose.
At $oldjob, I designed an upgrade mechanism to do A/B image updates so things were always up to date, or at 2-3 weeks out of date. See [1].
For small embedded systems that do not have enough space/bandwidth, this may not be feasible though.
[1] https://blog.heckel.io/2019/09/18/image-based-upgrades-upgra...