Agents "powershell.encryption

DavidH asked a question.

February 6, 2020 at 8:00 AM

Agents "powershell.encryption_key" setting

Hi,

We'd like to make use of the powershell.encryption_key setting in our agent configs. We have obtained the psencrypt.exe tool from Snow Support and encrypted our powershell script. It seems to work fine, the script has been encrypted and the agent can still execute it.

However, there is one big problem. After putting the powershell.encryption_key setting in our Agent config, the standard powershell scripts provided by Snow no longer work. So for example our Agent log says this:

ERROR; snowagent; powershell\powershellmanager.cpp; snow::win32::PowerShellManager::ExecuteScripts; Cannot run PowerShell script 'scan-agentcleanup.snow-ps1'.

ERROR; snowagent; powershell\powershellmanager.cpp; snow::win32::PowerShellManager::ExecuteScripts; Cannot run PowerShell script 'scan-autodesk.snow-ps1'.

ERROR; snowagent; powershell\powershellmanager.cpp; snow::win32::PowerShellManager::ExecuteScripts; Cannot run PowerShell script 'Scan-CustomRegistry.snow-ps1'.

ERROR; snowagent; powershell\powershellmanager.cpp; snow::win32::PowerShellManager::ExecuteScripts; Cannot run PowerShell script 'scan-msinfo.snow-ps1'.

ERROR; snowagent; powershell\powershellmanager.cpp; snow::win32::PowerShellManager::ExecuteScripts; Cannot run PowerShell script 'scan-swid.snow-ps1'.

ERROR; snowagent; powershell\powershellmanager.cpp; snow::win32::PowerShellManager::ExecuteScripts; Cannot run PowerShell script 'scan-toad.snow-ps1'.

Is that expected? If we use the psencrypt.exe tool does this mean we can no longer use any of the standard powershell scripts? Those scripts work fine without the powershell.encryption_key setting.

If you know the answer, please let me know. We'd like to encrypt our own scripts but also keep using the ones provided by Snow!

Thanks, David

DavidH
6 years ago
This is on the ideas board now: Thanks! David
Expand Post
- ThomasH
  6 years ago
  Hi Igor, are you able to comment on a possible solution to the problem already? (see Davids and my proposals). It actually just proofed to be a burden and workload for me (as a customer) AND for the snow support staff as well to get my hands on the unencrypted snow ps1 files. This is not an economical way to handle this and there really should be a solution in an 'automatic' way to avoid involving support for other task than sending over the tool and some documentation on how to use it. Best Regards Thomas
  Expand Post
  - Portal User
    6 years ago
    ‌ - I like your suggestion, I'll bring it in for the internal discussion! It may indeed be a good improvement to save us and you quite some time... perfect example how together we can make the product better for use and also improve the serviceability. Appreciate your input and will keep you updated with the status of this!
    Expand Post
    ThomasH
    6 years ago
    Hi Igor, just to let you know... I finally got my hands on pscencrypt.exe and snow's unencrypted ps1 files. According to the notes/doc i got alongside with the psencrypt.exe there seems to be no parameter to hand over the generated encryption key to the tool by using the command line, thus complicating automation. Taken from doc: ">...Enter the copied string 525...2DD as the key when asked by the tool. " What about to revise the tool to accept the key as a command line as well? E.g.: psencrypt.exe encrypt {input file} {output file} {key} If I use it this way, the tool currently just does nothing (not creating encrypted file, nor giving error or help at all). Or is there another (undocumented) way on how to hand over the key on command line? So all in all there is room for improvement... ;-)
    Expand Post
    DavidH
    6 years ago
    Hi , With powershell, I realised that you can just pipe the key into the psencrypt tool. For example, this is basically what I am doing in my build script: "YOUR_CUSTOM_KEY_GOES_HERE" | .\psencrypt.exe encrypt .\MyScript.ps1 MyEncryptedScript.snow-ps1 This means that you can automate the process of encrypting the scripts. In actual fact I am retrieving my key from somewhere else before piping it, so that the key does not appear in plain text in my build script. I hope that helps :-) David
    Expand Post
    DavidH
    6 years ago
    Hi , With powershell, I realised that you can just pipe the key into the psencrypt tool. For example, this is basically what I am doing in my build script: "YOUR_CUSTOM_KEY_GOES_HERE" | .\psencrypt.exe encrypt .\MyScript.ps1 MyEncryptedScript.snow-ps1 This means that you can automate the process of encrypting the scripts. In actual fact I am retrieving my key from somewhere else before piping it, so that the key does not appear in plain text in my build script. I hope that helps :-) David
    Expand Post
- Portal User
  6 years ago
  Hello and , I appreciate your thoughts and suggestions how to improve this feature. One of the key ideas behind using the custom encryption key with Powershell scripts is to ensure that only scripts encrypted with it are executed. This means that everything else encrypted with any other key, including the "default" scripts would not work. When developing this feature, we performed threat modeling and analysis and found out that keeping the default key for a fallback would negate most of the benefits of using custom encryption key by making it "optional" and still trying to decrypt scripts with the old default key. In our threat model, this old key that has been around for some time and is the same between different environments, has a low risk to be leaked and hence used by malicious parties to create their own scripts and impersonate snow-encrypted ones.To ensure this is not the case, we deliberately do not use the default key for the fallback. This allows organization to rely on their own key management and configuration management practices, implement key rotation and "expiration" (you can change the key at any point of time). As you correctly noticed, this feature requires requesting default Snow-ps1 scripts (4 scripts shipped with the default agent install) to be encrypted with the custom key. This can be done in two ways: 1. Request Snow support to encrypt them and provide them your key. I would not recommend it for high-security deployment since it exposes your key to us. However, if you have secure means of sharing the key string, it will work just fine. 2. Request unencrypted versions of the default scripts from Snow support and encrypt them in your own environment. Indeed, it adds work for yourself as well as Snow support every time the default scripts are updated. Luckily, these scripts are very stable are not updated often. Also, this is the cost of ensuring better security of the powershell script encryption at the agent side. What I can help with is clarifying with support that it is OK to share default scripts with customers using psencrypt.exe for custom encryption and also better outline how to encrypt default keys with your key if that is shared with support, and how to ensure the secure transfer. I hope this helps to resolve your issues or at least make the whole flow of requesting scripts more understandable. Thanks, and let me know if you have any questions! UPDATE 2020-03-09: after a thorough consideration, suggested option 2 was ruled out to protect Snow Intellectual Property. We will work on implementing Tom's suggestion that allows to encrypt standard snow-ps1 with custom key.
  Expand Post
  - ThomasH
    6 years ago
    Thank you for the clarification. So i clearly have to take back my harsh words about 'idiotic' - Sorry for that. Please take my apologies. I now understand the rationale behind. But then Support must clearly be aware of this and enabled to fulfill the resulting requests with a clear workflow. Still your solution puts a workload and burden to support and customer stuff to handle this. What about the following change! - Snow continues to deliver encrypted ps1 files which are encrypted by their own key. - if customer opts to use own key, he can encryt his own files with this key AND will encrypt the - already encrypted - snow ps1 files as well. (now snow files are double encrypted). - snow agent is using customer key to decrypt all files. If they are not 'cleartext' now (maybe some kind of check-able header in ps1 fiel is then a must, or agent knows because of a 'list' of snow-owned files ) agent will then try to decrypt the remaining encrypted files with snows own key. - if a custom key is used agent will refuse to run snows scripts - even if decrytpable by snows key - if not decrypted from the customer-key encrypted version before. This way your 'threat modeling' is still valid and obeyed but there is no need to request/exchange any keys or unencrypted files between snow support and customer staff and updated scripts by snow doesn't present a 'problem' any more.
    Expand Post
    DavidH
    6 years ago
    I have been thinking about this, and a good option would be to have the unencrypted ps1 files delivered by SUS to the script repository on our Snow Inventory Master Server (eg C:\ProgramData\SnowSoftware\Inventory\Resources\Powershell Scripts ). If the latest unencrypted scripts can be delivered automatically, then we can automate the process of encrypting them with our own key. Once that's set up there will be very little manual intervention. David
    Expand Post
    Portal User
    6 years ago
    Hi David, I updated the support instructions and also set up some internal deployment automation to make the scripts delivered to support for sharing when needed. As the next step, I will bring forward Thomas' suggestion of encrypting snow-ps1 once again with the custom key - this would save a lot of time and could be done only by releasing the agent fix without changing the workflows around the snow-ps1 scripts delivery. Would the described approach also work for your case?
    Expand Post

10 of 29