search

debauchee / barrier

Open-source KVM software
Other
27.19k stars 1.5k forks source link

Client authentication: what prevents a rogue client from connecting to a server and stealing the clipboard? #1204

Open jleproust opened 3 years ago

jleproust commented 3 years ago

Hello,

(I have searched the issues and wiki about this topic but found nothing, sorry if I missed something.)

I understand the server authentication using a certificate and private key, and checking the server fingerprint on the client, preventing man-in-the-middle attacks and stealing keystrokes.

But what prevents a rogue client from connecting to a server in the place of a known client? Obviously the user would find the connection to the legit client broken, but the rogue client could leave and let the legit one reconnect, and all the user could experience would be a slight lag when switching desktops. Meanwhile, the rogue client would have had the time to steal the server's clipboard content, leading a potentially serious confidentiality issue, if the clipboard contained data from a password manager for example.

What do you think? I have no proof of concept, but just launching the client from a rogue host on the same network would work the same as the legit client. I guess client certificates with trusted fingerprints on the server could mitigate this risk, and disabling clipboard-sharing works too obviously, but some other data that I don't know about may be at risk.

eldahl commented 3 years ago

if you are so paranoid you could setup a rule in your firewall, allowing only specific ips to access.

furkanmustafa commented 3 years ago

This is very far from being paranoid. An extremely minimal security expection.

I guess client certificates with trusted fingerprints on the server could mitigate this risk, and disabling clipboard-sharing works too obviously, but some other data that I don't know about may be at risk.

Server side confirmation of clients should suffice. A dialog like below.

A preconfigured list of trusted key fingerprints in config file could also be a convinient option.

lieryan commented 3 years ago

if you are so paranoid you could setup a rule in your firewall, allowing only specific ips to access.

That wouldn't really solve anything. I think the attack scenario here is users that the attackers are connected to the same network. This may be because you set up barrier server in a laptop and you brought this laptop to a coffee shop/hotel with public Wifi or to connect to work network, a rogue co-worker could steal keyboard inputs there if you don't shutdown the barrier server.

Additionally, in these scenarios, your laptop are usually going to be connected using dynamically allocated IP address, so you can't just whitelist an IP address in your firewall.

A proper security here can be achieved by using two-way/mutual authentication between client and server. If the server also has to approve the connected client's TLS fingerprint, then that would eliminate those attack scenarios above.

eldahl commented 3 years ago

Seeing that you would need to change the screenname to that of the targeted client, which you can't do in barrier, i would call this a bit paranoid. Then again i sometimes don't lock my car door when going shopping so you could call me careless...

Confirming clients on the server would be a nice feature though.

alectrocute commented 3 years ago

Then again i sometimes don't lock my car door when going shopping so you could call me careless...

I used to be this way. Used to be.