5 ms·

Reclaim Your Data: Freeing a Wi-Fi Sensor from the Cloud

46 points by WaitWaitWha 2y ago

pmontra 2y ago
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.
- rrr_oh_man 2y ago
  > documentation for the API I've got bad news for you...
ce4 2y ago
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
- api 2y ago
  The S in IoT stands for security.
frazar0 2y ago
> If the device was validating the server certificate, it wouldn’t make it this far, so that shows that our certificate was accepted. 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.
- alias_neo 2y ago
  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.
  - pmontra 2y ago
    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.
    - alias_neo 2y ago
      > 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-NCSC.pdf https://www.ncsc.gov.uk/files/Security-law-smart-devices-NCS...
shellfishgene 2y ago
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?
- jon-wood 2y ago
  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.
- alias_neo 2y ago
  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.
boomskats 2y ago
I remember reading somewhere that this is how Valetudo works, like a mitm on a rooted robot vacuum.
deleted 2y ago
[deleted]

46 points by WaitWaitWha 2y ago

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.

rrr_oh_man 2y ago
> documentation for the API I've got bad news for you...

ce4 2y ago

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

api 2y ago
The S in IoT stands for security.

frazar0 2y ago

> If the device was validating the server certificate, it wouldn’t make it this far, so that shows that our certificate was accepted. 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.

alias_neo 2y ago
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.
- pmontra 2y ago
  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.
  - alias_neo 2y ago
    > 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-NCSC.pdf https://www.ncsc.gov.uk/files/Security-law-smart-devices-NCS...

shellfishgene 2y ago

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?

jon-wood 2y ago
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.
alias_neo 2y ago
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.

boomskats 2y ago

I remember reading somewhere that this is how Valetudo works, like a mitm on a rooted robot vacuum.

deleted 2y ago

[deleted]