Reclaim Your Data: Freeing a Wi-Fi Sensor from the Cloud(embeddedartistry.com)
embeddedartistry.com
Reclaim Your Data: Freeing a Wi-Fi Sensor from the Cloud
https://embeddedartistry.com/blog/2024/11/04/reclaim-your-data-freeing-a-wi-fi-sensor-from-the-cloud/
17 comments
It is funny, but it's also the defacto-standard.
I avoid as much as possible, devices with cloud connections, but those which I somehow end up with anyway that do have such services, I've found almost none of them do any sort of certificate validation.
Load up any certificate you like on your MiTM proxy and go to town.
Sadly, despite embedded hardware being much more capable, some of them having hardware secure-elements and cryptographic extensions, people making these devices either don't have the expertise or just don't care.
Once upon a time I dreamt of creating IoT devices with security, openness and longevity in mind.
I avoid as much as possible, devices with cloud connections, but those which I somehow end up with anyway that do have such services, I've found almost none of them do any sort of certificate validation.
Load up any certificate you like on your MiTM proxy and go to town.
Sadly, despite embedded hardware being much more capable, some of them having hardware secure-elements and cryptographic extensions, people making these devices either don't have the expertise or just don't care.
Once upon a time I dreamt of creating IoT devices with security, openness and longevity in mind.
We're trying to hit those three checkboxes with the environmental monitor/data logger we're shipping in a few months. Certificate to talk to our server, but you can also just point it at any MQTT broker.
I think that they know that the maintenance of the certificate on their server could be a big point of failure, maybe out of their control, so they disable any validation on the client.
A self renewing free certificate (eg: Letsencrypt) still requires some maintenance. A non free certificate also costs money. It's probably a no-no for many of those manufacturers or the company that give them the servers. Razor thin margins, know how, dedicated staff, etc.
A self renewing free certificate (eg: Letsencrypt) still requires some maintenance. A non free certificate also costs money. It's probably a no-no for many of those manufacturers or the company that give them the servers. Razor thin margins, know how, dedicated staff, etc.
> I think that they know that the maintenance of the certificate on their server could be a big point of failure
If you're building products that talk only to your APIs, you issue your own CA, at the very, very minimum you can put a fingerprint in the end-device to verify it, that can be updated OTA if you need to change the CA/server-cert because you kept the lifetime short.
My experience is that for people outside of the "security" space (I'm in secure-comms, backend), most of them don't have a clue. Some believe the only solution is a cert issued by some "trusted" org like LE, others don't know what pinning or verification is, self-sign is often mis-used as a term for self-CA, and then more generally speaking understanding or TLS is low.
The low-resource nature of microcontrollers has certainly made it difficult to do this well/easily in the past, but with micro-sized TLS libraries, and secure-elements on board many of them now, it can absolutely be done with a little effort and understanding. Coupled with EC/certs keys with smaller memory footprints and hardware-crypto accel the only take home I can find in any of this, is that these people simply don't give a shit about the security of the devices they sell and the data about their end-users they're spitting out.
> Razor thin margins, know how, dedicated staff
Half of this "smart" junk is sold at overinflated prices thanks to the "smart-tax". I have a heater which has an ESP32 and you manage it with an app (which I won't do), they spent a bunch on the app, put an ESP32 and some other electronics in what otherwise could have been a £20 heater instead of a £80 heater, and yet I can MiTM their TLS MQTT connection because they make no effort to protect it, all while this thing is spewing mountains of environmental data up to their cloud every 30 seconds that could quite easily be used to detect presence, amongst other things in my home, even when the thing isn't running.
I'm biased being a dev in the security space, but this sort of careless approach shouldn't be allowed when selling consumer electronics. Fortunately, in the UK, NCSC is making efforts to improve this with security labels[0] and requirements at PoS for consumer electronic devices, and I hope to see it develop further.
[0] https://www.ncsc.gov.uk/files/Security-law-smart-devices-NCS...
If you're building products that talk only to your APIs, you issue your own CA, at the very, very minimum you can put a fingerprint in the end-device to verify it, that can be updated OTA if you need to change the CA/server-cert because you kept the lifetime short.
My experience is that for people outside of the "security" space (I'm in secure-comms, backend), most of them don't have a clue. Some believe the only solution is a cert issued by some "trusted" org like LE, others don't know what pinning or verification is, self-sign is often mis-used as a term for self-CA, and then more generally speaking understanding or TLS is low.
The low-resource nature of microcontrollers has certainly made it difficult to do this well/easily in the past, but with micro-sized TLS libraries, and secure-elements on board many of them now, it can absolutely be done with a little effort and understanding. Coupled with EC/certs keys with smaller memory footprints and hardware-crypto accel the only take home I can find in any of this, is that these people simply don't give a shit about the security of the devices they sell and the data about their end-users they're spitting out.
> Razor thin margins, know how, dedicated staff
Half of this "smart" junk is sold at overinflated prices thanks to the "smart-tax". I have a heater which has an ESP32 and you manage it with an app (which I won't do), they spent a bunch on the app, put an ESP32 and some other electronics in what otherwise could have been a £20 heater instead of a £80 heater, and yet I can MiTM their TLS MQTT connection because they make no effort to protect it, all while this thing is spewing mountains of environmental data up to their cloud every 30 seconds that could quite easily be used to detect presence, amongst other things in my home, even when the thing isn't running.
I'm biased being a dev in the security space, but this sort of careless approach shouldn't be allowed when selling consumer electronics. Fortunately, in the UK, NCSC is making efforts to improve this with security labels[0] and requirements at PoS for consumer electronic devices, and I hope to see it develop further.
[0] https://www.ncsc.gov.uk/files/Security-law-smart-devices-NCS...
I built a small device as a hobby a couple years back using an ESP32. It has 500KB of memory, so storing a full set of CA certs was quite limiting. I forget the size, but looking at Ubuntu package repo, perhaps 100KB. So the constraint was storage size (and therefore hardware cost). I ended up making it local network only and using unencrypted HTTP, which worked for my use case.
> so storing a full set of CA certs was quite limiting
Not sure what your project was doing, but one doesn't generally want to install a full set of CAs. If you're creating a product that'll talk to your APIs you pin your own CA, ensure that the server name matches and verify it, anything else is a failure.
Not sure what your project was doing, but one doesn't generally want to install a full set of CAs. If you're creating a product that'll talk to your APIs you pin your own CA, ensure that the server name matches and verify it, anything else is a failure.
If you use an API endpoint provided by a cloud service provider then you use whichever CA they use, which will be a public CA. But they can switch to another at any time.
IoT devices should come with at least a QR code to the documentation for the API, to be able to write our own backends. In that way they would sell the hardware, not the data of the people that installed those devices at home.
> documentation for the API
I've got bad news for you...
I've got bad news for you...
There's another thing not mentioned.
From the payload it looks like one may be able to spoof other customers' sensors by altering the serial (maybe it's a contiguous number) and replay the request. Heck, it is just one "curl -X PUT -d ..." command away, the info is all in the article
The S in IoT stands for security.
Would it still be possible to get at the data and disable connection to the actual cloud service if the device did check the certificate properly?
It really depends on the type of device, and how much effort was put in.
Many devices have very little effort; It'd easier however for something that might be storing its filesystem on EEPROM or NAND than say, a microcontroller storing it on-module.
My experience is that most devices I've tested, that use something like an ESP32, make little to no effort to validate the CA; even if you don't have the resources to do it cryptographically, you could still do it with a fingerprint check or at the very least a server name validation, but often none of these things are done.
I have a "smart" room heater which requires an app to control, the heater talks to their server using MQTT; pointing the DNS name on my LAN at a local IP, and starting an MQTT server, I can get full control even with a server cert that isn't signed by the CA they use and doesn't even contain the server name of their server; so long as it's an unexpired certificate, it'll happily accept it.
Many devices have very little effort; It'd easier however for something that might be storing its filesystem on EEPROM or NAND than say, a microcontroller storing it on-module.
My experience is that most devices I've tested, that use something like an ESP32, make little to no effort to validate the CA; even if you don't have the resources to do it cryptographically, you could still do it with a fingerprint check or at the very least a server name validation, but often none of these things are done.
I have a "smart" room heater which requires an app to control, the heater talks to their server using MQTT; pointing the DNS name on my LAN at a local IP, and starting an MQTT server, I can get full control even with a server cert that isn't signed by the CA they use and doesn't even contain the server name of their server; so long as it's an unexpired certificate, it'll happily accept it.
Possibly, it wouldn't be anywhere near this trivial though. With proper certificate validation you'd need to dismantle the device and find a way to get into the OS it's running, which can range in difficulty from finding a serial header and entering root/password to log in, up to near impossible if it's one of the few devices that bother to encrypt their storage.
I remember reading somewhere that this is how Valetudo works, like a mitm on a rooted robot vacuum.
[deleted]
One more very good reason for preventing requests to "the cloud".
However, I find it funny that the lack of proper certificate validation (which is a security issue in principle) is a pre-requisite for the "de-cloudification" process.