20 ms·

Reverse-Engineering Google Nest Devices

115 points by jelveh 11y ago

pilif 11y ago
> with email and plaintext password It's totally reasonable to transmit a password in clear if it's being transmitted inside of an SSL tunnel (which it is in this case). Most if not all techniques that would allow for not transmitting the password in a server-decryptable fashion would require the password or a password equivalent to be stored in clear on the server. In case of a breach, that would be devastating.
- nitrogen 11y ago
  SRP does not require the server to store either a password or a password equivalent. https://en.m.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...
- jimktrains2 11y ago
  > Most if not all techniques that would allow for not transmitting the password in a server-decryptable fashion would require the password or a password equivalent to be stored in clear on the server. That's not true at all! SRP[1][2] allows the server to not have the plaintext password ever, even during account creation. Kerberos' KDC doesn't know the plain-text password either[3]. Even HTTP Digest didn't require the password to be stored in plain text [4]. [Edit: though if you leaked HA1 that effectively becomes the credential] Moreover, client TLS certificates would also fit the bill, as the client key is never transmitted. Don't spread FUD if you aren't sure. If you don't know, don't say anything or say you don't know. [1] http://srp.stanford.edu/ http://srp.stanford.edu/ [2] https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... [3] http://security.stackexchange.com/questions/15849/does-the-kerberos-kdc-know-the-users-plaintext-passwords http://security.stackexchange.com/questions/15849/does-the-k... [4] https://en.wikipedia.org/wiki/Digest_access_authentication https://en.wikipedia.org/wiki/Digest_access_authentication
  - mortehu 11y ago
    > Even HTTP Digest didn't require the password to be stored in plain text As I understand it, it would still be required to store something that, if leaked, would allow anyone to create valid authentication responses? "HA1" effectively becomes the password, in that leaking it is as bad as leaking the password.
    - jimktrains2 11y ago
      Right, edited.
  - Retric 11y ago
    If password X is hashed to Y, and you store Y that seems ok. But if you directly check if the client transmits Y then Y is just the new password. At a minimum you should be hashing whatever the client sends and comparing that with the hashed password. PS: Not that most developers should do this by hand.
    - jimktrains2 11y ago
      I don't understand your point. Even if the client sends HASH(password), that effectively becomes the credential. That's where HTTP Digest is less successful (as was pointed out by a sibling and I went D'oh for not remembering). > At a minimum you should be hashing whatever the client sends and storing that. That's a very narrow view of how to authenticate. SRP and client certs certainly don't work that way.
      - Retric 11y ago
        Yes, there are many many more secure schemes out there. By minimum I meant minimum. The point was what the client sends should not be what's in the database or easily reversible from what's in the database. I guess the larger point was you can't trust clients in any way shape or form.
      - gohrt 11y ago
        Salt. In SSL/TLS, the data is transmitted using a one-time pad of some kind, so that intercepting a transmitted token gives you nothing that you can use to authenticate in a future connection (but you might be able to hijack the connection you intercepted, if you spoofed the server into thinking you are the intended client) https://en.wikipedia.org/wiki/Forward_secrecy https://en.wikipedia.org/wiki/Forward_secrecy
supergeek133 11y ago
> you cannot operate the camera or switch your thermostat’s settings without Internet connection This should say *remotely. I know it does in the paragraph before, but sometimes people only read bullets. So is the complaint here I can't find out what data the device is sending back to Nest in whole? And contrary to the post, their Public API is pretty extensive. Seems to me this is just another person with a concern around no local control/data retrieval. There is at least one other thermostat that has that.
- eitally 11y ago
  Well, you can't operate the camera without an internet connection. The only thing you can do is unplug it & plug it back in. It's really irritating to use a Nest thermostat with no connection, either, since you can't set or control your heating/cooling schedule.
  - supergeek133 11y ago
    The camera is one thing... but from their perspective I could understand why they don't want it working locally. As far as the thermostat, people don't edit their schedules that often really. Plus at least with the v3 you can do it on the thermostat. I don't know about the others, I assume not based on the comments. Plus for others (Honeywell for instance) you can do it locally as well as remotely. That being said, scheduling interfaces are SUPER hard to build where people understand them and it does what they want.
    - mikestew 11y ago
      Plus at least with the v3 you can do it on the thermostat. I don't know about the others, I assume not based on the comments. I don't know if it's always been this way, but my V1 Nest let's me fiddle with the schedule on the thermostat. Kind of a pain with a rotating ring as your input device, but it can be done. (Assuming a firmware update hasn't broken this feature; haven't used the feature in well over a year.)
kuschku 11y ago
> […] creating a walled garden around the user’s own data is a shady move. All of my private data should be easibly accessible to me though open API without any gimmicks. In its press release Nest promised introducing a public API[,] however [it] seems limited in many ways compared to the internal API used by Nest mobile app - and to add insult to injury - many of its features require an active Nest subscription. This is exactly one reason why using "Cloud" services for long-living things, like Hardware, is a great risk. When Google shuts down Google Reader, we can all migrate to an alternative easily. When Google shuts down Nest, people are left with non-working thermostats, and have to spend money and rebuild their systems to continue on. Even worse, if just the internet goes down – not that rare in areas in the US only served by one ISP which doesn’t have to fear competition – one is even left without heating. The reaction of the people on the recent case where Nest went down itself, and people were left without heating, fits well as context for the following excerpt from "The Sorcerers Apprentice" (1797, Johann Wolfgang von Goethe): Herr, die Not ist groß! Sir, my need is sore. Die ich rief, die Geister Spirits that I've called werd ich nun nicht los. My commands ignore.
- jedberg 11y ago
  > When Google shuts down Nest, people are left with non-working thermostats, and have to spend money and rebuild their systems to continue on. No, they are left with a normal programmable thermostat with a nicer interface than most. > Even worse, if just the internet goes down – not that rare in areas in the US only served by one ISP which doesn’t have to fear competition – one is even left without heating. This is not true. The Nest operates perfectly fine without internet. > The reaction of the people on the recent case where Nest went down itself, and people were left without heating That's not exactly what happened. What happened was there was a bug in the software that had an issue when their server became unavailable. But this could happen with any device that is controlled by software. And even if they had a totally open and accessible API right on the device, this problem still would have happened. I don't like the fact that they lock up the data, but we should probably try to stomp out the myth that the device is totally useless without their servers.
  - 11y ago
Animats 11y ago
Then there are the Nest cameras, reporting everything you do to Google. "The telescreen received and transmitted simultaneously. Any sound that Winston made, above the level of a very low whisper, would be picked up by it; moreover, so long as he remained within the field of vision which the metal plate commanded, he could be seen as well as heard. There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. but at any rate they could plug in your wire whenever they wanted to. You have to live - did live, from habit that became instinct - in the assumption that every sound you made was overheard, and, except in darkness, every movement scrutinized." - "1984", Orwell "Video and audio signals and data: When you enable the recording or streaming features of your Nest Cam, we may record and process video and/or audio recordings from the device, subject to your configuration and settings. This may include capturing and emailing to you portions of this data as part of a notification or analyzing the data to identify motion or other events. We may process information from your Nest Cam so that we can send you alerts when something happens. In addition, if you have the recording features enabled, we will capture, process and retain video and audio data recordings from your device for the duration of your recording subscription period (for example, 10 or 30 days) and you will be able to access those recordings using the Services during that time." - NestCam privacy policy, Google
- dguaraglia 11y ago
  I'm curious. How else would you implement a cloud-based recording service with image recognition? (EDIT: full disclosure, I work for Nest through the Dropcam acquisition)
  - afandian 11y ago
    That's kind of like saying "how would you make a car without wheels?". It could be that inherent in the idea of making object X are privacy concerns. The fact that the privacy concerns are intrinsic to the object just means that you have to call the whole object X into question when discussing them. Your question seems to suggest a sentiment like "there isn't any other way to do this, can you think of one?" but there is, and it's not to do it at all. (I'm not taking a position on the Nest device, but this comment just seemed a little like a cognitive bias similar to anchoring)
yalogin 11y ago
I am surprised the Nest devices allow themselves to be man-in-middle'ed like this. Why are Nest devices accepting a random (valid) certificate? One would think they will only accept a valid Google certificate, signed by the Google root certificate. Am I missing something? The article does not mention about any software tampering on the device itself.
- supergeek133 11y ago
  I've also done something similar with Wireshark and a hotspot off my laptop to find out what API calls an Echo is sending to Amazon. I believe I could see the endpoints, but not the content.
- kapitalx 11y ago
  This is a man in the middle on the mobile app, which relies on the certificates on the phone. You just need to add your phony certificate to the OS's trust store. It's an attempt to find any private APIs that the APP is using, rather than reverse engineering the protocol between Alphabet and the nest device.
andrewpe 11y ago
The nest thermostat seems to use firebase.com API from my research.

115 points by jelveh 11y ago

pilif 11y ago

> with email and plaintext password It's totally reasonable to transmit a password in clear if it's being transmitted inside of an SSL tunnel (which it is in this case). Most if not all techniques that would allow for not transmitting the password in a server-decryptable fashion would require the password or a password equivalent to be stored in clear on the server. In case of a breach, that would be devastating.

nitrogen 11y ago
SRP does not require the server to store either a password or a password equivalent. https://en.m.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...
jimktrains2 11y ago
> Most if not all techniques that would allow for not transmitting the password in a server-decryptable fashion would require the password or a password equivalent to be stored in clear on the server. That's not true at all! SRP[1][2] allows the server to not have the plaintext password ever, even during account creation. Kerberos' KDC doesn't know the plain-text password either[3]. Even HTTP Digest didn't require the password to be stored in plain text [4]. [Edit: though if you leaked HA1 that effectively becomes the credential] Moreover, client TLS certificates would also fit the bill, as the client key is never transmitted. Don't spread FUD if you aren't sure. If you don't know, don't say anything or say you don't know. [1] http://srp.stanford.edu/ http://srp.stanford.edu/ [2] https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... [3] http://security.stackexchange.com/questions/15849/does-the-kerberos-kdc-know-the-users-plaintext-passwords http://security.stackexchange.com/questions/15849/does-the-k... [4] https://en.wikipedia.org/wiki/Digest_access_authentication https://en.wikipedia.org/wiki/Digest_access_authentication
- mortehu 11y ago
  > Even HTTP Digest didn't require the password to be stored in plain text As I understand it, it would still be required to store something that, if leaked, would allow anyone to create valid authentication responses? "HA1" effectively becomes the password, in that leaking it is as bad as leaking the password.
  - jimktrains2 11y ago
    Right, edited.
- Retric 11y ago
  If password X is hashed to Y, and you store Y that seems ok. But if you directly check if the client transmits Y then Y is just the new password. At a minimum you should be hashing whatever the client sends and comparing that with the hashed password. PS: Not that most developers should do this by hand.
  - jimktrains2 11y ago
    I don't understand your point. Even if the client sends HASH(password), that effectively becomes the credential. That's where HTTP Digest is less successful (as was pointed out by a sibling and I went D'oh for not remembering). > At a minimum you should be hashing whatever the client sends and storing that. That's a very narrow view of how to authenticate. SRP and client certs certainly don't work that way.
    - Retric 11y ago
      Yes, there are many many more secure schemes out there. By minimum I meant minimum. The point was what the client sends should not be what's in the database or easily reversible from what's in the database. I guess the larger point was you can't trust clients in any way shape or form.
    - gohrt 11y ago
      Salt. In SSL/TLS, the data is transmitted using a one-time pad of some kind, so that intercepting a transmitted token gives you nothing that you can use to authenticate in a future connection (but you might be able to hijack the connection you intercepted, if you spoofed the server into thinking you are the intended client) https://en.wikipedia.org/wiki/Forward_secrecy https://en.wikipedia.org/wiki/Forward_secrecy

supergeek133 11y ago

> you cannot operate the camera or switch your thermostat’s settings without Internet connection This should say *remotely. I know it does in the paragraph before, but sometimes people only read bullets. So is the complaint here I can't find out what data the device is sending back to Nest in whole? And contrary to the post, their Public API is pretty extensive. Seems to me this is just another person with a concern around no local control/data retrieval. There is at least one other thermostat that has that.

eitally 11y ago
Well, you can't operate the camera without an internet connection. The only thing you can do is unplug it & plug it back in. It's really irritating to use a Nest thermostat with no connection, either, since you can't set or control your heating/cooling schedule.
- supergeek133 11y ago
  The camera is one thing... but from their perspective I could understand why they don't want it working locally. As far as the thermostat, people don't edit their schedules that often really. Plus at least with the v3 you can do it on the thermostat. I don't know about the others, I assume not based on the comments. Plus for others (Honeywell for instance) you can do it locally as well as remotely. That being said, scheduling interfaces are SUPER hard to build where people understand them and it does what they want.
  - mikestew 11y ago
    Plus at least with the v3 you can do it on the thermostat. I don't know about the others, I assume not based on the comments. I don't know if it's always been this way, but my V1 Nest let's me fiddle with the schedule on the thermostat. Kind of a pain with a rotating ring as your input device, but it can be done. (Assuming a firmware update hasn't broken this feature; haven't used the feature in well over a year.)

kuschku 11y ago

> […] creating a walled garden around the user’s own data is a shady move. All of my private data should be easibly accessible to me though open API without any gimmicks. In its press release Nest promised introducing a public API[,] however [it] seems limited in many ways compared to the internal API used by Nest mobile app - and to add insult to injury - many of its features require an active Nest subscription. This is exactly one reason why using "Cloud" services for long-living things, like Hardware, is a great risk. When Google shuts down Google Reader, we can all migrate to an alternative easily. When Google shuts down Nest, people are left with non-working thermostats, and have to spend money and rebuild their systems to continue on. Even worse, if just the internet goes down – not that rare in areas in the US only served by one ISP which doesn’t have to fear competition – one is even left without heating. The reaction of the people on the recent case where Nest went down itself, and people were left without heating, fits well as context for the following excerpt from "The Sorcerers Apprentice" (1797, Johann Wolfgang von Goethe): Herr, die Not ist groß! Sir, my need is sore. Die ich rief, die Geister Spirits that I've called werd ich nun nicht los. My commands ignore.

jedberg 11y ago
> When Google shuts down Nest, people are left with non-working thermostats, and have to spend money and rebuild their systems to continue on. No, they are left with a normal programmable thermostat with a nicer interface than most. > Even worse, if just the internet goes down – not that rare in areas in the US only served by one ISP which doesn’t have to fear competition – one is even left without heating. This is not true. The Nest operates perfectly fine without internet. > The reaction of the people on the recent case where Nest went down itself, and people were left without heating That's not exactly what happened. What happened was there was a bug in the software that had an issue when their server became unavailable. But this could happen with any device that is controlled by software. And even if they had a totally open and accessible API right on the device, this problem still would have happened. I don't like the fact that they lock up the data, but we should probably try to stomp out the myth that the device is totally useless without their servers.
- 11y ago

Animats 11y ago

Then there are the Nest cameras, reporting everything you do to Google. "The telescreen received and transmitted simultaneously. Any sound that Winston made, above the level of a very low whisper, would be picked up by it; moreover, so long as he remained within the field of vision which the metal plate commanded, he could be seen as well as heard. There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. but at any rate they could plug in your wire whenever they wanted to. You have to live - did live, from habit that became instinct - in the assumption that every sound you made was overheard, and, except in darkness, every movement scrutinized." - "1984", Orwell "Video and audio signals and data: When you enable the recording or streaming features of your Nest Cam, we may record and process video and/or audio recordings from the device, subject to your configuration and settings. This may include capturing and emailing to you portions of this data as part of a notification or analyzing the data to identify motion or other events. We may process information from your Nest Cam so that we can send you alerts when something happens. In addition, if you have the recording features enabled, we will capture, process and retain video and audio data recordings from your device for the duration of your recording subscription period (for example, 10 or 30 days) and you will be able to access those recordings using the Services during that time." - NestCam privacy policy, Google

dguaraglia 11y ago
I'm curious. How else would you implement a cloud-based recording service with image recognition? (EDIT: full disclosure, I work for Nest through the Dropcam acquisition)
- afandian 11y ago
  That's kind of like saying "how would you make a car without wheels?". It could be that inherent in the idea of making object X are privacy concerns. The fact that the privacy concerns are intrinsic to the object just means that you have to call the whole object X into question when discussing them. Your question seems to suggest a sentiment like "there isn't any other way to do this, can you think of one?" but there is, and it's not to do it at all. (I'm not taking a position on the Nest device, but this comment just seemed a little like a cognitive bias similar to anchoring)

yalogin 11y ago

I am surprised the Nest devices allow themselves to be man-in-middle'ed like this. Why are Nest devices accepting a random (valid) certificate? One would think they will only accept a valid Google certificate, signed by the Google root certificate. Am I missing something? The article does not mention about any software tampering on the device itself.

supergeek133 11y ago
I've also done something similar with Wireshark and a hotspot off my laptop to find out what API calls an Echo is sending to Amazon. I believe I could see the endpoints, but not the content.
kapitalx 11y ago
This is a man in the middle on the mobile app, which relies on the certificates on the phone. You just need to add your phony certificate to the OS's trust store. It's an attempt to find any private APIs that the APP is using, rather than reverse engineering the protocol between Alphabet and the nest device.

andrewpe 11y ago

The nest thermostat seems to use firebase.com API from my research.