4 ms·

This is a bunch of nonsense, assumption and leaping to conclusions without evidence. "In the second screenshot, we have the public key that’s authorized to acc

by avalys 2y ago

This is a bunch of nonsense, assumption and leaping to conclusions without evidence. "In the second screenshot, we have the public key that’s authorized to access the device. The email address attached to the public key, eng@eightsleep.com, to me suggests the private key is likely accessible to the entire engineering team." He has no evidence for this whatsoever and not really any good reason to assume it either. "In the first image, we see evidence SSH is being exposed remotely, to a far away host, remote-connectivity-api.8slp.net. Typically SSH would only be accessible to the local area network, but the variables in production.json would seem to imply this access was opened up to a remote host." This isn't how SSH works and he doesn't seem to have enough information, or enough knowledge of SSH, to understand what's being done with the "far away" hostname. This article is just clickbait nonsense, which should have been obvious from the title. It is clearly intended to draw traffic to their company website, which is some kind of venture-backed security startup. Based on the fact that the founders seem to have a superficial understanding of technology but a well-developed understanding of hype and bullshit, I am not interested in exploring their business further.

ta1243 2y ago
Are you denying the existence of an authorised ssh key on each of these beds allowing the holder of the key? Are you denying there is a config file pointing to a target called remote-connectivity-api.8slp.net? No there's not enough evidence to prove in a court of law who has access to the private key, or that the config file is enabling a return ssh connection, but it's pretty damning. The only thing that's not newsworthy about this is that large amounts of IOT shit does this.
- duskwuff 2y ago
  > Are you denying there is a config file pointing to a target called remote-connectivity-api.8slp.net? Under the path ".ssh.endpoint", too. It's not like it's just a mystery hostname; it clearly has something to do with SSH. > The only thing that's not newsworthy about this is that large amounts of IOT shit does this. And - just to be clear - that doesn't mean it shouldn't be reported on! Talking about this stuff, and having concrete, specific examples, is good.
  - avalys 2y ago
    "I downloaded the firmware and I found an SSH key and a configuration file that mentions an SSH endpoint; therefore, I know that all of Eight Sleep’s engineers are allowed to remotely SSH into every customer’s bed and run arbitrary code!" Do you not see a problem with this line of reasoning? That's literally what he says in the article, and he presents it as a near-certainty, not the wild leap of unsupported reasoning that it is.
    - ta1243 2y ago
      Is your argument that there may be an internal policy which restricts access to the private key to a subset of engineers?
paldepind2 2y ago
I don't really understand the take here. The post makes it very clear what is concrete evidence, what is speculation based on that, and the reasoning is much better than what you give it credit for. For instance, what would you suggest the "remote-connectivity-api" SSH endpoint URL and the authorized public SSH key is for if not for remotely SSHing into the bed's computer?
- avalys 2y ago
  This is a Linux image that is, somehow, remotely flashed onto the bed. He found the SSH key on the filesystem. 1. He didn't even bother to check and see if the bed is running an SSH server - ten seconds with nmap could have told him this! 2. Essentially every one of these beds would be behind a NAT and thus the SSH server which he didn't even bother to look for would not be accessible to the internet or to the nefarious engineers he imagines have access to the key - he ignores this fact. 3. The fact that the firmware includes the URL of a specific external endpoint, suggests that the bed connects _to_ that endpoint, not that this is somehow used to screen incoming requests by reverse DNS lookup or anything like that. The architecture he is supposing exists (all remote access requests must come from a host whose reverse DNS resolves to this host?) makes no sense. 4. The fact that the public key exists on the filesystem means nothing if no SSH server is running, or accessible. It might be used, for instance, as part of the manufacturing test process or a maintenance procedure, and then disabled. The SSH public key on the filesystem isn't necessarily related to the JSON config file for their own application which he found! 5. SSH keys don't have "email addresses" associated with them, they have a plaintext field which is used merely for identification purposes, and this is commonly used for the _user account_ that created the key. But it's not an email address and even if it were, it doesn't mean that that email address, much less every engineer at the company, somehow has access to the key! The sloppiness and level of jumping to conclusions here, for a supposed security company, is ridiculous.
  - paldepind2 2y ago
    Thanks for expanding! I think your original comment would have made more sense with some of these arguments included. Point 1 is especially prudent. It really would have been trivial to see if the bed is actually running an SSH server on some port.
perching_aix 2y ago
> He has no evidence for this whatsoever and not really any good reason to assume it either. I'm not sure what kind of evidence or reason you're looking for, I think their assumption is pretty sensible. > This isn't how SSH works Maybe I'm just naive, but the wording of it to me seems nontechnical enough that I think the author is skipping over things on purpose. For example, how exactly that "far way" host he thinks is involved. I'd personally imagine it's a reverse shell type deal going on, although why SSH needed to be involved in that I'm not sure. Could be just a hacky implementation. But it's really not that far removed from sensibility, vendors popping reverse shells without authorization really wouldn't be new. > It is clearly intended to draw traffic to their company website, which is some kind of venture-backed security startup. Didn't even notice that. Can't imagine too many other people did either. So maybe not so clearly?
- avalys 2y ago
  Please see my reply to another person in this same thread. He didn't even verify that the bed is running an SSH server in the first place!
  - perching_aix 2y ago
    I saw it. It's not necessary if the process that maintains the reverse connection can just start it as needed. That said, some actual investigation of that supposed binary would have been a strong support for this whole thing, and indeed an evidence for this theory, so I will give you that.
    - avalys 2y ago
      If the bed requires going through some kind of production endpoint interaction in order to set up the remote connection (as is most likely the case), then his claim that any engineer can connect to any bed is simply false, and this is no more of a security hole than the idea of having a cloud-connected bed which is updated OTA in the first place.
      - 2y ago

by avalys 2y ago

ta1243 2y ago

Are you denying the existence of an authorised ssh key on each of these beds allowing the holder of the key? Are you denying there is a config file pointing to a target called remote-connectivity-api.8slp.net? No there's not enough evidence to prove in a court of law who has access to the private key, or that the config file is enabling a return ssh connection, but it's pretty damning. The only thing that's not newsworthy about this is that large amounts of IOT shit does this.

duskwuff 2y ago
> Are you denying there is a config file pointing to a target called remote-connectivity-api.8slp.net? Under the path ".ssh.endpoint", too. It's not like it's just a mystery hostname; it clearly has something to do with SSH. > The only thing that's not newsworthy about this is that large amounts of IOT shit does this. And - just to be clear - that doesn't mean it shouldn't be reported on! Talking about this stuff, and having concrete, specific examples, is good.
- avalys 2y ago
  "I downloaded the firmware and I found an SSH key and a configuration file that mentions an SSH endpoint; therefore, I know that all of Eight Sleep’s engineers are allowed to remotely SSH into every customer’s bed and run arbitrary code!" Do you not see a problem with this line of reasoning? That's literally what he says in the article, and he presents it as a near-certainty, not the wild leap of unsupported reasoning that it is.
  - ta1243 2y ago
    Is your argument that there may be an internal policy which restricts access to the private key to a subset of engineers?

paldepind2 2y ago

I don't really understand the take here. The post makes it very clear what is concrete evidence, what is speculation based on that, and the reasoning is much better than what you give it credit for. For instance, what would you suggest the "remote-connectivity-api" SSH endpoint URL and the authorized public SSH key is for if not for remotely SSHing into the bed's computer?

avalys 2y ago
This is a Linux image that is, somehow, remotely flashed onto the bed. He found the SSH key on the filesystem. 1. He didn't even bother to check and see if the bed is running an SSH server - ten seconds with nmap could have told him this! 2. Essentially every one of these beds would be behind a NAT and thus the SSH server which he didn't even bother to look for would not be accessible to the internet or to the nefarious engineers he imagines have access to the key - he ignores this fact. 3. The fact that the firmware includes the URL of a specific external endpoint, suggests that the bed connects _to_ that endpoint, not that this is somehow used to screen incoming requests by reverse DNS lookup or anything like that. The architecture he is supposing exists (all remote access requests must come from a host whose reverse DNS resolves to this host?) makes no sense. 4. The fact that the public key exists on the filesystem means nothing if no SSH server is running, or accessible. It might be used, for instance, as part of the manufacturing test process or a maintenance procedure, and then disabled. The SSH public key on the filesystem isn't necessarily related to the JSON config file for their own application which he found! 5. SSH keys don't have "email addresses" associated with them, they have a plaintext field which is used merely for identification purposes, and this is commonly used for the _user account_ that created the key. But it's not an email address and even if it were, it doesn't mean that that email address, much less every engineer at the company, somehow has access to the key! The sloppiness and level of jumping to conclusions here, for a supposed security company, is ridiculous.
- paldepind2 2y ago
  Thanks for expanding! I think your original comment would have made more sense with some of these arguments included. Point 1 is especially prudent. It really would have been trivial to see if the bed is actually running an SSH server on some port.

perching_aix 2y ago

> He has no evidence for this whatsoever and not really any good reason to assume it either. I'm not sure what kind of evidence or reason you're looking for, I think their assumption is pretty sensible. > This isn't how SSH works Maybe I'm just naive, but the wording of it to me seems nontechnical enough that I think the author is skipping over things on purpose. For example, how exactly that "far way" host he thinks is involved. I'd personally imagine it's a reverse shell type deal going on, although why SSH needed to be involved in that I'm not sure. Could be just a hacky implementation. But it's really not that far removed from sensibility, vendors popping reverse shells without authorization really wouldn't be new. > It is clearly intended to draw traffic to their company website, which is some kind of venture-backed security startup. Didn't even notice that. Can't imagine too many other people did either. So maybe not so clearly?

avalys 2y ago
Please see my reply to another person in this same thread. He didn't even verify that the bed is running an SSH server in the first place!
- perching_aix 2y ago
  I saw it. It's not necessary if the process that maintains the reverse connection can just start it as needed. That said, some actual investigation of that supposed binary would have been a strong support for this whole thing, and indeed an evidence for this theory, so I will give you that.
  - avalys 2y ago
    If the bed requires going through some kind of production endpoint interaction in order to set up the remote connection (as is most likely the case), then his claim that any engineer can connect to any bed is simply false, and this is no more of a security hole than the idea of having a cloud-connected bed which is updated OTA in the first place.
    - 2y ago