RMM Guard - Approved Paths Clarification
in progress
N
Nathan
Wouldn't it make more sense to approve tooling based on hash vs "approved installation paths"? For example, a common method for TA is using a trojanized installer from a valid (compromised) source, and installing to a standard location on endpoint. If I approve the install location, then doesn't that open up a potential method for TA to drop into an "approved" location to bypass this tool?
J
Jon Sale
Would be nice if we could connect it to our RMM so that there is visibility into what is being deployed and ran from our RMM such as scripts or app updates to help with false positives.
E
Evan Swendsen
with Screen Connect specifically (and I'm sure this applies to other RMMs) there are instance values that they connect to. For supported RMMs I'd like to approve say Screen Connect for ONLY instance abcdefgxyz not all screen connects period.
Chris Bisnett
marked this post as
in progress
Chris Bisnett
I think this is a place where our UI doesn't give enough details. We always allow and block RMMs based on the signing certificate or the file hash for unsigned files. What that means is that if ScreenConnect is not allowed, we'll block it no matter where it's run from. But, if ScreenConnect is allowed, by default it could run from anywhere. This is how Application Control generally works. The problem with this approach, is as you pointed out, attackers can run ScreenConnect from anywhere (downloads, temp, etc.) and it would be allowed. So the question then becomes, how do we allow ScreenConnect, but only the one used by the customer?
Our answer to that is to have the customer specify the path where they install ScreenConnect. This way we can only allow ScreenConnect when run from that location and nowhere else. So we need the path where you install ScreenConnect so that we can use that for the allow. Our system will pick up the paths where we saw matching RMM binaries and will provide those as suggestions. If you install ScreenConnect there, then an attacker would have to overwrite ScreenConnect (which you can't on Windows if the executable is running) to be able to bypass the deny policy.
I'm going to update the Approve/Reject flow a bit anyway, but I'll make sure this is spelled out a bit better so that users understand what they are approving and how it works.
N
Nathan
Chris Bisnett I think the devil really is in the details here, and right now those details aren’t fully clear in the UI. Using ScreenConnect as the example: my expectation is that only the specific hash of my approved binary would be allowed to run. If that’s true, then I’m trying to understand why the install path needs to be part of the approval at all.
If the hash is the authoritative trust signal, then the path becomes a very weak indicator of compromise. An attacker with the ability to write to disk can drop a malicious binary into an “approved” folder just as easily as anywhere else. So approving a path feels like it introduces an unnecessary bypass vector unless the hash check is always enforced first and the path is only a secondary constraint.
Can you clarify whether the system enforces:
(certificate/hash) AND (path)
or
(path) OR (certificate/hash)
Because the security implications between those two models are very different.
Chris Bisnett
Nathan: The system enforces the signing certificate (or SHA256 file hash) AND the path.
We don't generally use the file hash because an update will break everything if the file changes. It's much easier to allow software signed by ConnectWise. This way when they update the file it continues to work and we can block that signing certificate if an attacker manages to get access to it to sign malware, but that's super rare.
The reason we need a path is because if we allow ScreenConnect by the signing certificate or even by file hash, if an attacker comes along with the same file or another file signed with the same signing certificate (like a different version of ScreenConnect), then the attackers ScreenConnect would pass the check and be allowed to run. We are trying to lock the system down so that only the intended ScreenConnect can run. To do this we create a policy that first matches that the file executing is ScreenConnect (either by signing cert or file hash) and then blocks it except if it matches the approved path. This way if you install all of your ScreenConnect instances to "C:\Program Files\ScreenConnect\", then the policy will see that it's ScreenConnect and that it's running from the intended path and will allow it. On the other hand if it sees ScreenConnect running, except the path looks like "C:\Users\bob\Downloads\" it won't match the approved path and will block it.
So the approved paths are places on the file system where we allow anything to run. It's solely there to be used in combination with the signing certificate or file hash to allow the specific RMM from it's intended install location.