Welcome to our community!

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

Avatar
jeff weinman
  • updated
  • 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 7
Avatar
0
Wardrop

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.

Avatar
0
michał gut

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.

Avatar
0
mattonz

Anyone got any good Session Group syntax for trying to find these for easy deletion?


Here's what I have so far based on the current 5 AV sandbox VM's that appeared in my environment...

SessionType = 2

AND GuestMachineDomain = 'WORKGROUP'

AND GuestTimezoneName <> 'My TimeZone'

AND HostConnectedCount = 0

Avatar
0
josh cross

I think it's going to depend on what your criteria are, but I have an automation that initiates a queueduninstall based on the following (omitted details in brackets):

Event.EventType = 'Connected' AND Connection.ProcessType = 'Guest' AND Session.SessionType = 'Access' AND ((Session.GuestMachineDomain <> '[Domain]') OR ( Session.GuestPrivateNetworkAddress NOT LIKE '[Address 1 with wildcard]' AND Session.GuestPrivateNetworkAddress NOT LIKE '[Address 2 with wildcard]' AND Session.GuestPrivateNetworkAddress NOT LIKE '[Address 3 with wildcard]'))

The 3 addresses are the only 3 approved internal address ranges for our use case.  Like I mentioned, your needs may be (likely are) different.  This still leaves the guest in ScreenConnect that needs to be manually deleted (so we can see that they initially tried to connect), but it successfully uninstalled the ScreenConnect client so they could no longer connect.  Ideally, the installer wouldn't be accessible without authenticating first, but that's not the option we have today.  

Avatar
0
josh cross
Quote from josh cross

I think it's going to depend on what your criteria are, but I have an automation that initiates a queueduninstall based on the following (omitted details in brackets):

Event.EventType = 'Connected' AND Connection.ProcessType = 'Guest' AND Session.SessionType = 'Access' AND ((Session.GuestMachineDomain <> '[Domain]') OR ( Session.GuestPrivateNetworkAddress NOT LIKE '[Address 1 with wildcard]' AND Session.GuestPrivateNetworkAddress NOT LIKE '[Address 2 with wildcard]' AND Session.GuestPrivateNetworkAddress NOT LIKE '[Address 3 with wildcard]'))

The 3 addresses are the only 3 approved internal address ranges for our use case.  Like I mentioned, your needs may be (likely are) different.  This still leaves the guest in ScreenConnect that needs to be manually deleted (so we can see that they initially tried to connect), but it successfully uninstalled the ScreenConnect client so they could no longer connect.  Ideally, the installer wouldn't be accessible without authenticating first, but that's not the option we have today.  

It appears that this filter isn't operating as envisioned.  I'm sure there's something I'm missing, and if you see it I'd appreciate your feedback.  Please don't use.

Avatar
0
mattonz

Thanks Josh

All good, probably some syntax.  I wouldn't use IP ranges myself as we'll have Laptops out and about in the world.  I suspect isn't our DOMAIN is going to be enough to catch 99% but as per John's original post, it's concerning as the other end is obivously now part of secure channel of comms between Client and Server and exploits could be discovered...

Hopefully ConnectWise work on restricting access to installers in the future / rework the way clients get installed and updated...

Avatar
0
josh cross
Quote from mattonz

Thanks Josh

All good, probably some syntax.  I wouldn't use IP ranges myself as we'll have Laptops out and about in the world.  I suspect isn't our DOMAIN is going to be enough to catch 99% but as per John's original post, it's concerning as the other end is obivously now part of secure channel of comms between Client and Server and exploits could be discovered...

Hopefully ConnectWise work on restricting access to installers in the future / rework the way clients get installed and updated...

Hi mattonz,

The domain takes care of 99% of what we need as well, but we do have a couple of devices that are not domain joined for various reasons, but are on one of the "trusted" networks.  For this reason, we want this automation to run on anything that is not a member of the domain, or are not on one of the "trusted" networks.  The devices that are roaming about are a member of the domain, so that should take care of those.  I believe I've found my logic issue, but I'm doing further testing to make sure.  


Customer support portal powered by UserEcho