The vulnerability was in their backend cloud structure. The backend wasn't restricting access to only devices associated with your account.
> 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.
Not sure why this is being downvoted, it's a pervasive flaw across all these IoT products. See my description elsewhere here about how Haier "smart" controls work. It's completely insane, and pointless. For systems that can't fail--I include heating systems in the winter--this kind of "move fast and break shit" way of doing it is malpractice. The last thing in the entire world I want my furnace controls doing is an automatic OTA firmware update. Ever.
Sell an additional $200 box containing a Raspberry Pi with Home Assistant on it and a cheap capacitive touchscreen and pre-configure it with Tailscale. Would be reasonably consumer-friendly. Give it a fancy name and start slapping "{$HOME_ASSISTANT} Compatible" branding logos on partners boxes.
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.
> The cloud systems are insecure and invasive, but it's really hard to get Normal People to understand why it's a problem.
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.
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.
Agreed, and with open, auditable design it's far more trustworthy. So you can satisfy both the paranoid tech nerds (guilty as charged) and the folks who just want to get it running with the least amount of effort are safer--whether they know it or not--because it's audited.
I'm hoping that things like Matter and Thread will help with this, but in the meantime, I have no problem with "optional remote-access service that you don't have to use and have to explicitly enable, or you can use it entirely locally".
Quite ironically, they do install a unique TLS cert and key on each thermostat, although it's done on first-wifi-connection of each thermostat, rather than pre-installed at the factory.
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... ]
I think it's about being a configuration management nightmare. If every device has a unique password, you need the decoder ring for serial number to password. However, not all processors have unique IDs. So you either need to find a way to reliably serialize each board during manufacturing and hope it stays (like a sticker/laser/printer/etc) or add a serial number chip which is cost and complexity. It's not impossible, it's just extra work that usually goes unrewarded.
I'm a long way from embedded development. But I was under the impression a lot of microcontrollers these days have some ID capability built in, even some relatively low-end ones. This strikes me more as laziness than anything.
This is true, for example many stm32 series have a 96 bit unique id which is derived from the lot number, wafer id and position [1]. Even the low cost stm32g0b1 series I am using has them, but they are missing from some older series.
Moreover, on any device that is connected to Internet you already have a unique MAC address on its Ethernet or WiFi interface.
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.
Surprisingly it's not everywhere. I'm very in embedded development and cannot count the amount of time I look for "unique" "id" etc in a reference manual and come up short. It's certainly more common than not, but you often have to design systems for the lowest common denominator.
It is indeed. And that sucks but that's what it is. Product design is about calculated risks and trades. It's a good thing regulators are here to help because companies won't do it on their own and the general public doesn't care enough.
I have not knowledge of this kind of software dev/hw production, so can you please explain why the units cant just be born with a default pass and then have the setup process (which is always there) Force the owner to set a new password?
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
I'll answer your question with a question: how often do you see people complaining about needing setup processes vs the old way of just plug and play? There's no perfect answer that placates all sides. Things can certainly be better, but when those people win and you no longer need to have a setup process, then what?
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.
I agree that yes most just want PnP and basically don’t care about security. But it seemed on the posts above that there was an engineering complexity,
and a robot vaccum needs local WiFi, so there will be a setup flow. Whats preventing a password selection
just be part of that?
Well it needs to talk to either a web frontend (internet) or app (bluetooth or wifi). If you're worried about it spying, well, the app could always relay data for it.
Anyway regardless of wifi, bluetooth, or something else there will be a setup process.
You're begging the question. Why does it need to talk to a web front end or app? Why does any appliance need this? (I know they all claim to need it, but it isn't at all clear why this (supposedly) needs to be the case.)
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.
I'm not begging the question although I am implicitly assuming that the vast majority of consumers will want to control a robot vacuum via their phone. I suppose including a touchscreen on the unit itself is not entirely unreasonable but I expect that would be an uphill battle for various disparate reasons (expense, durability, and ease of use at minimum).
Once you introduce control via phone the most straightforward approach is either wifi or bluetooth which requires a setup process.
