Hubitat over HTTPS/SSL using Apache

🚧 Developers
10

I am not saying there are vulnerabilities with your setup. However that is a very complex and customized solution.

In an effort to not repeat myself, I am not going to speak to the fact that HTTP on a local network or that your gateway should protect you is not good security practice in 2020. However I will say that loading an HTTP iframe inside of an HTTPS site is.

Log into any hubitat via HTTPS on the local IP address and click on dashboards and then click on any dashboard link. It won't work. because no modern browser allows code execution from a HTTP iFrame within a HTTPS window. This fixing this issue should be one that anyone finds reasonable.

Let say you share a PIN secured cloud dashboard with a friend staying the night. You are going to change the pin after they leave. However when you give them that URL

https://cloud.hubitat.com/api/{UUID}/apps/74/dashboard/174?access_token={TOKEN}

All they need to do is change the Dashboard number (174) to validate and check for any non pin protected dashboards. While cloud dashboards have HTTPS and an access token that token is the same for every site and every session until you manually change it. More than that the token is held inside of the URL. By granting access to one dashboard you have given access to all of them.

This is known as security thought obscurity and it is not a valid security practice for 2020

The fact of the matter is WiFi routers used to be sold with no encryption turned on and terrible default passwords. But times have changed, people have learned that there is a certain level of stupid things that users will do. At some point you need to apply a level of reasonableness to what expectations you have of the device vendor.

A quick search on Shodan shows a number of users who have port 8081 open to the internet on their hubitat. Is that hubitats fault. No. Should this web interface have some basic level of security applied to it. Absolutely.

I do believe that there are issues that need to be fixed. Maybe I am the only one.

11

This topic is frequently misrepresented. As with all things software, all of this is quite doable. We aren't lacking in understanding of these issues. However, we don't have infinite development resources, so of necessity things get prioritized and we work down that list, doing the most important things first. For some people, they are up in arms about our "lack of security", or our failure to go completely to https. What you find is that people who want to use our hub beyond its original target use model are the ones demanding better security. If this population represented a large segment of our customers no doubt these requests would have higher priority. But, the reality is that this is a pretty small segment of customers.

As much as it pains us, and sometimes you, we can't do everything TODAY. If you watch Hubitat evolve over the next few months you will see why. As we grow, more and more of these things will be filled in, we will get further down the list. Eventually, tomorrow does become today.

10 Likes
12

Today is far too long so I want it NOW :stuck_out_tongue: sarcasm emplied :smiley:

13

But ultimately large portions of the community may not understand the risk. Who wants to change the oil and buy new sparkplugs when you can upgrade the stereo. These things are necissary and to see post about the same vuberability from a year ago, with a user base who seems to think that its a wasted effort because there are more fun things to see is really discouraging for me to see as a security professional.

I have seen these sorts of venerabilities pop up in very basic scans and frankly should have been resolved before leaving beta. However it is not my company or software.

Whats more discouraging is the number of people who basically write this off as it wont be a target, it doesn't have the value. It doesn't need to be safe because other things are more unsafe and more valuable. Or there should be something else in place to protect it.

Fact of the matter is every device needs a good secuirty foundation.

I can get off my soap box now. I hope and wish the best for hubitat. Maybe what will come out in the next few months, will have all the wiz bang features with a good secure foundation.

14

What would be much more valuable than a soap box is for you to articulate the risks you see -- not it terms of it should have https, or it should have this or that design, but in terms of real world actual threats of compromise. You have a device behind a firewall that is only reached from outside via secure links through our cloud.

The vulnerabilities you describe above, correct me if I'm wrong, are ones within the LAN, within the household. (Clearly, people can do dumb things like open port 80 on their router.) So please describe the kinds of exploits you think are realistically of concern, that warrant this being higher on the priority list.

3 Likes
15

To further supplement why this exisiting in this system is unacceptable please review this stackoverflow link from 2011. security - Are secret URLs truly secure? - Stack Overflow

Giving up the UUID of a device that from what I can tell doesn’t even change via a complete reset and an oauth token that will allow you access to every dashboard until you reset it and have to rebuild any and all dashboard links.

You have a portal that has login capablility. This could be utilized to get an oauth token with a refresh token. Which would typically be stored in a cookie and not exposed directly as part of the URL. Which could keep a season logged in for a very long time. This would also provide sessions that could be revoke for dashboards.

The system as it stands now allows no ability to revoke access without then granting access back to everyone with access it also will not grant partial access unless everything is secured by a separate pin

If you read the post that started this all it is about a usablity issue in the dashboard menu that has been know about for over a year

The cause is the mixed content which almost every modern browser is blocking.

If these are not specific enough thn please reach out and i can provide further documentation.

1 Like
16

Yes, you're right about this issue. Dashboard improvements is on our list of upcoming projects, with fairly high priority. We have been working with a per-user Dashboard feature that allows for the creation of revocable tokens for a specific user's access to a specific Dashboard. This would specifically address the concern you have raised.

5 Likes
17

I very much agree this is problematic, though it doesn't affect me as I don't give out dashboards to anyone other than my family members (who have physical access to the devices anyway). But, this problem isn't related to the claim you made that we need HTTPS over LAN. To @bravenel's question, what kind of realistic threats do you see lurking within our LANs that HTTPS would resolve?

1 Like
18

By using http on the lan the assumption is that every other device on the land is always trusted and cannot be compromised.

Let say you live at home with a teen who wants to be able to disable the alarm to sneak out of the house. It is possible to sniff the password sent to the hubitat at login, over the lan, or sniff the pin to the dashboard. Or browse to :8081 and shutdown the device.

It is clear from this of this post and other post that exist with similar topics and from running a shodan scan that people are using https. Additional the device can run custom code in the form or drivers and app. If an attacker gains access to the lan. Adding addtional apps to the hub can be used to gain a backdoor back into the network.

security is about layers and the ask is not for some bleed edge new technology. This is technology anyone would expect to find in a modern network device

19

I think that's a bit of an edge case that can be better resolved other ways. I set my alarm to beep when disarmed. Problem solved. Let us not forget that the weakest point of any system is the people involved. It is more likely that this malevolent teen figures out mom and dad's password than it is that he's going to setup a network sniffer to find the password.

Coming from a security background myself, you do balance the likelihood of the attack vs. the impact if said attack occurs. What are the odds that the teen in your scenario does what you described vs. what we all did as children and lie about sleeping over a friends house? That's why I'm asking if you know of a real world likely scenario. Are there any attacks you're aware of that scan for 8081 and shutdown devices? Or that actively scan a network to inject Groovy code into an HE? I'm not saying it's impossible, I'm saying, do such things actually exist, or are we in the world of theory at the moment?

Edit: Being in the world of theory doesn't make it an unimportant suggestion, it's just a very different thing if exploits are in the wild.

2 Likes
20

We are in the world of theory as far as injecting code goes. Everytime someone says no one will take the time to do something some 14 year old in China does.

Something that scans the local network to find further attack vectors absolutly happens. And to find an unprotected page that says wipe this device is a large threat. Even a code on the bottom of the device that would require physical access to the device would be acceptable. And quite honestly I could write a 1 line curl command that anyone could run on any network to reset any local hubitat.

If I didnt think I would get banned I could probaly write a link and put in in this post that would reset the hubitat of anyone that clicked it thanks to mDNS.

Cyber security is about the edge case 99% of the users are going to use it as intended and its OK. But the fact that 1% can use it to do something you shouldnt is bad.

Finding flaws in implementation that are know bad design from a decade ago is concerning

21

I look forward to seeing what improvements you have planned. I know dashboard access management is one aspect that could use some love in my book. One approach I use to secure systems at work is to leverage conditional access - basically rule machine for access:

You would define something like this:

  • User(s): All
  • Dashboard(s): All
  • Location: US Only
  • Method(s): Local & Authenticated Device (ie: Hubitat App)
  • Result: Allow Access

I'm sure implementing something along these lines would take bit of work, as it does allow for a wide range of configuration options. That being said it allows users to poke smaller holes in their security defenses.

There are different kinds of security that should should be discussed, such as HTTPS/SSL. If we are serious about keeping our hubs secure we should be discussing them all.

HTTPS/SSL - This is transport security, and only protects information when it's being actively transferred between systems. This would be a good thing to have implemented, but I would place it lower on the list. Unless you are logging/logged into your hub it has no benefit. Even then the benefit is somewhat limited as the connection is local to your network.

The main risk here is malicious activity on your device/network, where it would be possible to capture and decrypt the traffic. If this is the case you have bigger issues that need to be addressed.

Device Encryption - This can be considered data-at-rest security, and focuses on protecting the data where it lives - your hub. Once again this would be something good to implement, but does have other implications. What happens if the device experiences a failure and needs to be recovered? Where is the encryption key stored, and how do you recover a headless device? You can't connect a keyboard/monitor to enter a recovery key. This would require a lot of effort to implement correctly, and have minimal benefit. If someone has physical access to a device they have total access to the device. Any security can be compromised given enough time, and let's be honest your bank account is more interesting than you home automation.

Remote Access - This is perhaps the biggest issues right now that does need to be addressed in some manner. The two main approaches people seem to take are 1) Setup a VPN 2) Configure Port Forwarding.

If someone is taking the time to setup a VPN for controlling their hub, that's a somewhat secure option. Depending on how it's configured the connection is secure from your device, to your home network - at which point all the same risks exist as not having remote access configured. If your VPN isn't configured well this could be a giant hole into your network, but this isn't a Hubitat issue specifically.

The more concerning approach is uses configuring port forwarding. It's just a giant hole for anyone who finds your IP address to walk right through to access your network. Or more specifically the device you configured in the forward. This is where device and transport security matter more, as the hub is now responsible for the security of your network. If I crack your hub I can use it to attack the rest of your network.

The best thing Hubitat can do here is just communicate the risks of configuring remote access and making it clear they are not responsible for the end results. If you the power user is configuring remote access, you should be taking steps to improve your network security. How can you create a more secure connection to your network - as that's ultimately what you are doing.

Device Security - I think this is the area Hubitat could focus on some. One of the basic security principles drilled into everyone's head is to keep your devices updated. Given we lack access to our hubs, we are entirely dependent on Hubitat to implement security best practices. How is the underlying operating system updated, how is SSH access secured, how is the system accessed, etc. Yes - Hubitat provides updates, however I suspect these are largely focused on the software itself. If they are also updating the underlying operating system that could likely be better communicated.

In short, there is work that can and should be done to improve security. That being said more of the work falls on us - the users. Hubitat can certainly take some steps to help, but most of it falls outside their hands.

22

This discussion is very interesting. However, it misses a very fundamental consideration.

When I was a kid I had heard the word "engineer", and sort of had an idea about what it meant. But one day I decided to look it up in a dictionary. What I found had a profound impact on me. Paraphrased, the definition I found was "an engineer is a person who applies the principles of science and technology to practical problems with a view to their economic impact".

An engineer could design a bridge that would withstand every conceivable load. But, without doing the actual engineering analysis of the real world loads the bridge would be subjected to, the bridge would cost too much to build. This idea that the economic impact is the responsibility of an engineer to consider is a central aspect of technological advancement. Without it, there is only cool stuff in a lab.

Listening to you security engineers, one would get the impression that all of our engineering budget should be diverted to address your concerns. As a business man I say 'nonsense'! We have to apply this principle of engineering to everything we do, to allocate scarce development resources with a view to the economic impact. That's what every business does. That involves making judgement calls on the relative importance of a variety of risks and potential rewards.

Perfection of security has a cost, and failing to perfect it poses a risk. There are thousands upon thousands of hubs in use with no reports of any security related breaches. At the same time there are dozens of posts about theoretical security weaknesses. What is the business to decide? How is that decision to be made? Which one of you who know so much about security is prepared to weigh all of the competing demands and risks, not just the ones you know about?

We move ahead, assessing all that we know, coping with the pressures of the real world as it demands our attention and resources. If you think the risks of using Hubitat Elevation to automate your home are too high, you would not use it -- but wait, you are using it, right? Hmmm.

4 Likes
23

I completely agree. When I took one of my Fundamentals of Computer Security classes years ago, I remember the professor saying "Imagine you have $50. That's your life savings. You want to keep it safe. Which do you do, hide it in a drawer? Or buy the world's best safe for $1000?"

Of course the world's best safe is the safest option. But do you spend $1000 to protect $50? Of course not! The cost of the security outweighs the benefit when you're protecting $50. If I had $1million, sure that $1000 is worth it's weight in gold!

A big part of computer security is Risk Analysis. How likely is a situation to occur in the real world. So for me personally for my own HE setup, I don't foresee my wife (the only other person in my house) hacking my LAN to gain access to our Hubitat. Is it possible that one of my neighbors hacked my wifi, is using airsnort to sniff my wifi traffic, and has sniffed my HE password? I suppose it's possible. However, since my neighbors are people who as soon as they found out I'm a developer had me come over their houses to setup their wifi for them... probably not likely.

Right now, honestly, my biggest security weakness (I've mentioned it a couple of times so I won't beat a dead horse) is that I hate that as MQTT is becoming an internet protocol, not a LAN protocol (both Azure and AWS have cloud based IoT hubs using MQTT), that I am sending OAuth tokens over the internet in plaintext because MQTTS isn't supported. That's much scarier to me than stuff on my LAN. Still, I accept the risk and do it because I say to myself "the reward outweighs the risk."

We all take risks every day, every time you get in a car it's a risk. But we decide it's worth it (most of the time) an accept the risk. Computer systems are no different. Now if @bravenel said "all we have to do is Https=true but we refuse to do it!!!" then I'd agree, bad decision. But I'm sure there is a lot more work involved than something so simple. You have to build a UI to enable/disable https, provide a means to upload certs (and manage when they expire, a huge problem with certs that almost no one does well!), implement mDNS to provide a DNS entry for the hub instead of just an IP... all that takes time.

2 Likes
24

I put about 200 hours moving my house in its entirety from x10 to zwave/zigbee on hubitat. Then I started to find flaws. I guess thats my fault. I should have searched for the security issues first. Based on the reaponces from the community I guess I will need to refer back to something I learned when I was younger. "Dont hold onto a mistake because you spent a long time making it"

My issue isnt that you build a bridge to not withstand an unimaginable load. Bit that the bridge was build with a decades old design from the start.

25

I don't think that's fair. As we've already agreed, most CONSUMER devices, to this day, are built with the same level of security as HE. It's not a decades only design, it's a very common design for LAN. As I said, HIPAA, FERPA, PCI, and I believe Sox, none of them require LAN to be encrypted. LAN traffic being unencrypted is, for better or worse, industry standard. HE is not some oddball here. I'm not saying adding HTTPS at some point is a bad idea, I'm saying, as someone who is a business person myself, is it the wisest use of resources? Probably not. I suspect sales are not won/lost because of the lack or presence of a LAN based HTTPS solution.

Edit: I also don't think @bravenel said "no" so much as "likely, not now"

1 Like
26

This is precisely the point.

Choice (a): Invest x dollars in a feature that gets y new sales.
Choice (b): Invest x dollars in a feature that gets 1 new sale.

Which would you do as the CEO of the business @Hasty1? Now, cascade those decisions over time, toss in security experts buying the product as a result of having made the right choice (a) at some point along the way, and discover them saying, wait, you should have made choice (b).

27

there's also a subpoint... y new sales lead to z new dollars which gives you more resources to eventually do (a), (b), and (c) and (d).

1 Like
28

Yes, and making choice (b) puts you out of business with not enough sales. Thus it goes, round and round...

3 Likes
29

I am going to take a beat here after reviewing everything that has been said.

First of the response from Hubitat has actually been acceptable. Security bug noted, We'll put it on the list. However I feel like I have to defend this from a mob of people who this that this it not worthwhile.

Statements like the ones above do get under my skin, (sorry @LostJen you just happened to be the one in this thread, there are many here who share your view point) it makes me feel like the consensus is security is the end users responsibility and the platform has no responsibility in it. From my viewpoint the community in large is not as concerned about the security of the platform as I am. So I will start taking concerns direct to support and not post them in the community.

So, Hubitat has bugs and issues. The support team seems to be taking them into consideration. The community at large doesn't want to hear about it.

The only other issue that I have is the timeline. Finding what seems to be small bugs and finding a post from over a year ago where a staff member mentioned it was being looking at and still having the bug exist today is a bit disheartening. However it also seems that Hubitat would rather focus effort on releasing "Product 2.0" a year later than spend 10-40 hours to patch "Product 1.1.0" that has said bug.

@dman2306 the above quote was a targeted jab at the design of the cloud dashboards. The URL being the locator and security was considered insecure a decade ago. Am I glad to hear about the new version, you bet. Do I think the old version should have made it to production. Hell No. But that obviously hasn't stopped sales.

@bravenel My primary issues here doesn't actually seem to be with Hubitat's response to security issues, it seems to be with the communities ability to instantly shoot them down as not an issue that needs looking into because they feel safe enough. That said there are security issues that exist that should have been caught and corrected before feature release (again dashboards)

That being said I will probably move away from Hubitat when time once again allows. For now it will just be removed from the cloud and the app removed from all devices and dashboards uninstalled.

Respectfully