none
Code Signing PowerShell - Trusted Publisher Security RRS feed

  • Question

  • Running a PowerShell script signed by a valid certificate that is not a Trusted Publisher results in a prompt to:

    • Never run [V] - Signing certificate gets added to the Untrusted publisher store
    • Do not run [D] - self evident
    • Run once [R] - the script isn't signed by a trusted publisher but run it any way ;)
    • Always run [A] - add the signing certificate to Trusted publisher store and run it ;)

    That is all well and good BUT is not secure unless the above prompt can either be disabled or a specific option mandated via Group Policy.  Even if a PowerShell Execution Policy of AllSigned is enforced via Group Policy, a user:

    • Can issue themselves a self-signed code signing certificate (a bit of rudimentary Googling will show how)
    • Sign any script
    • Use [A] in the subsequent PowerShell prompt to add the certificate to the user's Trusted Publisher store

    Have I missed something here or is this a pretty big weakness in PowerShell code signing security?



    Tuesday, November 27, 2018 1:10 AM

Answers

  • I can see your concern but neither code signing nor execution policy were intended to be a "security" feature. Execution policies are only intended for avoiding accidentally running a script and they can be outright bypassed during process creation (powershell.exe -ExecutionPolicy Bypass), and code signing is only good for knowing who generated the file and/or if it was tampered with.

    EDIT: The previously mentioned bypass is on process level and can be fought against by controlling execution policy via GPOs.

    • Marked as answer by Kym of Brisbane Wednesday, November 28, 2018 5:36 AM
    • Edited by A'ziz Tuesday, March 5, 2019 5:59 AM Amendment
    Tuesday, November 27, 2018 7:38 AM
  • Can PowerShell be restricted to only execute scripts signed by specific entities?

    No.

    Why? PowerShell's execution policy is an administrator safety feature, not a security feature.


    -- Bill Stewart [Bill_Stewart]

    Tuesday, November 27, 2018 4:30 PM
    Moderator

All replies

  • Is there a question?


    \_(ツ)_/


    • Edited by jrv Tuesday, November 27, 2018 1:43 AM
    Tuesday, November 27, 2018 1:42 AM
  • Is there a question?


    \_(ツ)_/


    Refer to the line ending with '?' ... as far as I am aware that is a question.
    Tuesday, November 27, 2018 2:53 AM
  • Then the answer is "yes". You missed asking a question.

    Are you asking if all of that that you posted is correct?  Have you tried it?  What errors do you get?


    \_(ツ)_/


    • Edited by jrv Tuesday, November 27, 2018 5:30 AM
    Tuesday, November 27, 2018 4:56 AM
  • You are an idiot, go away. 
    Tuesday, November 27, 2018 5:12 AM
  • It is not possible to understand what you are asking.  The code signing works as it is designed to work.  If a cert is valid and you want to always trust it PS allows you to save it in the cert store as a trusted certificate.  The same is true in IE and other Windows applications.  Some prompt and others require you to know you have to add the cert to the store.  Why is this an issue?  I all cases "trust" requires a human to make the final decision.  PowerShell makes it convenient to persist a chosen trust.


    \_(ツ)_/

    Tuesday, November 27, 2018 5:35 AM
  • I can see your concern but neither code signing nor execution policy were intended to be a "security" feature. Execution policies are only intended for avoiding accidentally running a script and they can be outright bypassed during process creation (powershell.exe -ExecutionPolicy Bypass), and code signing is only good for knowing who generated the file and/or if it was tampered with.

    EDIT: The previously mentioned bypass is on process level and can be fought against by controlling execution policy via GPOs.

    • Marked as answer by Kym of Brisbane Wednesday, November 28, 2018 5:36 AM
    • Edited by A'ziz Tuesday, March 5, 2019 5:59 AM Amendment
    Tuesday, November 27, 2018 7:38 AM
  • Can PowerShell be restricted to only execute scripts signed by specific entities?

    No.

    Why? PowerShell's execution policy is an administrator safety feature, not a security feature.


    -- Bill Stewart [Bill_Stewart]

    Tuesday, November 27, 2018 4:30 PM
    Moderator
  • PowerShell is in widespread use on enterprise IT infrastructures and, being such a powerful tool, it should not adopt such a security posture.  I think any addressing needs to occur within PowerShell itself given the emergence of PowerShell Core on various platforms.  Anyhow thanks Bill (and A'ziz) for the clarification and will mark as answered.

    Wednesday, November 28, 2018 5:36 AM
  • Your response seems to reveal a fundamental misunderstanding.

    Execution policy and script signing are not security features. They are administrator safety features.


    -- Bill Stewart [Bill_Stewart]

    Wednesday, November 28, 2018 3:02 PM
    Moderator
  • Code signing is a security feature.  Try Google.  Execution Policy should be a security feature but isn't.  End of discussion.
    Thursday, November 29, 2018 12:47 AM
  • Code signing is a security feature.  Try Google.  Execution Policy should be a security feature but isn't.  End of discussion.

    Code signing is used only to determine if code has been changed.  It does not prevent that code from doing bad things.  NO program or driver that is signed can prevent that code from being infected or run by the wrong people.

    Stubbornness is not a trait that work well with science or technology.  Just because you want the earth to be flat will not make it flat.


    \_(ツ)_/

    Thursday, November 29, 2018 12:53 AM
  • There still seems to be some misunderstanding, as the design of the execution policy precludes it from being a security feature.

    For example, there's nothing stopping you from doing the following:

    1. Open the signed script in an editor and copy the script code, minus the signature
    2. Paste the code into a separate script, making any changes
    3. Open PowerShell using -ExecutionPolicy Bypass
    4. Run the new, changed script


    -- Bill Stewart [Bill_Stewart]


    Thursday, November 29, 2018 6:16 PM
    Moderator
  • I have authored well over a million lines of PowerShell over the years and don't need lessons.

    Being a volunteer Moderator does not make your statements fact - further, being a moderator should not be a platform for pushing your own security barrow.

    You seem to misunderstand.  I know the design of the Execution Policy precludes it from being a security feature.  All I am saying is the design in 2018 is lacking.  The integrity and authenticity of operational scripts (those that are version-controlled, quality-tested by reviewers & code-signed by authorised Release Managers) should be able to be centrally enforced.


    Friday, November 30, 2018 12:17 AM
  • I have authored well over a million lines of PowerShell over the years and don't need lessons.

    Being a volunteer Moderator does not make your statements fact - further, being a moderator should not be a platform for pushing your own security barrow.

    You seem to misunderstand.  I know the design of the Execution Policy precludes it from being a security feature.  All I am saying is the design in 2018 is lacking.  The integrity and authenticity of operational scripts (those that are version-controlled, quality-tested by reviewers & code-signed by authorised Release Managers) should be able to be centrally enforced.


    No need for personal vendettas here. When your wrong just take it and be happy to learn something new.  Bill is only posting known information about PowerShell security.  If you have issues with this then contact Microsoft to lodge your complaint.

    ! million? Really?  I have been using PowerShell since before the first beta.  I don't believe I have written a million lines and I use PowerShell daily.


    \_(ツ)_/

    Friday, November 30, 2018 12:24 AM
  • Being a volunteer Moderator does not make your statements fact

    OK. Here's an authoritative source:

    Is setting ExecutionPolicy to Unrestricted for CurrentUser a security breach?

    Note the (correct) marked answer on that question. It was answered by Bruce Payette, one of the principal PowerShell language designers, who confirmed what I said in the last comment on the question.

    - further, being a moderator should not be a platform for pushing your own security barrow.

    My intent was not to antagonize but simply to explain what the purposes of code signing and execution policy are. The fact that you don't like the design won't change the design.


    -- Bill Stewart [Bill_Stewart]

    Friday, November 30, 2018 1:37 AM
    Moderator
  • There used to be a much more detailed statement from the PowerShell Team but I have not been able to find it.

    Overall code security is misleading.  The limit of security is the execution context which include the account rights and permissions.  With compiled code there is also CS (Code Access Security) which allows us to limit the "reach" of any API calls and to prevent unintentional side effects if code fails.  Even this doe snot provide "Security".  "Security" has been discussed widely in journals and by those who have made it a critical issue.  The sum total of all discussions is that the idea that any code or OS is secure is misleading. 

    PowerShell has never claimed to be secure. Since the beginning it has always said that it was "safer" than other scripting systems because of things like ExecutionPolicy and the CLR and its ability to sandbox unsafe code. This does not fix or ensure security but it is much safer than systems like VBS and Jscript.

    One day all techs will finally get their heads around the issue of security but it is a painful quest to get this to happen. I have been pushing security and safety in computing since the first free version or McAfee VirusScan (v1.0) when I saw a need for care.  It was very clear then that AV scanners were helpful but they did not absolutely address most issues of security.

    Today the biggest issues of system security are employees and users.  That is because of two major issues.  Employees steal and both employees and users fail to observe security rules.  The next big issue is techs who do not have a clear understanding of what computer security is or how to implement it.

    I am now dealing with the conversion of client system to MFA and, once again, users are moaning and complaining about how much of a headache this is.  We have no choice.    It is the first line of defense.  Has to be done.  Code will never be absolutely secure.

    I highly recommend that all techs should do one of the many seminars on computer security to set a baseline of understanding.  Errors in understanding are gateways to disaster. 


    \_(ツ)_/

    Friday, November 30, 2018 2:10 AM