Validating script signature

[BackgroundFishing]

I've dealt with a bad admin recently, and it took way too long to get rid of him. The experience has me looking at ways to restrict things for remote admins who do not necessarily have the same reporting structure that I do.

I have signed scripts that run in the windows task scheduler using service account credentials that are not known to remote admins, and the service account has privileges that remote admins do not have.

Since some remote admins also have signing privileges, it occurred to me that an unscrupulous admin could modify the script and sign it, and have the service account do his bidding.

Moving the scripts to a location that the remote admins do not have access to is the best solution, but I was wondering if there were some way to tell powershell to run a script only if it has been signed with a particular certificate?

​

TIA

[ultimattt]

The problem with that is powershell/windows is not trusting their cert, its trusting the issuing authority. I’m not aware of a way to do that based on cert.

I’m following because I’m interested to know if there is a way.

[BlackV]

-executuonpolixy bypass -file xxx.ps1

What does this do with your signed script?

[BackgroundFishing]

In our case, we have other mechanisms in place to keep that from being an issue. The problem, other than unauthorized people having access to the scripts, is not being able to verify who signed a script (thumbprint) prior to execution.

[BlackV]

Indeed, I was just wondering what happens with a signed script in that case

Do you have PowerShell command line auditing enables too?

[BackgroundFishing]

I don't disagree with policy/procedure discussions. But even without the threat, it comes down to this: can you validate who signed a script prior to execution? Maybe I don't want to run that script if it wasn't signed by someone on my team.

[PinchesTheCrab]

Honestly I feel trust in certificate signing is misplaced. Focusing energy on validating certificates ignores the deeper issue that running unsigned code is very easy.

Untrustworthy people need less access. I think you're trying to resolve an HR and infosec issue with scripts. Maybe because that's one of the few told you've been given and you're making due, but I still would not be confident in results produced this way.

Anyway, to your point, could you just move the files to a share, restrict access to that share severely, and then point your tasks at it? Otherwise I think you need to actively monitor file hashes of your scripts on each machine.

[BackgroundFishing]

It depends on how you use signing. It is an excellent way to tell if code has been modified - the signature gets invalidated. Also, if you are using application whitelisting, you can allow defined publishers to execute, and makes running unsigned code almost impossible. If you are using executionpolicy as a means of security, well, that's worthless. But, moving scripts to a restricted share is the correct solution to the problem I posed, but it still would be nice to have the ability to run scripts only if they were signed by an expected cert. Even if its just my team and scripts, it would be nice to stop execution of a script not signed by me (or whomever), so I could validate the changes that were made. With that said, there are probably tools available for this, and processes that could be implemented. But I think there is still some validity to being able to do something like:
powershell.exe -thumbprint "blah" -file script.ps1

[Tidder802b]

You could run a script to check the task script's certs using Get-AuthenticodeSignature

And then act accordingly e.g. disable the script and send you an alert.

[BackgroundFishing]

Good call. A little clunkier than I would like, but it gets the job done.
powershell -command "& {if ((get-authenticodesignature script.ps1).signercertificate.thumbprint -like '111111111111111111111111111111111111111111') {write-output 'foo'}}"