Fixes for vulns in recent advisory - Community feedback wanted

[dcrowley]

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.

[micasaverde]

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

[futzle]

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

[dcrowley]

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

[micasaverde]

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

[micasaverde]

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

[dcrowley]

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.

[micasaverde]

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

[SOlivas]

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/

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.

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

[dcrowley]

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

[dcrowley]

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

[futzle]

@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?

[dcrowley]

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

[Da_JoJo]

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

[RichardTSchaefer]

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)