Community

Security enhancements

Omega Supreme, User (Posts: 8)

Jan 11, 2018 3:07:11 pm EST

Viewer version: 6.8.0.1
Host version: 6.8.0.1
Server version: 2.6.0.3

I have some security related remarks/requests of which I am not really sure that they have been asked before (the forum doesn't have a search function). Instead of making a topic per item, I will sum them up in here. I am running a self hosted RU Server and this is the focus of my questions.

The pre-shared secret is currently used for weak authorization. I really would like to see that you use it for strong authorization as well. See points 1 and 4 below.

1. When the host doesn't have a pre-shared secret configured but the viewer has, then the connection is prohibited without any information presented to the user. Blocking the connection is ok from a security point of view, but I would like to have a message saying something like: "Connection aborted, because host doesn't have the pre-shared secret". In the current situation I am guessing what is the reason why I cannot connect (e.g. network issue, host down?).

2. I wonder if it would be possible to have the RU Server (service) running under a restricted account instead of the System account. In case of a security breach, severe consequences might be limited in this case. I didn't try for myself if it is possible, thought I would ask here first. So I would like to know if it is possible and if not, please explain further.

3. As far as I can see now it is possible for unknown hosts to join my (public accessible) RU Server. This is really unwanted and from a legal point of view I am not really sure if this could lead to problems. If you would work with pre-shared secrets for hosts and server, RU Server could block incoming connections that do not have the pre-shared secret. Of course this could be a bit annoying for hosts that are configured for first time use, but I think there are lot of alternatives outside the RU domain to (manually) provide the hosts system with the pre-shared secret.

4. If the host has a pre-shared configured and the viewer doesn't, the viewer still can access the host. While this might be useful in some cases, I would like to have the option in the host settings to deny the connection when a viewer doesn't have the pre-shared secret.

Edited:Omega Supreme - Jan 11, 2018 3:36:02 pm EST

Conrad, Support (Posts: 2991)

Jan 11, 2018 4:34:42 pm EST

Hello,

Thank you for your post.

I have some security related remarks/requests of which I am not really sure that they have been asked before (the forum doesn't have a search function).

You can search the forum using the search field on the blue bar above:

Security enhancements - 11 Jan 2018 04:02:54

Blocking the connection is ok from a security point of view, but I would like to have a message saying something like: "Connection aborted, because host doesn't have the pre-shared secret"..

This is a good point. We'll add a message in one of the subsequent updates.

I wonder if it would be possible to have the RU Server (service) running under a restricted account instead of the System account.

I'm not sure this is possible but I will forward this question to our developers nonetheless.

As far as I can see now it is possible for unknown hosts to join my (public accessible) RU Server.

For now - yes, it is possible. But it cannot lead to any breach or security problems by definition. The Host can only grant access, it cannot "get access".

If you would work with pre-shared secrets for hosts and server, RU Server could block incoming connections that do not have the pre-shared secret.

This won't solve the problem. The problem of unwanted Hosts connecting to RU Server originates from the fact that an admin/tech shares their Host package - e.g. puts it on a website for everyone to download as part of a support service. Any settings that you put in the Host then will be cloned on whichever machine it is run.

Still, we'll give more thought to how we can ensure no unwanted Hosts can connect to the server. A unique PIN or (as you suggested) a shared secret can work but only in some cases. It's not a 100% solution, unfortunately.

If the host has a pre-shared configured and the viewer doesn't, the viewer still can access the host. While this might be useful in some cases, I would like to have the option in the host settings to deny the connection when a viewer doesn't have the pre-shared secret.

A shared secret is not a means or another tier of authorization. It is a means of confirming the identity of the Host. That is, making sure that the Host wasn't replaced with another Host with the purpose of harvesting your password.

Therefore, if the corresponding connection in the Viewer doesn't have the shared secret field populated the program reasons that the user doesn't care about the identity of the Host and doesn't want to check it.

That said, in the upcoming version 6.9 we are adding 2-step verification (2FA) to the Host (uses Google Authenticator or similar app) . You'll be able to use that in order to strengthen your Host authorization.

Don't hesitate to ask me if you have other questions.

Conrad, Support (Posts: 2991)

Jan 12, 2018 4:51:48 am EST

Hello,

Update on this subject.

We are planning to remove the shared secret mechanism altogether in the next update. Instead, there'll be a certificate check and a warning if the Viewer cannot verify the certificate of the Host.

Next, about whether the server can work under a user account. In theory, this might be possible, but this will inevitably cause problems whenever the server needs to perform actions that require administrative privileges. Software like RU Server is supposed to run with full privileges. It is much better to devote time and resources to protect the server and the network in the first place, rather than resort to half-baked (and ineffective) solutions such as preventing programs from running with admin privileges when they are supposed to run with them.

Omega Supreme, User (Posts: 8)

Jan 12, 2018 5:23:01 pm EST

Support level: Free or trial

Hi Conrad,

Thank you for your answers! It is becoming rare these days for companies to actively take part of a community, so it is very much appreciated.

I think having a certificate check is more in line with the current standard in identification so that is good news. On the other hand, it might make things a little bit more complex for the average user. But of course a lot of stuff can be automated (e.g. generating and signing certificates).

I don't think having a service running under a restricted account is a half-baked or ineffective solution. On the contrary! If done properly it can dramatically reduce the consequences of a security breach. I am more familiar with the Linux domain and there it is very common that a daemon (= service) does not run under an account which has system wide privileges like for example the 'root' account. Granted, a lot of daemons start running under an account with elevated rights, but only for initialization purposes and when they are ready they drop to a restricted account. I come to know that on the Windows platform a lot of services are running under accounts that have system-wide privileges (e.g. Local System) and I think this is bad design from a security point of view. Of course the service must be designed to work under a restricted account, if not then I agree with you that it is a half-baked solution and you might run into problems sooner or later. But I want to stress that having a service running under a restricted account is really an additional security layer and is not something to be taken lightly. Especially when this service is accessible from the outside. Improving security is done by adding robust and tough layers on different levels in the system. I really hope you take this in consideration and have a look at this topic.

Thanks again for your time!

Conrad, Support (Posts: 2991)

Jan 14, 2018 4:01:24 am EST

Hello,

I think having a certificate check is more in line with the current standard in identification so that is good news.

Exactly. That was the reason why we implemented such identification.

On the other hand, it might make things a little bit more complex for the average user. But of course a lot of stuff can be automated (e.g. generating and signing certificates).

Nothing is required on the user part. The certificate is generated automatically, you cannot "disable" it. I.e. this system is always on - the user will only know that something is wrong when the Viewer cannot check the validity of the certificate.

Of course the service must be designed to work under a restricted account, if not then I agree with you that it is a half-baked solution and you might run into problems sooner or later.

You pinned it down :) The server is designed to work with full privileges.

But I want to stress that having a service running under a restricted account is really an additional security layer and is not something to be taken lightly. Especially when this service is accessible from the outside. Improving security is done by adding robust and tough layers on different levels in the system. I really hope you take this in consideration and have a look at this topic.

Thank you! We will definitely take note.

Don't hesitate to ask me if you have other questions.

Omega Supreme, User (Posts: 8)

Jan 15, 2018 4:36:33 am EST

Support level: Free or trial

Thank you for you reply Conrad, on a Sunday! :-) Really nice.

Ok, I am eagerly awaiting updates in the future. In the meantime I am a happy user of RU, considering to apply for a paid license and spreading the word about RU being a solid alternative for the competition.

Edited:Omega Supreme - Jan 15, 2018 5:32:13 am EST

Conrad, Support (Posts: 2991)

Jan 15, 2018 3:06:08 pm EST

You are welcome! And thank you for the kind words!

Submit a reply

^* Website time zone: America/New_York (UTC -4)