Welcome to our community!

Ability to Approve newly installed unattended access devices before they are added

jeff weinman

3 years ago
updated 1 week ago
Pending Review

If installers get in the wrong hands, unknown unattended access devices are added. This could allow an adversary to gather information about a ScreenConnect instance to potentially attack it. Additionally, it's common to get rogue devices show up. When unattended access is installed, we would like the device to go into a holding position and need approval before it's fully accessible in the system. Our RMM does this and it works well. Ideally, there should be minimal communication with the agent while it's waiting for approval to avoid an adversary mapping things out.

Replies 2

Oldest first
Newest first Oldest first

Wardrop

2 weeks ago

We'd also appreciate this. Even though in theory a rogue machine shouldn't be able to "do anything" in our environment, what's to say some new exploit isn't discovered that these rogue sessions could exploit. Also, it'd be easy for an agent to inadvertently run a bulk command that includes one of these machines with potentially sensitive information, like a password.

I think a lot of admins would prefer that there would be an approval mechanism for new machines added via the unattended installer. Additionally, it'd be good to have a way to essentially invalidate all existing installer builds (i.e. rotate keys) that wouldn't affect existing sessions. Both of these would give admins a lot more peace of mind; both prevention and a remediation method.

Reply Link

michał gut

1 week ago

It's precisely my current problem - how to rotate keys without ruining existing clients. I want to get rid of rouge clients. I had to shut down my SC server as a precaution (i cannot be 100% sure that rouge client wont do anything malicious to host and other clients even if i wont join it). Adding networks to firewall works for one rouge and next day i have next one from different datacenter...

I have already a problem after changing address(domain) - removing old client removes both - new and old (one connecting to old address and other to new one).

Adding security features should be top priority at this moment.

FEATURE REQUEST: aside of accepting clients ALLOWLIST for clients on SC side.

Example and description of concept: Allowlist would allow us limiting client networks to known ip addresses or networks. Yes, it can be done on firewall side but on SC this could be more efective.

Unknown client connects to server - sends its ID, hostname, network address only. No other communication other than keep-alive.

If UnknownClient is on one of trusted networks (IP matches existing one already accepted) it can be aded automatically (suggestion: switchable option). Also existing accepted client IP could trigger whole network range of public addresses (switchable) to be treated as trusted.

If unknownclient is tagged by user as rouge and rejected: ban whole source network (to prevent next connect attempt as new client from similar ip)

Allowlist could allow normal connecting as usual for new instances of clients - such dynamic allowlist would prevent most of rouge client connections. Most of us have customers with known addresses or networks ranges.

Individual customers new clients or support connections can be on such waitlist.

This feature in SC will automate "firewalling" of relay. Rotating keys (for currently connected clients - two accepted keys for some peroid of time) would be good way to get rid of rouge clients if firewalling will fail, other SC 0day will occur or keys will leak.

Reply Link