The Vera Community forums have moved!

Advanced => Security => Topic started by: dcrowley on August 30, 2013, 08:10:58 pm

Title: Fixes for vulns in recent advisory - Community feedback wanted
Post by: dcrowley on August 30, 2013, 08:10:58 pm
This thread is based on the advisory I published at https://www.trustwave.com/spiderlabs/advisories/TWSL2013-019.txt.

The advisory discusses the following vulnerabilities in the current firmware version (as of this writing):

Lack of authentication on web console by default
Insufficient Authorization Checks
-Firmware Update
-Settings backup
-Test Lua code
Path Traversal
Cross-Site Request Forgery
Lack of authentication on UPnP daemon
Vulnerable libupnp Version
Server Side Request Forgery
Unconfirmed Authentication Bypass

Here are some short-form fix suggestions for each:

Lack of authentication on web console by default
===
Enable authentication on the web console by default, and enable SSL. Either use a CA-signed cert with a generic domain that resolves to your Vera's IP address (in the same way that the detect_unit.php script does) or generate a self-signed CA certificate and SSL certificate and ask the user to install the cert to resolve the browser warning about self-signed certificates.

Insufficient Authorization Checks
===
Firmware Update - Do not allow Guest users to update firmware. Implement digital signature on firmware to be able to distinguish stock firmware from modded versions.
Settings backup - Do not allow Guest users to generate backups. Encrypt backup file so that its contents cannot be read or modified by an attacker.
Test Lua code - Do not allow Guest users to run Lua code. Do not run tested Lua code as root.

Path Traversal
===
Do not allow slashes in filename parameter provided to "get_file.sh".

Cross-Site Request Forgery
===
Incorporate an unpredictable element into each sensitive request to prevent cross-site request forgery attacks.

Lack of authentication on UPnP daemon
===
UPnP is an inherently dangerous protocol. I recommend disabling it by default and giving users an option to re-enable it if desired, with a warning about UPnP being unauthenticated and unencrypted. I also recommend removing the "RunLua" action, or at least adding a password to prevent unauthorized access (This does not prevent someone from eavesdropping, but it prevents remote attacks if people really must use UPnP.)

Vulnerable libupnp Version
===
Update the version of libupnp in use to the latest version.

Server Side Request Forgery
===
I don't have any good ideas for fixing this, since the only real way to fix this is to disable it.

Unconfirmed Authentication Bypass
===
MCV says that they have checked and that this is not a vulnerability. Additionally, it seems they are changing the remote access architecture. So, moot point.


If you see a problem with one of these suggestions, or have a better idea on how to fix something, please post a reply!

EDIT Aug 30 7:14 CT: Updated table of contents to add dashes indicating subitems to "Insufficient Authorization Checks" item.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: micasaverde on August 30, 2013, 09:12:59 pm
@dcrowley,

This is a lot more productive.  But I don't see the fix here.  Every recommendation on the list is irrelevant unless you secure the web UI.  Sure, UPnP is not an encrypted protocol and allows a hacker in the home to control the device.  But, turning it off is going to do nothing to thwart a hacker if the web UI is not secure since he could just do the same thing in the web ui.  Similarly, the web UI is how you access the OpenWRT configuration panel, which lets you set a root password for the ssh console, and install new packages like telnet.  So, again, if the web UI is not secured, a hacker on the network can do anything he wants with the system anyway regardless.

Thus, the one gating issue is securing the web UI.  The rest is trivial once that hurdle is solved.  And, like I explained to Robert months ago, and posted in this thread earlier, there are 4 options: 1. HTTP authentication, which is pointless since it's not encrypted.  2: CA-signed cert, which isn't commercially viable since it requires the user buy a cert from a third party, like Verisign, go through an ID check, get a static IP, and a domain name with reverse DNS.  3: self-signed cert, which isn't accepted by most browsers without a process that is too technical for 99% of the users, and, even then will never work with lots of tablets and phones.  4: turn off all local access and make it a cloud/subscription service.

We explained to you guys that those were the options we came up months ago, and explained why none of them was viable as a default option.  Your not presenting any new solution.  You're just restating what I already told you, and ignoring the fact that the solutions aren't viable.

For example, one option is to 'enable SSL on the web console by default with a CA-signed cert with a generic domain that resolves to your Vera's IP address'.  So, think this through.  The Vera's IP can be any of millions of choices.  There are 65,000 IP's in the 192.168.x range, 16 million in the 10.x range and 172.x ranges.  We have no way of knowing WHAT ip address the customer's DHCP server is going to give.  It could be any one of those 30+ million choices.  So, what you're proposing is that we buy 30+ million CA-signed certs for every IP address (which would cost hundreds of millions of $), and means we need 30+ million domain names, and then we instruct the user to pick the right domain out of those 30+ million that matches his IP address!!  And, on top of this, for the umpteenth time, we have a lot of users who put this in a remote location, like a cabin or new construction, where there is NO internet.  So if we use a CA-signed cert, it WILL be unusable unless there's an active internet connection.

You also say that we could use SSL with a self-signed cert and have the user reconfigure his browser.  But, you fail to address the fact that this is way too technical for 99% of users, and many browsers, particularly in tablets and phones, don't even allow the user to install their own certs anyway.  So, if we do as you say and have this turned on by default, a very high percentage of users will never even be able to access his system, which means there will be a very high percentage of returns that will ultimately drive us out of business.

So, be very specific: Do you have a viable solution for securing the web UI that is usable for mainstream users?

There's no point in discussing the other issues until the issue of securing the web UI is solved.  And, remember, we already said we'd add the option of using ssl certs to secure the web ui for those 1% of users who are willing and/or able to buy either a CA-signed or self-signed cert.  So, we'll do this.  But that only solves the problem for 1% of the users, so we obviously cannot have this turned on by default as you say and tell the other 99% that they're out of luck.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: futzle on August 30, 2013, 09:17:27 pm
I'm very happy to see some robust and constructive discussion about MiOS security here on the forum.  Please allow me to throw the following into the mix:

LuaUPnP runs as root.  Does it have to?  OpenWrt does allow a multiuser environment so the naive answer is "yes", but perhaps there are snags when communicating with some of the hardware like the Z-Wave chip.  Perhaps a split privileged/unprivileged model with a pair of processes, as seen in tools like sshd, would work.  If all plugin code ran as a non-root user then many of the existing vulnerabilities (arbitrary Lua execution, leading to arbitrary shell execution) would not happen, and it would be possible to protect sensitive files like /etc/cmh/HW_Key from prying eyes.  Preventing arbitrary root execution means that it might even be possible to usefully install an egress firewall on Vera, preventing Vera from becoming, say, an SMTP spambot.

Every Vera uses the same SSH private key to communicate over the MiOS tunnel.  That means that I've got your private key, and you've got mine.  We can decode each other's tunnel stream, and worse, I can impersonate you if I have your hardware key.  I'd like to see the option for users to generate their own SSH keypair for the tunnel, making it a truly "private" key.  Also a (user-visible) return of the option to completely disable the tunnel.

As well as allowing the Vera web server to create a self-signed certificate, I would welcome the option to install a real CA-generated certificate.  I've got my own domain and I use StartSSL's free certificate service.  This probably isn't common.  (Edit: I see this is already in the works.  Thanks.)
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: dcrowley on August 30, 2013, 09:32:00 pm
@micasaverde: I think you may be confused. Self-signed certs do not prevent users from accessing sites, it only presents a warning, one which can be dismissed by the users.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: micasaverde on August 30, 2013, 09:37:24 pm
@futzle, The problem is that running LuaUPnP as non-root only makes IF we secure the web UI because with the web UI you can access OpenWRT's control panel and, say, install telnet, which gives you root console access anyway.  It's also useless to make all the power user features like OpenWRT's control panel, the ability to install new Linux packages, which requires root privileges, etc. "optional" unless the web UI is secured because anybody could go into the web UI and enable them again anyway.  So it all comes back to securing the web UI.

We're already adding an 'advanced security settings' page for the handful of people, like you, who have an SSL cert.  But surely you understand that it's a very, very tiny % of people who will be able to use that feature, and so it's not viable as a default option for the mainstream user.  And this has been in the works for almost 2 years because a few users have requested this for a long time.  The hold up is that OpenWRT's web server (lighthttpd) never handled https/ssl properly, and it's taken the lighthttpd devs a long time to get it fixed.  It was fixed earlier this year, and we applied the patch, we're just waiting to get the next release out.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: micasaverde on August 30, 2013, 09:48:14 pm
@dcrowley, we've been trying to find a good solution for self-signed certs for years, and have tested them on many browsers.  Some browsers display an ominous warning that the user can ignore (although it will scare most users since it makes it sound like something is not working right), but there are still a lot of browsers, mainly on tablets and phones, that don't take self-signed certs at all.  So, like I said, if turn this option on by default, a lot of users will be stuck and unable to even get to step 1.  That is why we've proposed making this optional, for those users who understand what this means.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: dcrowley on August 30, 2013, 09:59:16 pm
There's a script at https://cp.mios.com/detect_unit.php that will tell you your Vera's internal IP. I think MCV could take this information and return it in DNS based on the IP address requesting it, much like they do with detect_unit.php. That way, you could just put something like "myvera.mios.com" in your browser and MCV would only need to buy a single CA-signed cert for all Vera units, as it can be tied to the domain name and not .

The problem with this, though, is that as soon as someone tears apart the firmware (MCV does not encrypt their firmware so power users can mod their firmware, a decision I agree with and would hate to see them change), they get the server cert and can decrypt the traffic, so in this case it doesn't seem to be a viable solution.

The self-signed cert generated per-install seems to be the only way to do this securely. I understand MCV's point that some Vera users are non-technical (though I don't know about 99%, I think you're all pretty smart from the posts I've seen) so perhaps this could be made an option for those users who can understand certificate warnings and who would like solid security for their connections. MCV, you also make a good point about tablets and phones that will actively reject bad certs.

I disagree with the idea that none of the vulnerabilities are worth fixing if the web UI cannot be secured against eavesdropping/MITM attacks. An adversary who gets five minutes on the network with a VeraLite is unlikely to see any traffic of users logging into the Vera's web UI, but the UPnP port can be immediately used to execute commands as root. Surely, doing something about the UPnP port would make the VeraLite more secure. There is no such thing as perfectly secure, only more or less secure.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: micasaverde on August 31, 2013, 12:25:49 am
@dcrowley,

Thank you for a productive post.  I agree with almost everything you said in the last post.  The concept of a custom DNS server that returns the device's internal IP based on the external IP is interesting.  I've never heard of anybody trying that, so it sounds like a new idea.  We'd have to test it with browsers to see how it works and there may be hurdles.  And, even if we did get it to work and wrote our own custom DNS service, it does mean the gateway would be unusable if the user didn't have an internet connection, and as you mentioned, it wouldn't really solve the security issue anyway.

So, like you, we reached the conclusion that the only viable option was self-signed certs, although, as you conceded, it's not something you can have turned on by default and it's not a mass-market solution?so it won't help the mainstream user who will still be using an unencrypted connection.  And if we try to explain what a self-signed cert is in the quick start guide or the setup wizard, it will confuse a mainstream user, so it has to remain an advanced option for the power users.

It sounds like we are in sync now on the issues and understand that there is no practical solution for the mainstream user to secure the web UI, but, now that lighttpd works with certs, there are things we can do for the power user who understands self-signed certs to let them secure the connection, and we are implementing them.  But, considering that I explained all this to Robert many months ago, I hope you will acknowledge that it wasn't fair to say the problem is easy to fix and that we just refused to do so because we were stubborn or incompetent.  It seems that with this last post we're in agreement that the the reality is there is a fundamental gap in today's networking technology, both for local web ui and for UPnP, that means there is no good solution for the mainstream that will secure the web port over the LAN.

The only thing we still have to agree to disagree on is your last paragraph: ?An adversary who gets five minutes on the network with a VeraLite is unlikely to see any traffic of users logging into the Vera's web UI...?  I would agree with that statement only _IF_ we put standard HTTP authentication on the gateway by default.  The hacker would need to sit and wait for a user to login to sniff the password, so shutting down UPnP and the other entry points would mean the hacker wouldn't be able to get in until someone logged in, providing some security.  BUT, what that's not taking into account is that we do not put an HTTP auth password by default because even if we have separate passwords for the unsecure, local HTTP auth vs. the secure online portal, users will be very confused over which password is which and will want to use the same password for both sites meaning that his secure password will be exposed once the user logs in.  It's just not a user friendly solution for the mass-market to tell them that they need to remember 2 different logins and to understand that one login is secure and the other is broadcast every time he uses it.  How do you explain that in a simple picture-based quick start guide?  Since no solution for that issue was ever presented, we're back to the default configuration being to have no password at all, like it is now.  And that means an adversary doesn't need to wait and sniff a user logging in, he will have full access the minute he compromises the network, and won't ever need to exploit UPnP or any other vulnerabilities since he'll already be in, making the rest of the issue moot.  I agree that once we push an update that allows self-signed certs we'll want to patch them so that those power users can have a close-to-100% secure solution.  But, whether or not those other issues are fixed or left open, for the mainstream user who doesn't have any password on the local interface he will always be exposed once someone gains access to his network so we're back to where we are today that it's imperative the user not have insecure wi-fi because there's just no practical solution to secure the local web ui.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: SOlivas on August 31, 2013, 02:04:50 am
You also say that we could use SSL with a self-signed cert and have the user reconfigure his browser.  But, you fail to address the fact that this is way too technical for 99% of users, and many browsers, particularly in tablets and phones, don't even allow the user to install their own certs anyway.  So, if we do as you say and have this turned on by default, a very high percentage of users will never even be able to access his system, which means there will be a very high percentage of returns that will ultimately drive us out of business.

Two of the most popular platforms, Apple's iOS and Android, do allow custom CA's to be installed for accessing sites with self-signed certificates. 

For Android, it seems to depend on what version of the OS you are running, with Gingerbread allowing self-signed certs to be more easily installed

Apple's iOS can be a bit trickier to get a self-signed cert installed.  I've done it, and have used it for S/MIME signatures and encryption for email.


Why not add another option under the security tab, that of enabling two factor authentication using something like Google-authenticator?

https://code.google.com/p/google-authenticator/

Quote
The Google Authenticator project includes implementations of one-time passcode generators for several mobile platforms, as well as a pluggable authentication module (PAM). One-time passcodes are generated using open standards developed by the Initiative for Open Authentication (OATH) (which is unrelated to OAuth).

These implementations support the HMAC-Based One-time Password (HOTP) algorithm specified in RFC 4226 and the Time-based One-time Password (TOTP) algorithm specified in RFC 6238.

Quote
PAM Module
The PAM module can add a two-factor authentication step to any PAM-enabled application. It supports:

Per-user secret and status file stored in user's home directory
Support for 30-second TOTP codes
Support for emergency scratch codes
Protection against replay attacks
Key provisioning via display of QR code
Manual key entry of RFC 3548 base32 key strings

Or, if not this specific implementation, then the HOTP/TOPT authentication as defined in https://tools.ietf.org/html/rfc4226 and https://tools.ietf.org/html/rfc6238.

This can even be enabled for SSH servers, so once a user has entered their password they need to provide an additional code before the server will let them in.

Someone as already ported this to OpenWRT (patches are available):
https://forum.openwrt.org/viewtopic.php?id=38905
https://dev.openwrt.org/ticket/9138

Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: dcrowley on August 31, 2013, 10:37:25 am
@MCV If the user's internet connection is down, they can still access their VeraLite directly via IP as they do today, but will receive the certificate mismatch warning as stated before.

As far as the question of enabling authentication by default, the VeraLite could be made to go through a one-time setup process upon installation where it would generate its self-signed cert (if you go that route) and ask the user to set up an account with MiOS. This way, the VeraLite is vulnerable only during the initial setup process. The other option would be to set up a default password the user would need to use to log in (many networking vendors go this route) that must be changed upon first login.

@SOlivas A 2FA option would be great, that would mitigate attacks via malware. TOTP/HOTP sounds nice (full disclosure: I haven't reviewed the protocol) and would prevent an attacker from being able to hijack a session if they can eavesdrop. However, it still wouldn't prevent eavesdropping without the layer of encryption.

What every major networking vendor does is to use SSL with either a CA cert tied to a domain name (see Linksys and "routerlogin.com") which would require either a special external DNS server or control of the DNS (much easier when your device is also an Internet gateway); or they use self-signed certs and accept the fact that users will get browser warnings.

@MCV I agree with you that SSL is not well designed, especially with the consideration of SSL over the LAN, especially for mass-distributed devices.

One potential option would be to change the control mechanism to SSH and have a client which connects via SSH and issues commands. This would provide very strong security that a mainstream user can easily operate, but would require significant work that MCV may not be willing to undergo.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: dcrowley on August 31, 2013, 11:11:47 am
@MCV I think discussion of the media blitz around this advisory should really go in the other thread to keep this one on topic. I've posted a response about that in the other thread.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: futzle on August 31, 2013, 07:29:55 pm
@futzle, The problem is that running LuaUPnP as non-root only makes IF we secure the web UI

I agree, to a point.  But there is still a class of exploits which bypass port 80 entirely, going straight to port LuaUPnP's control port (3480).  The RunLua feature is one of these.  Independently of how or whether the web UI is secured, these exploits will still exist.

The thermonuclear option is to change LuaUPnP to listen only on the loopback interface, and force all external access to rely on the lighttpd .../port_3480/... proxy, thereby reducing the problem to exactly that of securing the web server.  Is that what you have in mind?
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: dcrowley on September 01, 2013, 11:07:13 am
I think some loose threat modeling might be handy. We can categorize the vulnerabilities and help MCV prioritize what's worth fixing.

Let's consider the following theoretical adversaries listed from most advantaged to least advantaged adversary (complete with silly nicknames):

1. Angry ex-girlfriend (Access to network, guest access to device, unsupervised physical access)
2. Shady friend (Access to network, guest access to device, no physical access)
3. WiFi leech + mitm (Access to network and ability to MITM, no device or physical access)
4. WiFi leech + eavesdrop (Access to network and ability to eavesdrop, no device or physical access)
5. WiFi leech (Access to network but no eavesdrop, no device or physical access)
6. Bad neighbor (Proximity but no access to network, no device or physical access)
7. Bogeyman (No access or proximity to network or device, no physical access)

Angry ex-girlfriend is usually excluded from my threat modeling unless it's a very high security scenario. As such, it was excluded from my testing. The following is the list of vulnerabilities from the advisory, along with the least advantaged attacker who can exploit the vulnerability.

Lack of authentication on web console by default - WiFi leech
Insufficient Authorization Checks - Shady friend
Path Traversal - Shady friend
Cross-Site Request Forgery - Bogeyman
Lack of authentication on UPnP daemon - WiFi leech
Vulnerable libupnp Version - WiFi leech
Server Side Request Forgery - Bogeyman

The server side request forgery flaw can be used by an attacker to load arbitrary scripting content under the domain context of the VeraLite unit. This means that the risk is similar to that of cross-site scripting, where an attacker can control the actions of a logged-in user on the device. This essentially enables a bogeyman attacker to gain an advantage similar to the shady friend, enabling the bogeyman to gain root access in ~6 ways, using various combinations of SSRF with the other discovered flaws.

CSRF can also be used by the bogeyman to gain advantage similar to that of the shady friend.

Based on this model, I draw the conclusion that if the CSRF and SSRF vulnerabilities are fixed, only the WiFi leech or higher level adversary can launch a successful attack against the VeraLite. As such, fixing these vulnerabilities provides the most improvement in security as far as known flaws goes.

Additionally, if the web UI is authenticated by default and you use digest authentication (as is currently the case when the "Do you want to secure this Vera?" checkbox is checked), the web UI can be used only by WiFi leech + mitm. Digest authentication does not expose the user's password and additionally provides protection against replay attacks. The wifi leech + mitm attacker could insert scripting content into the HTTP response, making protection against replay attacks moot and escalating their advantage to that of shady friend. If the web UI requires authentication as it is currently implemented today and does not use SSL, it will still require an attacker to have the advantage of wifi leech + mitm. This is two advantage levels above what is needed for exploitation of the UPnP interface.

So, finally, I disagree with the conclusion that being unable to provide reliable protection against WiFi leech + mitm advantaged attackers on the web interface means that fixing other flaws is moot. The following are still exploitable by less advantaged attackers if SSL cannot be used, for whatever reason:

Lack of authentication on web console by default - WiFi leech
Cross-Site Request Forgery - Bogeyman
Lack of authentication on UPnP daemon - WiFi leech
Vulnerable libupnp Version - WiFi leech
Server Side Request Forgery - Bogeyman
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 07, 2013, 10:17:43 pm
so what u say is that SSL (which can also be hacked and is a pain in the behind for most users who get scared when a warning page comes up) is a solution.
i still dont like the idea of someone having a webpage that you can open which has php script to open the https://cp.mios.com/detect_unit.php (https://cp.mios.com/detect_unit.php) and find the IP and run a all devices service command to open a lock . with or without the /port_3480/ proxy and with even ssl or tls on it.
i rather like it to use TLS1.2 4096 bit key as this is only non-compromised version of the encrypting stuff for webbrowser. but alas only internet explorer is able to handle this (rest is using TLS1.0), so this will be not an option for mainstream. see here http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html

thank god you finally come up with some discussable valid points, thank you for that. and thanks for thinking with us for a solution to the problems. now we finally get somewhere :-)

edit:

thinking some more of this stuff...  ..if you would gain local acces to a (windows) pc you can map a port with upnp controls on the routers upnp to forward the port 3480 to the vera and thus gaining total control. example here http://www.vbforums.com/showthread.php?592823-VB6-PortMapper-UPnP-NAT-Traversal-Class
all in all there are to many holes in the security of the internet and i seriously wonder if this is fixable to a level that less savvy ppl understand also.
better to make a peer connectionmanager in the vera upnp maincontrolpoint so that upnp commands cannot be invoked without the right key.
a setup tool for vera which uses SSH and a key written on the vera.
http acces with a php script which uses its own login mechanism.
just some ideas.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: RichardTSchaefer on September 08, 2013, 07:51:39 am
Maybe I am clueless ... but how many people actually use the UPNP interface to Vera ...

Vera's interface is not a complete or 100% conforming. Why not just disable it for the majority of people ... For those that want it ... they can make the Security trade-off.

We can easily secure Port 3480 (And I think there is another port or two as well) by binding that to the localhost interface ONLY  and requiring the http proxy to forward. Securing ALL connections with the Web server using a certificate would then make me very happy! 

NOTE: I would expect that MCV would also go through the front door when accessing Vera and NOT the back door (bypassing the http proxy)
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 08, 2013, 10:37:57 am
its using the UPnP for steering the devices so its not really good idea to turn off. the outside port could be turned off (would ruin many peoples remote interface) or using proxy-forward or authentication mechanism in peer communication
i'd go for the peer authentication with a key as this has least inpact of all.
http://<vera-ip>:49451/URL%20for%20presentation gives the UPnP spec page on my windows pc but doesnt seem to work.
scanning with UPnP tester doesnt bring up the .root device for vera which it should.
2 decimal behind comma for temperature devices conform UPnP specs also not working. http://forum.micasaverde.com/index.php?topic=10244.0 (http://forum.micasaverde.com/index.php?topic=10244.0) Ap15e mentioned a lot of other stuff that should be noted and MCV did not listen to its users. stil wonder why ?
now that its in the news all of a sudden there is a need for doing stuff to change what is not easy to change but the things that would require changes is being neglected.. ow and there is documentation wiki which i and other forum users have rewritten and extended as MCV was transparent and honest to the users that it didnt have time for this. also the hours i put into translation which in the end turned out was not possible because of the used strings for the main UI. and the extra translation for the tricktv platform which shouldnt be there in the first place. giving me a test account with which i could turn the lights and heating for the whole mcv offices .. taking out the test-vera UI as it was subject to hackers.. exchanged by a test-vera which you can buy as developer .. the wiki that was being abused by spammers.. etc.. etc..
i see where MCV interest is primaly  ;D
time to fix it all up  ::)
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: RichardTSchaefer on September 08, 2013, 11:12:26 am
Quote
its using the UPnP for steering the devices so its not really good idea to turn off. the outside port could be turned off (would ruin many peoples remote interface)
I am not sure I quite understand what you mean my steering ...
I though most of the remote user interfaces use the HTTP based LUUP requests.
I am not sure what devices uses the UPnP interface ... I do not think I have any.
Maybe the cameras ... I have not looked ... but I think Vera uses just the HTTP interface for these.

So if everything goes through LightHttpd, and we disable UPnP we have one place to secure.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 08, 2013, 11:16:23 am
well have a look at the device type in advanced settings of device. there is a upnp point. also many remotes use port 3480.
see here http://wiki.micasaverde.com/index.php/Luup_Intro#Introduction_to_Luup_development
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: RichardTSchaefer on September 08, 2013, 11:29:21 am
These are not UPNP issues.

To change direct access to Port 3480 will require change to remotes ...
But it's simple you can replace:

http://xxx:3480/...

With
http://xxx/port_3480/...

The Light Http is already setup to proxy this port. MCV already uses this because of Cross Site scripting issues with the remote interface.

Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 08, 2013, 11:52:53 am
but if you exchange port 3480 for port 80 then it has the same problem ?
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: RichardTSchaefer on September 08, 2013, 12:23:22 pm
Notice:
http://YourIPAddress/port_3480/data_request?id=user_data
is the same as:
http://YourIPAddress:3480/data_request?id=user_data

The former goes through the HTTP proxy first.
They have not setup the proxy for the HTTPS port ... but that's a one line change.
Other changes need to be made to use certificates as well.
When you talk to port 3480, you are talking to LuaUPnP directly.
I am proposing that we only allow access via the Light httpd daemon and only allowed access via certificates ... 
This implys that we only allow LuaUPnP to read from 127.0.0.1:3480 which would be accessed via the proxy. That's a MCV change.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 08, 2013, 12:27:23 pm
yes but if you send a command for open lock to port 3480 or to /port_3480/ it would still open the lock right ? so if i put this in a webpage with some php to find the vera ip and send command to /port_3480/ it would still work.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: RichardTSchaefer on September 08, 2013, 12:37:56 pm
If the Vera Web Server was setup to only respond to authenticated (via certs) requests  there would not be a problem.

Then unless your PHP server presented the certificate ... it would not respond.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 08, 2013, 12:51:15 pm
but then it would make it troublesome for the remote interfaces. i like the idea of having a key first to make contact to the vera upnp and then be able to send commands. wont need a ssl cert and stuff. just send the right key to vera and vera would open up the rest of the commands to the ip used only.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: RichardTSchaefer on September 08, 2013, 01:06:05 pm
If you do that on an IP basis ... if you open it up to your desktop (because you run the Vera Control Panel)  ... than you are opening the possibility for malicious script to access your Vera via your Home computer.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: guessed on September 08, 2013, 01:07:29 pm
Yup, there are a few extra's that'll need to be locked-local.

Excluding SSH, and DNSMasq, here's the complete list of TCP Listen entry points.  Note that ser2net is a flexible list, depending upon what you have serial-attached to Vera (49451 is the original version of 3480):

Code: [Select]
lighttpd   2358   root    4u     IPv4       2672      0t0        TCP *:80 (LISTEN)
LuaUPnP   10519   root    6u     IPv4    2123595      0t0        TCP *:49451 (LISTEN)
LuaUPnP   10519   root   10u     IPv4    2123601      0t0        TCP *:3480 (LISTEN)
ser2net   10612   root    4u     IPv4    2123708      0t0        TCP *:3484 (LISTEN)
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: RichardTSchaefer on September 08, 2013, 01:24:23 pm
@guessed
Do you know if there a significant number of clients to the UPnP interfaces to Vera ?
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 08, 2013, 01:32:11 pm
If you do that on an IP basis ... if you open it up to your desktop (because you run the Vera Control Panel)  ... than you are opening the possibility for malicious script to access your Vera via your Home computer.

ok then sending the key everytime with the command would be better.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: guessed on September 08, 2013, 03:48:46 pm
@guessed
Do you know if there a significant number of clients to the UPnP interfaces to Vera ?
To my knowledge, all the mainstream UI's are using the Vera [specific] mechanism to display data, and invoke actions, from Vera.  There are some variants of this, including the port differences (49451, 3840 or Proxy via port_3480) and some subtle variations on the entry point (user_data2 et-al) but otherwise they're all fairly consistent.

The ones I'm less clear on relate to the Windows Media Center controllers, since I've never used them.


For raw UPnP, I doubt that people use it...  It has a lot of very old bugs that haven't been addressed (timeouts/performance on SSDP Discovery, lack of NOTIFY support, non-compliance with UPnP state handling etc) that I can't imagine it would be usable in practical terms.

For "tiny" systems, with a small # of devices, some of these issues won't be as important.  People quickly grow systems beyond the tiny state.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: micasaverde on September 08, 2013, 11:12:57 pm
I agree it makes sense to turn it off by default since the few people who do use it will be saavy enough to go into a settings and turn it back on.  The only reason we left it on by default is that, since the regular http port 80 isn't protected anyway, turning on UPnP doesn't hurt anything (doesn't add any extra protection).  It's like locking your car door and leaving the windows down.  In the beginning we didn't know how many people would use it vs. the proprietary interface, so we left it on, and maybe for existing users who might be using it, we'll leave it on by default when we provide a firmware upgrade so they're not left hanging and unaware why their stuff stopped working.  But, even though it doesn't solve the security issue, I think it's a good idea to have it turned off by default.  However I think we're going to have port 80 AND the self-signed cert on https port 443 on by default, and have a 'secure my device' option to turn off port 80 and upnp, but which first tests if the browser will accept an https connection, before proceeding.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: RichardTSchaefer on September 08, 2013, 11:24:55 pm
@micasaverde

I like the strategy ... you should only be allowed to turn off Port 80 from Port 443 while using a cert!

Need to define the strategy for exchanging the certs for 3rd party apps ...
Will they need to turn off Security and connect on LAN Port 80 to setup the certs ?

Will access to Vera through the MIOS tunnels also be protected by the same certs ?

Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 09, 2013, 01:02:33 am
thats a good start to tighten security.. but by UPnP you mean the raw UPnP (noted by guessed being unusable) or the port 3480 ?
the mios tunnels are going over a ssh connection from what i read.
the problem is this port 3480 which allows on local net a command for opening a lock and the url that gets one the ip for vera.
there is a number of remote programs users made that use the port 3480 so what is going to happen to this ?
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: RichardTSchaefer on September 09, 2013, 06:52:25 am
@Da_JoJo
There have been claims that Vera is open (from a security perspective) in order to support the uPnP protocol.
It may have been a design goal for Vera ... In fact the name of main app is called LuaUPnP because of this. But I did not know of any actual users of the uPnP protocol. Mostly confirmed by guessed and MCV.

As a result MCV appears to be planning to secure the access to Port 3480 (and as guessed indicated port  49451). LuaUPnP would only listen on localhost. Any application that sits on Vera could access the LuaPNP application with a local connection. Remote access would be by the Light HTTPD daemon and would be available by making the following changes to the existing interface.

Change:   http://Vera.IP.LAN.Address:3480/...
To:          http://Vera.IP.LAN.Address/port_3480/...

I assume if they leave Port 80 open they may also allow access to Vera.IP.LAN.Address port 3480. This would provide a transition period for remote apps to upgrade their apps.

When they disable port 80 and Vera.IP.LAN.Address port 3480, 49451 then you will have to access via https (port 443) and present an authenticated user certificate.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 11, 2013, 10:55:52 am
sounds like a good plan.
it would also be nice if they change that to : https://VeraLocalLanIP/serial/loginname/password/port_3480/ (https://VeraLocalLanIP/serial/loginname/password/port_3480/)
and the network neighbourhood device now called: Mios serial  to Vera 2/3/lite serial
and change the presentation url from: http://192.168.1.5:49451/URL%20for%20presentation (http://192.168.1.5:49451/URL%20for%20presentation)  to https://VeraLocalLanIP (https://VeraLocalLanIP)
fixing the UPnP device presentation to other devices on lan. making the rest of the UPnP control internal and as noted proxied to localhost.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: dcrowley on September 13, 2013, 06:43:56 pm
so what u say is that SSL (which can also be hacked and is a pain in the behind for most users who get scared when a warning page comes up) is a solution.

SSL/TLS is rather broken and especially with the NSA spying revelations that have come out as of late, the entire security community is abuzz trying to figure out how to fix it (or how it is broken). There is a large body of study on SSL/TLS weaknesses, but it's about the best that can reasonably be done without significant re-architecture of the VeraLite.

As I said previously, there is no perfect security. Doesn't exist. Everything is vulnerable; security engineering and architecture is just about increasing the time, effort, and resources needed for an attack to be successful. I highly doubt that you are sitting in front of your computer in full-body kevlar armor to keep yourself safe from bullets. Neither am I! This makes us both vulnerable to bullets. If we were sitting in front of our computers in full kevlar armor, we would still be vulnerable to explosives. However, I don't know about you, but I don't work for SWAT or live in Syria, so I've decided it's not worth it for me to wear kevlar armor. That stuff is HEAVY and not very fashionable. The benefits I get from not wearing kevlar armor outweigh the risk of potentially being shot.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 13, 2013, 08:23:36 pm
@dcrowley
wouldnt it be better to use TLS1.0 with 4096bit key as this is a little more secure then SSL and all browsers can handle it and would take the time needed to hack it to the maximum archievable within reason. Also the option to have, like the remote to vera, the login to UPnP like this : https://vera-ip/username/pass/serial/data_request?...
the NSA got help from the designers of system-security and several security experts as well as social-engineering opening every possible hole there is in security and this cannot be closed by any existing security methods. also dns structure is so that there is considerable lack of security, if you have the right key then one could compromise it and even take over the ownership of the domain, which would be a huge pain in the behind.
i get the point of securing it so that it would make a big hurdle to take for exposing the inner layers of the vera and keeping it userfriendly. im sure if someone wants to hold a gun against my head to get the password, the security is not neccesary anymore then as there in allready. i do not have a fortified bunker and so dont the common user lol. the thing is to make it so to speak "the frontdoor isnt wide-open for intruders/mailicous scripts". in my opinion it would be great addition to vera if the UPnP port 3480/49451 is protected like the online version of it mentioned above here.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: dcrowley on September 14, 2013, 12:10:10 am
@dcrowley
wouldnt it be better to use TLS1.0 with 4096bit key as this is a little more secure then SSL and all browsers can handle it and would take the time needed to hack it to the maximum archievable within reason.

Sorry, yes, SSL and TLS are often used interchangeably and a lot of people don't know what I'm talking about when I say "TLS" so I just go with "SSL". Anyway, the breaks in modern versions of TLS require very specific conditions, like the ability to send tens of thousands of requests as the user, where some part of the request is reflected in the response and the response is also compressed. Pretty specific scenarios. So to say that modern versions of TLS are "easily hackable" isn't quite right. Hackable, maybe. As we know, so is everything. To be fair, breaking TLS usually isn't the easy way in.

Quote
Also the option to have, like the remote to vera, the login to UPnP like this : https://vera-ip/username/pass/serial/data_request?...

I like this idea. My only issue with this is that the username and password are passed in a URL. Not a great idea because this sort of information ends up in web logs, proxy logs, browser history, etc.

Quote
in my opinion it would be great addition to vera if the UPnP port 3480/49451 is protected like the online version of it mentioned above here.

I agree. I only learned of port 3480 after releasing the advisory mentioned in the OP. Trustwave has contacted MCV privately about it, but I suppose the cat's out of the bag now that it's been mentioned in a public forum by someone else. If I could get only one thing changed, it would be this. An img tag is enough to do nasty things with this as it is currently:

<img src="http://VERA_IP:3480/NASTY_RUNLUA_CALL_HERE">

Get someone on the same network as a VeraLite to visit a webpage with one of these for each common home IP address (192.168.1.1-256,192.168.0.1-256) and their browser will happily attempt to run the command against each IP until it runs out of "images" to load.

EDIT: fix for typos 9/13 11:11pm
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 14, 2013, 08:53:20 am
yup thats what i tried to tell... some php or javascript running a loop would be too easy to script and screw up the system. if this was run on the same browser that has the SSL/TLS cert opening this page in a popup/iframe window then it wont make a difference this whole SSL stuff, correct me if im wrong.

perhaps its not a great idea but it would only stay in the local pc browsers history. could set the page on vera which handles the request to not store local cache. and over a TLS connection it would be better then no login. perhaps a key generated with time/login/pass in it would work, but it would break the system for having the easy way of controlling a device with a simple link. so i guess its a compromise.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: dcrowley on September 15, 2013, 02:47:49 pm
yup thats what i tried to tell... some php or javascript running a loop would be too easy to script and screw up the system. if this was run on the same browser that has the SSL/TLS cert opening this page in a popup/iframe window then it wont make a difference this whole SSL stuff, correct me if im wrong.

A client SSL/TLS cert can authenticate, but does not protect against tricking a user into submitting a request.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 15, 2013, 05:56:52 pm
hence the idea of protecting the submitted request with a key or login.. unless someone has a better idea, i would opt for this construction.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: fraga on September 16, 2013, 05:49:06 am
Hello,

I'm about to buy a vera light to start a small system at home, but before doing so I would like to make sure I could secure it without any side effects on the features.
I would like to start to implement TLS/SSL on the web interface.
First question, do you have any ETA to have this feature outside the box ? (I understand this is something planned)

In the meantime, can I do it myself by tuning lighthttpd.conf and use openssl to generate my own self signed certificates ?
Otherwise, do some of you use a front reverse proxy with ssl termination to allow access to the vera ?
I have no knowledge related to Upnp so I will look at this once I have everything in my hand. However, it could be a good idea to upgrade libupnp to the latest version.

Thank you in advance for your feedback.
Maxime
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: futzle on September 16, 2013, 06:41:15 am
I'm about to buy a vera light to start a small system at home,

A note on forum etiquette: your post will be seen as trying to hijack an existing thread with a different topic. If you want more or better answers, start a new thread.

The best answers to your questions can already be found on the forum. You can probably convince lighttpd to use a self-signed certificate. That won't protect you from port 3480 exploits. Several of us have set up VPNs for secure remote access. This works. There are no howtos for doing any of this. You will need to use existing forum posts, your own knowledge, and the goodwill of other forum members to get what you want.
Title: Re: Fixes for vulns in recent advisory - Community feedback wanted
Post by: Da_JoJo on September 16, 2013, 11:03:06 am
upgrade to latest libupnp is not much of use in this particular case. and like futzle noted: do not hijack threads.. there is a beginners-section on the forum, mostly consist of reading and searching. once you get to the point of being familiar with the system you could opt some good points here which might be usefull. the points stated obviously aren't.