Require authentication on scripts

It would help me sleep much better if we had the ability to require authentication (Using the device credentials) when running scripts unless that script is assigned to a policy. Log Me In has this capability and it is amazing. If Syncro were to be compromised, this would give all of us another layer of security to prevent the bad guys from executing scripts on our client devices.

4 Likes

Yes, all kind of security features around scripts are needed!

I would like a second user to need to approve a new script.

There are lots of potential headaches with these changes, but it might contain a massive breach.

2 Likes

The ability to do this would be great, but I think it should be possible to bypass it as an admin user.

This might sound bad from a security perspective but:

  1. If you’re the admin, you could assign a script to a policy and bypass what you’re talking about anyway

  2. We don’t always have the device credentials. If the Syncro tech doesn’t have the credentials, they can escalate to an internal admin staff member to have the script run. This mitigates risk on normal-user accounts a lot, while still allowing support to actually do their job.

Of course, the problem of protecting the Syncro admin account remains very important here, and I’m still waiting in hope for Syncro to enable IP restrictions on admin accounts.

2 Likes

what is this you speak of about enabling MFA on admin accounts? All of our accounts admin or otherwise have MFA enabled. Are you saying there is a login flow that allows Admins to bypass MFA?

for Syncro catering to small MSPs they cannot just force all scripts to require double sign off, but they could possibly make it an option (that an admin could disable).

I’d like to see this all handled with script signing and a git integration. Let me use a git branch as my script repo and allow me to require all scripts have a valid signature, or even by signed by My signature in order for Syncro to run them. The people who want and will use these security features are either really technical small guys, or more likely the bigger MSPs who will want other stuff around their script management flow, like being able to have a code pipeline to run automated tests etc etc. stuff Syncro should not build but could make it easy to use.

3 Likes

Oops I meant IP restrictions, sorry! MFA is enabled on all of our accounts too, including admin, and works as intended. IP restrictions, on the other hand, are not available on admin accounts, and it’s been requested many times.

It’s nice to know I’m being read even when I’m wrong :slight_smile:
I edited the post but I can’t see how to do a strike through to show I made an error, oh well.

1 Like

I guess we can be considered really technical small guys but in all honesty, we’re just super paranoid. If Log Me In can require the script runner to authenticate using each devices’ local user and password, Syncro should be able to figure something out. Even if it is restricting scripts to only run from a defined IP. I am not too familiar with your suggestion but if it gives us the power to protect our clients and business, I am all for it.

Either way, I would hope this is a priority.

1 Like

by the time you all get it secure nothing will work. be like creating a building with no doors or windows and calling it secure. Although that may be true it is totally unusable.

LOL that would be about the most secure way to build a building for sure! May as well go full re-enforced Concrete with armor plating too, that way its extra expensive AND Maximum secure :+1::+1:

No, in reality we do not want the cost of the platform to blow up because of crazy engineering, and we don’t want the building to be unusable. We actually just want a Neighborhood appropriate (some neighborhoods steel bars on windows and multiple deadbolts are the norm, in other neighborhoods that would look really weird and overkill) building, with a few additional features that can be enabled if desired. Security rarely comes without additional end user friction, or complexity, so if you don’t need it, the stuff we’re talking about shouldn’t be on by default.

I think the end goal of most of these threads is that the platform should be designed in such a way that controls available w/in Syncro can prevent a Kaseya level platform compromise from becoming a customer environment compromise. And should play well with third party security tools like AV and Application Allow listing.

Yeah I’m pretty much right there with you. But as a rule I’m trying to move away from my team handling Credentials as much as possible, and we’re trying to automate resolving as many issues as possible. So for the majority of my use cases, rather than using point in time authentication for every script run, I’d prefer to have Strong controls around how scripts can get into Syncro in the first place, and ensure the code will not run if its modified at any point between when it was in a known good state and being run on the endpoint.

To my knowledge the best way to do this is via code signing (about Signing - PowerShell | Microsoft Docs). You have to protect the signing Key and the process by which code can be signed, but once the code is signed it can be validated all along the way and discarded if the code signing doesn’t check out. So in theory Syncro could check scripts when added to the platform, Syncro’s script runner could be set so all scripts run with execution policy set to “AllSigned” instead of bypass, and application allowlisting like Threatlocker or Applocker can be set to allow any script signed by my key, running from the correct path when executed by Syncro.

I would not lobby for this to be a default always on kind of setting but one that if enabled cannot be disabled without strong Identity verification like support calling me to verify I intended to disable it. Much like the way cloud vendors are handling “immutable” backup storage.

2 Likes

Just to be clear, the goal of this feature request is to add another layer of security in the event Syncro is breached. At the very least, give us the ability to generate a report showing what scripts have been ran over whatever time frame we choose.

1 Like

All for an added layer of security to be able to run scripts, AND better global reporting of scripts usage so we can audit globally what automation is doing.

My only hang up with the initial suggestion for additional auth is scale. Requiring device Credentials to effectively require scripts to Run As valid user on the endpoint (if it actually removes the ability for the agent or some users to run scripts as system) is an elegantly simple way to protect endpoints from a complete Syncro/User account compromise. In the case of the Kaseya attack there was a vuln that effectively allowed an “unauthenticated entity” to completely bypass any system user and schedule arbitrary scripts to run. If Syncro suffered a similar vuln, the additional layer of requiring an endpoint user account would only work if A) you could 100% prevent the system from running arbitrary scripts as system, which would break most of the sync jobs patch installs etc that Syncro does in the background. or B) have some sort of user keys that have to sign jobs for Syncro to process them, and this by itself if implemented correctly would entirely prevent a Kaseya style attack, and if there was any level at which stuff could be run in a way that the system would self-sign it, or it bypassed the check sig check, it could be circumvented anyway.
Ideally, I would like

  1. Strong verification that the user scheduling a script to run really is the user the system thinks they are.
  2. All scripting to be done in such a way that a third-party system, 100% disconnected from Syncro can validate all executables and code has been pre-approved.
  3. Globally accessible reporting to be able to see all scripts (including system) that ran by approver, job schedule, time/date range, device filter or company.
1 Like

Cybersecurity Tools, Application Whitelisting, Ringfencing | ThreatLocker Inc

yep, Threatlocker is a great tool, it’s a little tough to make it work with Syncro any way other than just whitelisting any ps1 run by Syncro that matches Syncro’s naming convention, (aka allow Syncro to run any script it wants to). This is one of the main focuses of my comments on this thread. The challenge with the way syncro does things is that it embeds all the runtime variables in the PS1 and then seems to generate the name off of the hash or something. At any rate if the content of the file is unique so is the name, if you push a script that has a different variable for every company you have to whitelist it for every company, if its unique for every computer, you basically have to just allow all scripts to run until the script run finishes.

Yeah this is a bit of a bummer. It would be “real nice” if syncro seperated the parameters from the scripts. Seems like it would be pretty trivial to drop a JSON file with the parameters in the same folder as the randomly generated PS1 and then just read the params from the script via powershell.

This might be considered overkill or micro manage, but I actually have started making an application and a policy out of every syncro script. A bit tedious but it also keeps me honest with version controlling my scripts. The web editor is super handy, but I build/troubleshoot most of my code in vscode (version control it locally once it works) then drop it into syncro and integrate any runtime or platform variables on testmachine1 (no threatlocker), version control it again once thats all working, and then i create an application and policy in threatlocker matching the script name, put testmachine 2 into learning mode and then deploy with whatever combination of variables needed to run the script. Then publish the polcy. If there are scripts with unique values per workstation, then let those get learned locally, if they are company wide, then learn locally and push upwards to the customer’s threatlocker group, and if the scripts do not apply to specific customers (most of mine) those get pushed up to the organization level so it applies to all clients. I realize thats a lot of work, but it helps me sleep at night :slight_smile: Security and convenience are mortal enemies.

that makes sense, I’m still working on getting TL rolled out so I don’t have every version of every script but I’m getting there.

I think that the “correct” answer with TL is to create a separate application policy for each script. I chatted with somebody who did this. Might take a while to get them setup but should be easy enough to manage once that hard work is done. I want to do this but haven’t taken any time to think about streamlining the process yet (100+ scripts = ugh).

No way. You get an auto-generated guid for each script, and you whitelist each specific script, which isn’t a big deal to do. You run it against a machine, it fails, you allow it, and voila, it works.

Then, even if someone got into your Syncro tenant and changed an existing script, the hash would be different and it wouldn’t run.

Yes, it’s more work.

Yeah I wish Syncro would provide the script variables in $env: vars it registry or something so that the each script only had one version. The problem is Syncro inserts the variables into a script, which changes the hash, and Syncro generates a guid for the name of each version of a single script so a script that pulls a variable from the asset will have to be allowed individually for EVERY asset.

If we’re still talking about Threatlocker, you can simply grab your computers all at once in the TL portal, switch them all to learning mode at once, wait a minute, then run the script against every asset, wait for it to finish, then turn the assets in TL back to secured. It’s not terribly difficult.

That said, I am with you that I would like to have built-in controls for scripts right in Syncro. I just made a separate feature suggestion that includes it to knock off CIS 2.7 compliance. I don’t want to manage TL on every asset… I like it on servers, but on endpoints it can be a bit much, management-wise. People say it runs itself…not really.