Is this cutting corners on manufacturing/assembly where they're skipping installing a unique set of keys on each device?
> Out of sheer laziness, I connected to the Mysa MQTT server and subscribed to the match-everything wildcard topic, #. I was hoping I’d see messages from a few more MQTT topics, giving me more information about my Mysa devices.
> Instead, I started receiving a torrent of messages from every single Internet-connected production Mysa device in the whole world.
The devices had unique IDs, but they were all connected to one big MQTT pub/sub system that didn't even try to isolate anything.
It's lazy backend development. This happens often in IoT products where they hire some consultant or agency to develop a proof of concept, the agency makes a prototype without any security considerations, and then they call it done because it looks like it works. To an uninformed tester who only looks at the app it appears secure because they had to type in their password.
The vulnerability is in having a backend cloud structure.
(There are plenty of ways to provide remote access without that, and no other feature warrants it.)
If it's not quite as consumer-friendly as you want it to be, contribute your engineering hours to the Home Assistant product until it is.
Bonus points for giving it 25-250W audio output to power speakers and letting you pair them together to play music in sync across different rooms of your house connected to speakers of your choice.
The number of people who 1) really want local-only control and 2) can deal with Home Assistant and Tailscale but 3) don't actually have the skill set to put together a Raspberry Pi or other small Linux box and set up HA and TS themselves is tiny.
The cloud systems are insecure and invasive, but it's really hard to get Normal People to understand why it's a problem. "So someone can tell if I'm not home; so what? I live in a gated community, they can't just drive in at night and burgle the house." They're not entirely wrong about that; it is unlikely. The hard push for subscription services by these companies has turned out to be the best way to push people into locally hosted alternatives, because they don't want to pay for another service, but the usual approach is just to do without the service when they realize that the "smart" functions are not that useful. Most people don't have the free time, knowledge, or inclination to set up and maintain Home Assistant. They can appreciate it when they see it done well, but they aren't going to pay for a professional installation and maintenance and they aren't able to do it themselves.
In the case of HVAC systems the danger is a collective one not individual. Sure if someone really wanted to they could watch you and wait until you're not home then turn your heat off and freeze your pipes. But they're not gonna do that, probably. Instead the kind of havoc they'll wreak with this access is to wait until some off-peak time and instantaneously fire up all the AC units and shut them down simultaneously, repeatedly, causing a huge demand spike. If supply doesn't ramp up fast enough then frequency will drop and then the grid will start trimming off branches to self-correct (or something like that? I'm not a power grid expert someone correct me) and you basically have chaos.
So you don't need to get individuals to care about it, and there's some argument to be made that they shouldn't, or at least shouldn't have to. But the power company damn well should, and governments damn well should.
https://snowpatch.org/posts/i-can-completely-control-your-sm...
EDIT: the major issue here is the people who are affected by a vulnerability like that aren't the people who purchased and installed the attack vector. They're everyone on the same power distribution network. So it's not like "oh well, they did a dumb thing and trusted a tech company" it's far bigger than that.
And then the thermostat uses those keys to mutually authenticate itself with the MQTT server. It actually makes it quite tedious (not impossible :-D) to 2-way-MITM the device's connection to the server.
It's just that, as @Aurornis wrote, the MQTT server itself did not have any checks to prevent sending and receiving messages to other owners' thermostats. ¯\_(ツ)_/¯
[ I've actually discovered a whole lot more details about the Mysa thermostats than what I published. Many of them can be used to subvert and reconfigure the devices in interesting ways, but only with a witting/willing device owner who has local access. So I don't feel any obligation to disclose them, although I might eventually get around to building a de-cloud-ifying tool using them: https://github.com/dlenski/mysotherm/blob/main/README.md#fut... ]
[1] https://community.st.com/t5/stm32-mcus/how-to-obtain-and-use...
You can hash this unique MAC address, together with other data that may be shared with the other devices of the same kind, to generate unique keys or other kinds of credentials.
Knowledge or not, this..
> It's not impossible, it's just extra work that usually goes unrewarded.
.. is just not an acceptable way for business to think and operate i 2026, especially not when it comes to internet connected video enabled devices
While true that in $current_year it would be nice if things were more secure, the sad truth is that most people don't care.
No, it doesn't. Unless it's supposed to spy on you (or "harvest training data") there's no reason it needs to phone home at all (c.f. Roombas).
Anyway regardless of wifi, bluetooth, or something else there will be a setup process.
For that matter, I'm unclear why there needs to be a setup process. I understand that this may be key to the vendor's business model, but that's their need, not something the products needs, and certainly nothing I need.
Once you introduce control via phone the most straightforward approach is either wifi or bluetooth which requires a setup process.
That sounds like profit motivated negligence, and it sounds like a standard justification for why Europe is going to hold companies liable.