Raspberry Pi Z-Wave kit exposes private key(blog.simplicify.me)
blog.simplicify.me
Raspberry Pi Z-Wave kit exposes private key
http://blog.simplicify.me/bad-zway.html
6 comments
> "using ssh as a transport mechanism for a web service is one of the worst practices you can use. SSL vulnerabilities are being spotted more frequently than ever now"
Just wanted to note that SSH doesn't really have anything to do with SSL (e.g., it doesn't operate over an SSL transport). Might just be a typo though. Still seems really sketchy that they're using a reverse bind to (presumably) punch through NAT rather than something sane like just using UPnP or simply requiring correct network configuration.
Just wanted to note that SSH doesn't really have anything to do with SSL (e.g., it doesn't operate over an SSL transport). Might just be a typo though. Still seems really sketchy that they're using a reverse bind to (presumably) punch through NAT rather than something sane like just using UPnP or simply requiring correct network configuration.
I see zero problem with using SSH, which happens to be a pretty secure protocol. In fact I would prefer it to HTTPS since it is not by default vulnerable to malicious CAs. Note for example that GitHub allows Git access over SSH.
When the author says that the system "exposes the private key", well, it's by design that the user can see it - since they need to use it to identify themselves to the SSH server. It's not much different from being assigned a password by the server. What could be improved is if it was transferred over HTTPS rather than HTTP, and of course also the install script.
(I only speak about the usage of SSH, it's possible that they still do something insecure..)
When the author says that the system "exposes the private key", well, it's by design that the user can see it - since they need to use it to identify themselves to the SSH server. It's not much different from being assigned a password by the server. What could be improved is if it was transferred over HTTPS rather than HTTP, and of course also the install script.
(I only speak about the usage of SSH, it's possible that they still do something insecure..)
> it is not by default vulnerable to malicious CAs
Well, in this particular case, they're using
Well, in this particular case, they're using
ssh [..] -o 'StrictHostKeyChecking no' -o 'UserKnownHostsFile /dev/null' [..]
Indeed, they're just using it wrong.
> When the author says that the system "exposes the private key"
To be fair the author didn't, the submitter did. I'm not sure if they are the same person.
To be fair the author didn't, the submitter did. I'm not sure if they are the same person.
Oh look, another "security expert" that doesn't know the difference between SSL and SSH
Actually, SSH tunneling is a very secure way of transporting your web requests.
Actually, SSH tunneling is a very secure way of transporting your web requests.
If you check the key. Which that script doesn't.
I agree, that's the problem, the problem is not that it is SSH
Seems like it's not a typo, rather he intended to indicate that he uses ssh due to SSL vulnerabilities precluding use of SSL.
Title should maybe be amended to make it clearer that this is not a Raspberry Pi Foundation product.
Suggestion: 'Z-wave's Raspberry Pi kit exposes private key'
It's not made by Z-Wave, either - they're Z-Wave.me.
> These types of installers aren't inherently bad or evil, they just require a degree of trust between yourself and the source you are downloading from.
* And everyone in between.
* And everyone in between.
The Z-Wave protocol transmits keys in plaintext when setting up secure connections between devices on the mesh network. The rationale is that this should be a one-time event when installing the devices, while also requiring very close proximity to them. Most device don't even have the capability to run securely. It's typically only door and window locks.
For more security fun: `wget <non-http url> | sudo bash`
Not any worse than installing an RPM/deb (which includes an embedded preinstall script) Or the normal "./configure / make / make install" pattern which gives a malicious distributor lots of boilerplate to hide in.
If anything it's probably safer since it's explicit and more likely to be audited.
If anything it's probably safer since it's explicit and more likely to be audited.
If you install deb's normally they are signed, and it does check the signature.
Perhaps the one-liner should be amended to check the hash of the file first, and only run if it matches.
Perhaps the one-liner should be amended to check the hash of the file first, and only run if it matches.
Or just use https with certificate check.
One could argue that signed packages are still harder to check because publicly facing web servers are easier to hack, but you need to get the signature somewhere which is usually included in you distribution you downloaded through an insecure http or ftp connection.
One could argue that signed packages are still harder to check because publicly facing web servers are easier to hack, but you need to get the signature somewhere which is usually included in you distribution you downloaded through an insecure http or ftp connection.
That doesn't protect you from truncation attacks: almost no server out there sends a close_notify before closing the TLS connection, so few tools will throw an error when you receive an incomplete file.
It may be hard to exploit, but executing a script before you have completely downloaded it is simply a really bad idea.
It may be hard to exploit, but executing a script before you have completely downloaded it is simply a really bad idea.
Yes you download the signatures, but you need to trust the key which created the signatures. Distributions come with that key pre-trusted.
This actually seems okay, the script should be loaded over https definitely but this ssh key part is really just giving a password to each device for connection.