Security VS habridge

[stefan73]

habridge allows to execute scripts and programs on the hosting system. These scripts/programs are executed with root permissions. habridge also allows to add and test new configurations without any authentication to the system. i.e. habridge is a great tool but on the other hand exposes root to any user on the net. I guess there should be a password protection to the habridge configuration.

[bwssytems]

This is something that can be controlled by the user. As being open, it is a risk if you put items on it that could be an issue. This is something that should be noted.

[stefan73]

Can the user really control this? - I do not think so. The default config of a package should also not by default open up the root account to anyone.

Of course you may configure iptables to make sure that the habridge WebIF is only accessible by localhost. Then use a reverse proxy approach to get it channeled through Apache and add authentication. Such option sounds more like a work-around to me.

I can imagine two solutions:

1. Make a password mandatory for the habridge WebIF before one can set-up devices.
2. Eliminate the execute script/program option from habridge completely. It is much safer, if scripts get called by a webserver like apache / lighthttpd, where the user explicitly sets up e.g. a php script. The account running the script is also more appropriate then.

[pr3sidentspence]

Yikes, yeah. Maybe a third option could be only run scripts saved in a folder using a pick list or something? No entry of code in the web forms.

…

On Wed, Jan 25, 2017 at 3:07 AM stefan73 ***@***.***> wrote: Can the user really control this? - I do not think so. The default config of a package should also not by default open up the root account to anyone. Of course you may configure iptables to make sure that the habridge WebIF is only accessible by localhost. Then use a reverse proxy approach to get it channeled through Apache and add authentication. Such option sounds more like a work-around to me. I can imagine two options: 1. Make a password mandatory for the habridge WebIF before one can set-up devices. 2. Eliminate the execute script/program option from habridge completely. It is much safer, if scripts get called by a webserver like apache / lighthttpd, where the user explicitly sets up e.g. a php script. The account running the script is also more appropriate then. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#390 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AArbCYyQ6uwYrSfFtMfWBx4RBHV9W_Qvks5rVxC7gaJpZM4LtCOM> .

[bwssytems]

@stefan73 This is an application that is open to any one to use and configure. This type of application is inherently risky in security due to it's implementation. This also, allows some flexibility on how it operates. If people do not want to understand the risks, such as blindly opening ports from the internet and that if anyone that gets onto their internal network inappropriately, they should not run this software. Please feel free to fork this project and remove what you do not want until it can be added as a feature. Also, even if these features are added, this is still a risk as the Hue API is already inherently risky.
@pr3sidentspence Yes, you should never open this up to the internet. Even if you have a better router....

[pr3sidentspence]

A decade ago I did information security as a good chunk of my job, and although I should have seen the risk right away (open root access) I didn't. If I didn't, some others won't. I think I subconsciously assumed there was a password option I hadn't yet activated. Perhaps a prominent disclaimer outlining the risks on the page and readme are in order? Never allow access from the internet, never install on a local network where there are people you don't absolutely trust, etc. I was considering allowing access from 1 singular external IP, but won't now (even if I get a better router). I still appreciate the software and have donated, thanks for all your work, Mike

…

On Wed, Jan 25, 2017 at 8:52 AM BWS Systems ***@***.***> wrote: @stefan73 <https://github.com/stefan73> This is an application that is open to any one to use and configure. This type of application is inherently risky in security due to it's implementation. This also, allows some flexibility on how it operates. If people do not want to understand the risks, such as blindly opening ports from the internet and that if anyone that gets onto their internal network inappropriately, they should not run this software. Please feel free to fork this project and remove what you do not want until it can be added as a feature. Also, even if these features are added, this is still a risk as the Hue API is already inherently risky. @pr3sidentspence <https://github.com/pr3sidentspence> Yes, you should never open this up to the internet. Even if you have a better router.... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#390 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AArbCaSAUY8y9v3jFbhi1LTBv22mP7Utks5rV2G4gaJpZM4LtCOM> .

[bwssytems]

@pr3sidentspence Your idea of sequestering scripts or programs to a specific directory is what I will probably implement. So as long as a user doesn't give up the system in a script or a link to a program to run, it will be mitigated somewhat.

[stefan73]

The directory idea is great & simple. The solution though needs to make sure that oen can only call scripts/programs with parameters and not a chain of commands.
Thanks for considering.

[bwssytems]

This will be implemented with the security update.

[linuxkidd]

This could also be accomplished by:

• Setup reverse proxy using any web server ( lighttpd, nginx, apache, etc.. )
• Configure the reverse proxy to require user authentication
• Use iptables to block access to the default port 8080, or configure ha-bridge to listen for web only on localhost ( 127.x.x.x ).

Viola, secured access to ha-bridge web interface.

[bwssytems]

There will be multiple levels integrated. i.e. Secure just the user config portion, secure the api portion and also, secure only to registered user via "link button" ala hue. And there is some mix and match.