Announcement

Collapse
No announcement yet.

Security related question

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Security related question

    I purchased the RaspberryIO plugin several weeks ago, and I have it successfully setup with a Raspberry Pi 2 and a couple of Zero W's, all connected to HS3 via WiFi. Some careful reading of the forums got me up and running without any difficulty.

    The Raspberry Pi is setup with a 4-relay board I got on Amazon, and a stacked homemade input board with zener protection for 7 inputs. Two of the inputs are wired to magnetic switches to monitor open/closed status of the garage doors. They work perfectly.

    I'd like to use the relays to wire across the switches of a wireless garage door remote - using the pulsed output of the relays to emulate a human pressing a button on the remote, thus opening the garage door. Technically, this is a no-brainer.

    However, it's easy to see some serious shortcomings of this method. I just don't know what the security ramifications are, and I literally don't know what I don't know.

    First there's the WiFi link. I use WPA2, but it's been compromised since 2017, and I have no idea if it's been patched on Raspbian or my router.

    And then (the reason for this question in the first place) there's RaspberryIO. Does it provide any encryption between HS3 and the Raspbery PI, or does it assume it will be used strictly hardwired, not exposed to WiFi? Or, is it assumed that the user would have enough common sense to not use it for an application that would allow someone free access to their house if something went south? (By the way, common sense and I don't get associated very often!)

    As an aside, none of this would be necessary if I hadn't made the incredibly stupid mistake of replacing my garage door openers with Chamberlain MYQ systems. Chamberlain is a company that thinks it's a smart Business decision to charge a monthly fee for the privilege of connecting MY garage door opener to a third-party home automation system. I know there's an HS3 plugin for MYQ, but it appears to be like playing Wack-A-Mole keeping it working every time Chamberlain tries to break it.

    Gary Sanders

    #2
    On the wifi issue, it is beyond statistically unlikely that you would be directly targeted by an attacker that would then get on your network and determine the api to your raspberry pi and use that to enter and attack or rob you. If it where to happen, the attackers targeted you and would have found another way in. Anything else is politely paranoia. I would be much more worried about the MYQ service or something like that getting hacked and being able to control doors from it, that is a much much more likely scenario and would result in a random crime (e.g. anyone that robbed you likely could not have planned that someone hacked MYQ right at the time they happened to be passing by and took the opportunity (again unless you were being targeted by a very determined attacker))

    I personally use a device called a GarageDoorBuddy. Ive been meaning to write a plugin, but the api is so simple in developer mode (its just an HTTP get) that I just use the built in HS function to toggle it. I just put things like that on a private vlan and block their access to the web. Then the HS machine has access and I am comfortable with the way I tunnel that for remote access via myhomeseer (Am concerned about asp and mono/.net bugs being used to exploit, but on things like this I am paranoid as I've 'seen some stuff man' ,) [I forget what movie that is from]

    (I don't normally add my credentials here, but I'm a VP and Fellow at the largest security company in the world, so I don't say the above randomly...)

    Comment


      #3
      I agree that it is very unlikely that someone would try to open your garage door by figuring out the communication protocol between HS3 and the RaspberryIO plugin.

      That being said, to answer your question, the raspberry plugin communicates with HS3 like every other plugin (including local plugins). It uses the HomeSeer Communication Framework (HSCF.dll). I don't know much about it but It looks like it is derived version of this project https://github.com/hikalkan/scs, and I don't think it uses any encryption.

      Comment


        #4
        Thanks for your reply. Based on your comments, I looked a little further into the WPA2 situation, especially as it relates to the physical plant here, and it would probably be more difficult than usual to break WiFi in this particular instance. (In an area restricted from the general public, long password, etc.) I'm not normally inclined to paranoia, but as I said originally, I literally don't know what I don't know, and that's not a comforting place to be.

        I don't mean this to be insulting to the developer of RaspberryIO, but I don't have enough experience with the plugin to know what it will do in all circumstances. For example, I don't know if the outputs will unconditionally come up in a known state after a reboot, or what happens in a power failure that effects only the Raspberry Pi client. (A definite possibility, given that the HS3 computer is on a UPS and the RasPi isn't). It would probably spoil my day to discover that in some now-unknown uncommon circumstance the relay picks for a few milliseconds (seeing as how the garage door is connected to it). Only time and trying every "what if'" I can think of will give me the comfort level I need to trust it. I'll probably set up a test fixture driving HS3 that will count the number of relay activations over some period of time. Simply tying an output back to an input, and counting hits would do.

        Silly as it sounds, the potential for property loss isn't my biggest motivator for getting it right. We have an alarm system that reports to a central alarm dispatch office. If the alarm is tripped and I don't verify that it's a false alarm immediately, the Police are dispatched. After the first dispatch for a false alarm, the fines begin, and the costs go up RAPIDLY into the hundreds of dollars per incident. And, of course, I've already had my free lunch for this year!

        The GarageDoorBuddy sounds like a good solution. Unfortunately, Chamberlain, in their infinite wisdom, doesn't provide for a contact closure at the opener to operate the door. (I probably could use the GarageDoorBuddy contact closure to operate the remote. Hmmm. Food for thought.)

        Comment


          #5
          Originally posted by gls9009 View Post
          Thanks for your reply. Based on your comments, I looked a little further into the WPA2 situation, especially as it relates to the physical plant here, and it would probably be more difficult than usual to break WiFi in this particular instance. (In an area restricted from the general public, long password, etc.) I'm not normally inclined to paranoia, but as I said originally, I literally don't know what I don't know, and that's not a comforting place to be.

          The GarageDoorBuddy sounds like a good solution. Unfortunately, Chamberlain, in their infinite wisdom, doesn't provide for a contact closure at the opener to operate the door. (I probably could use the GarageDoorBuddy contact closure to operate the remote. Hmmm. Food for thought.)
          I have 13 of the garage door buddy units installed, at one location all of the gates/openers had (or could be added) a board with specific open/close contacts. Those where the easiest. The 4 remaining devices each door only had a contact that toggled, so some little work on the internal limit contacts gave me a way of in those cases having a 'toggle' button and a specific close button on the GDB (toggle went to the normal contacts, the close I had to rig of the limit switch). Point is, there may be contacts inside you can use, ultimately their control module is probably a relay (that said, utterly silly they would do that!)

          Comment


            #6
            Originally posted by spud View Post
            I agree that it is very unlikely that someone would try to open your garage door by figuring out the communication protocol between HS3 and the RaspberryIO plugin.

            That being said, to answer your question, the raspberry plugin communicates with HS3 like every other plugin (including local plugins). It uses the HomeSeer Communication Framework (HSCF.dll). I don't know much about it but It looks like it is derived version of this project https://github.com/hikalkan/scs, and I don't think it uses any encryption.
            You are correct on both points (non encrypted and the project used). That project is really designed for ipc for projects on box, albeit it will work okish for lan (I can't get a device enumerator remotely over wan, it now fails every time)

            Comment


              #7
              Unless something else has come along that I don't know about, the crack of WPA2 depends upon incorrect behavior of a client responding to a retry message with a 0 length key during connection negotiations and RPis and many access points have been patched for this (if updated properly) so your wifi traffic is probably safe.

              Sent from my SM-N950U using Tapatalk

              Comment


                #8
                Originally posted by spud View Post
                I agree that it is very unlikely that someone would try to open your garage door by figuring out the communication protocol between HS3 and the RaspberryIO plugin.

                That being said, to answer your question, the raspberry plugin communicates with HS3 like every other plugin (including local plugins). It uses the HomeSeer Communication Framework (HSCF.dll). I don't know much about it but It looks like it is derived version of this project https://github.com/hikalkan/scs, and I don't think it uses any encryption.
                Thanks for the info. I'll take a look at it, but as a later post mentions, if the WiFi vulnerability has been patched, I won't need to worry about encryption in the HSCF protocol. It would all be hidden anyway.

                Again, I want to make sure you understand that I'm not trying to insult you are your hard work. I guess a good corollary would be - If I went out and bought a brand new car, I wouldn't likely take it on a 3,000 mile trip on day one. I'd drive it locally for a bit just to make sure I knew what to expect, and to understand all of it's features. I guess you could say I'm in the "drive it a few days" mode now.

                Comment


                  #9
                  Originally posted by bsobel View Post

                  I have 13 of the garage door buddy units installed, at one location all of the gates/openers had (or could be added) a board with specific open/close contacts. Those where the easiest. The 4 remaining devices each door only had a contact that toggled, so some little work on the internal limit contacts gave me a way of in those cases having a 'toggle' button and a specific close button on the GDB (toggle went to the normal contacts, the close I had to rig of the limit switch). Point is, there may be contacts inside you can use, ultimately their control module is probably a relay (that said, utterly silly they would do that!)
                  I possibly could accomplish the same end result programmatically. I already monitor the door's current state via a magnetic contact on the door. So, I could do something like - To Open: Check the door state. If the door is closed, toggle the remote. Set a timer, and if the door state doesn't change after some amount of seconds toggle it again, etc. To Close the door, do something similar, but timer values would have to be tweaked to allow time for the door to completely close before testing for a change of state.

                  The lack of a contact closure is a pain, but I think I understand their reasoning. The wall controller is no longer a simple button. It's now a controller with an LCD display, time and temperature display, setup functions and a mess of other stuff, all fed by a single wire pair, that handles both power and communications. Basically you can rip out the old pushbutton controlled unit and replace it with the latest and greatest, without having to run new cables. When I installed mine it saved me a ton of wire pulling. (But I still wish it had a contact closure for control!)

                  Comment


                    #10
                    Originally posted by mitchmitchell1616 View Post
                    Unless something else has come along that I don't know about, the crack of WPA2 depends upon incorrect behavior of a client responding to a retry message with a 0 length key during connection negotiations and RPis and many access points have been patched for this (if updated properly) so your wifi traffic is probably safe.
                    Thanks for that. I just checked, and my units are running a version that has been patched. Same for the routers. I need to check some of the other devices around here, and update them as necessary. Thanks again.

                    Comment

                    Working...
                    X