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.
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.
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.