
Raspberry Pi Z-Wave kit exposes private key - bootstrapbill
http://blog.simplicify.me/bad-zway.html
======
trengrj
I loaded the script
"[http://find.zwave.me/zbw_new_user"](http://find.zwave.me/zbw_new_user") a
couple times. You will notice it generates a new private key each time. This
is for the local service to connect to the z-wave server without password
credentials.

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.

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

~~~
ambrop7
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..)

~~~
lcampbell
> it is not by default vulnerable to malicious CAs

Well, in this particular case, they're using

    
    
      ssh [..] -o 'StrictHostKeyChecking no' -o 'UserKnownHostsFile /dev/null' [..]
    

So the remote authentication bits are already out the window. It would be
nicer if they included the host's public key in the installation package
rather than eschewing it completely.

~~~
ambrop7
Indeed, they're just using it wrong.

------
yzzxy
Title should maybe be amended to make it clearer that this is not a Raspberry
Pi Foundation product.

~~~
NoCowLevel
Suggestion: 'Z-wave's Raspberry Pi kit exposes private key'

~~~
timthorn
It's not made by Z-Wave, either - they're Z-Wave.me.

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

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

------
2bluesc
For more security fun: `wget <non-http url> | sudo bash`

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

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

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

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

