LittleBlackBox: is Vera2 vulnerable?

[futzle]

http://www.devttys0.com/2010/12/breaking-ssl-on-embedded-devices/

I'm curious... do all Veras have the same SSL keypairs?  Someone else run the same commands below and we'll see...

Code: [Select]

# cat /etc/cmh/version         
1.1.1047
# md5sum /etc/cmh-ra/keys/cmh-ra-key*
34e653331c65e103bada3b3e9ff09cde  /etc/cmh-ra/keys/cmh-ra-key.priv
9910ba39a21b2dfd941bef2dc1921012  /etc/cmh-ra/keys/cmh-ra-key.pub


[Ap15e]

Yes, they do.

[futzle]

Yes, they do.

Thanks for checking.  At least it gives me a way of decrypting the SSL tunnel network traffic between the Vera and mios.com.  (Just curious, not paranoid.)

[not12bhere]

And they removed the GUI feature for disabling remote access in UI4 why???

I really hope no black hat reads this forum and uses one of the ip addresses listed next to posts to find Vera2 vpn traffic to mcv. . .

This product needs HTTPS:// SSL local access control with the ability to disable the vpn to MCV. Otherwise, we are wasting our time discussing "security" on this device.

[futzle]

I really hope no black hat reads this forum and uses one of the ip addresses listed next to posts to find Vera2 vpn traffic to mcv. . .

To be fair, that black hat would have to be listening at your ISP, or on the backbone between your ISP and MCV's ISP.  If that's happening then I am much more concerned.  (The black hat doesn't need to decode the ssh traffic if they are already in your LAN, because they can just connect straight to Vera's port 80, which is all that the ssh tunnel is doing.)

On a related note, it occurs to me that by using a reverse ssh tunnel, I can be sure that Vera is taking to MCV (and not a MitM), but how does Vera know that it's talking to me?  We're all making exactly the same ssh tunnels to mios.com, so how does MCV stop me masquerading as not12bhere?  My theory is that it involves nvram and the seemingly unique keys in /etc/cmh/HW_Key*, but it'd be nice to know.

Still, I agree with your sentiment, and if MCV is going to the trouble to give each Vera a different hardware key in nvram, it can't be much more effort to cut a different ssh identity for each of us too.

[cipherwarrior]

The attack could target Mios servers or neighboring servers possible in a hosted environment.   

But the point is made.   This implementation of SSL is only slightly better than clear text.   Vera is encrypting traffic but giving everyone the key.    It is like locking your door but then leaving the key hanging on a hook right next to it.

[cipherwarrior]

Well actually after looking at LittleBlackBox it looks like the exploit code is already there.   Only a matter of time before they include the Vera SSL keys in the database. 

http://code.google.com/p/littleblackbox/

So much for adding Zwave locks to my setup

[cipherwarrior]

To be fair, that black hat would have to be listening at your ISP, or on the backbone between your ISP and MCV's ISP.

BTW, that is not entirely true.   With open public wifi I would be able to intercept your SSL connection when you are sitting at the local Starbucks, etc.    There are actually other attack tools out there which will spoof open wireless APs.    So in essence, it will appear that you are connecting to the Starbuck SSID but actually connecting to the attacker's machine which is proxing your connections back to the wireless.   It would be difficult to determine that your connection has been attacked.

Once the blackhat has intercepted your connection at Starbucks they could then use that to compromise your home security system and rob your house.   Not good. 

See "carmetasploit"

[futzle]

With open public wifi I would be able to intercept your SSL connection

While technically true, that's unlikely to be how people have their Veras hooked up to the Internet.  The closest I can imagine is when users are putting a Vera at the downstream end of a WiFi bridge.  Hopefully users aren't silly enough to disable WPA or use a weak password in that topology.

The Starbucks scenario is more of an issue for users dialling home, which is over HTTPS.  Granted, HTTPS is vunlerable to DNS spoofing, but that's a different attack vector and not the subject of this thread.

[mikkelj]

On a related note, it occurs to me that by using a reverse ssh tunnel, I can be sure that Vera is taking to MCV (and not a MitM), but how does Vera know that it's talking to me?  We're all making exactly the same ssh tunnels to mios.com, so how does MCV stop me masquerading as not12bhere?  My theory is that it involves nvram and the seemingly unique keys in /etc/cmh/HW_Key*, but it'd be nice to know.

You're not far from the truth

Check out /etc/cmh-ra/cmh-ra-daemon.sh (I think - I don't have access to a Vera box ATM). The script establishes the ssh tunnel, and then does something like this:

echo "$HW_KEY $PK_AccessPoint $SomeThirdVar"

This is just off the top of my head, so YMMV.

I am interested in how this works out too - I wanna understand the SSH tunnel stuff a bit more, and I'll look into it when I get the time. Wireshark is supposed to be able to decrypt SSL in realtime provided the keys - should be possible.. If not, I think Ettercap is capable of doing MITM.

[computerjohn]

Granted that someone needs to know your home address, but that is why I didn't add Z-Wave locks to my home.  My alarm system is connected to Vera.  I can arm, but I MUST enter my alarm code to disarm my system. 

To be fair, that black hat would have to be listening at your ISP, or on the backbone between your ISP and MCV's ISP.

Once the blackhat has intercepted your connection at Starbucks they could then use that to compromise your home security system and rob your house.   Not good. 

See "carmetasploit"