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|1 year ago
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|1 year ago