microsoft
Signing of winget binary for high security environment
Description of the new feature / enhancement
For WDAC hardened devices, winget can't be trusted as a managed installer. This means that the vast majority of functionality for deploying software and updates are useless due to the manual whitelisting overhead. Note that each of the following failures are also specific to every version and every application, making this not a scalable solution.
- The winget binary
- The installer exe / msi
- The files created during the installation process
- The final installed binaries to be used once the install / upgrade is complete.
For example, the following error when I attempt to install Wireshark. This corresponds to device guard / wdac blocking the installation.
Proof that winget exe is not digitally signed:
Without the signing, it is impossible to safely define as a managed installer. I have used the managed installer definitions here to trust a number of tools, including SCCM, the MEM endpoint manager, as well as third party utilities used within my organization.
The development of a policy usable to trust winget is documented, but is not currently viable, until signing is complete.
Proposed technical implementation details
At a minimum, the release process in the future should include signing the output binaries and any supporting DLL or script files.
There should also be a set of suggested policies to restrict what sources are trusted, etc along with a pre existing managed installer template specific to winget.
There are some wrong assumptions being made here.
This is how WDAC handles packaged apps: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/design/manage-packaged-apps-with-wdac
Also, you should not set Winget as managed installer, it would be a huge security risk. Why? because it doesn't need administrator privileges.
If a managed installer process runs in the context of a user with standard privileges, then it's possible that standard users or malware running as standard user may be able to circumvent the intent of your WDAC policies.
More info here: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/design/configure-authorized-apps-deployed-with-a-managed-installer
In the end, i suggest reviewing the documentations and changing your implementations/expectations to be secure and not create security loopholes.
By the way, Winget IS signed, it is done through the catalog. Security catalog signing is nothing new, it's used by Microsoft, Nvidia, Intel and many many companies.
Instead of signing every single file, you create a catalog that includes the hash of every file and then sign that catalog file to make the tamper proof. Windows will refer to the security catalogs to determine the signing status of files.
It uses Authenticode SHA256 hash. You can calculate those hashes using this command.
Learn more about catalog signing here:
-
https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/deployment/use-code-signing-for-better-control-and-protection
-
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/catalog-files
Very interesting topic, I think it's a perspective for the circle of trust in an environment, and of course for standard users and standard workstations, winget as managed installer is a very bad idea 🙂
But if you have DEV-Boxes/Workstations, where DEVs have adminrights or need at least, in more secure environments, with 3rd party Tools elevation of explicit processes, like Visual Studio or VS Code, instead of being a member of the local admin group, you could do this eventually also with ISG (which is not perfect either), but i think winget would also be interesting in this scenario. For example WinGet DSC (Desired State Configuration) for DEV Machines is amazing, i highly recommend it for this type of deployment, so winget as managed installer would be interesting if WDAC on a DEV-Box would be considered.
So looking forward that winget will be digitally signed (not the catalog/MSIX way as it is now) 🙂
Thanks to everyone on the responses here.
The managed installer functionality here might still be useful, if we can get an appropriate whitelist configuration in place for which packages are allowed to be pushed using winget. That's on a different team's radar so I haven't been keeping up with their progress. Having that in place is a mandatory prereq before we'd even consider using this at any kind of scale. The reasoning to consider a managed installer is avoiding having to whitelist every msix vendor in WDAC policy; I don't want to allow all msix for obvious reasons, and there shouldn't need to be a policy update every time they add a updater tool to their allow list. The managed installer functionality seems a good method for doing this if there are appropriate controls in place for which packages it is allowed to install.
I think the biggest point of my confusion on my part here is the fact that Get-AuthenticodeSignature appears to NOT behave the way that it's described (at least on 5.1).
The Get-AuthenticodeSignature cmdlet gets information about the Authenticode signature for a file or file content as a byte array. If the file is both embedded signed and Windows catalog signed, the Windows catalog signature is used. If the file is not signed, the information is retrieved, but the fields are blank.
The same is true for Get-SystemDriver, neither of them show the winget binary being signed. Even using Get-SystemDriver with -PathToCatRoot set to the appxmetadata folder it still doesn't show these binaries as installed.
I get the concept "you create a catalog that includes the hash of every file and then sign that catalog file to make the tamper proof. Windows will refer to the security catalogs to determine the signing status of files." However the two primary methods I'm using with WDAC straight up don't support it. Signtool works but that's yet something else that I'd have to push to the endpoints, then have to parse the output on.
C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.23.1911.0_x64__8wekyb3d8bbwe> signtool.exe verify /v /pa /c .\AppxMetadata\CodeIntegrity.cat .\winget.exe
File is signed in catalog: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.23.1911.0_x64__8wekyb3d8bbwe\AppxMetadata\CodeIntegrity.cat
Hash of file (sha1): 84672027A00332F402AC57231ECF218524E6BF7D
Signing Certificate Chain:
Issued to: Microsoft Root Certificate Authority 2011
Issued by: Microsoft Root Certificate Authority 2011
Expires: Sat Mar 22 18:13:04 2036
SHA1 hash: 8F43288AD272F3103B6FB1428485EA3014C0BCFE
....
@timbrigham-oc With Intune set as Managed Installer, any program pushed from Intune is automatically allowed. That's how secure environments do it and that's what works.
Winget can still be set as managed installer but it's not secure because of the reasons i mentioned such as not requiring Administrator privileges.
This isn't a problem with Winget, it's the way packaged apps work, their files are managed by a centralized file, including their signature. There are lots of benefits associated with it. For MSIX development, there are great articles out there on Microsoft Learn website and others. They lay out exactly how things work: https://learn.microsoft.com/en-us/windows/msix/package/signing-package-overview
The Get-AuthenticodeSignature is simply a general purpose function, a collection of codes that runs when you use that PowerShell function. That's not what Windows uses internally of course. Windows uses native APIs that properly inspect and retrieve the signature of every file, whether directly signed or signed by a security catalog. Again, there are documentations for them on Microsoft Learn: https://learn.microsoft.com/en-us/windows/win32/api/wintrust/nf-wintrust-winverifytrust
In this article Microsoft described how to do it: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/configure-authorized-apps-deployed-with-a-managed-installer
The New-AppLockerPolicy cmdlet mentioned in that article supports hash and file path, https://learn.microsoft.com/en-us/powershell/module/applocker/new-applockerpolicy?view=windowsserver2022-ps#-ruletype
File path is probably what would be suitable in your case, but remember it decreases security even more.
Any risks associated with this scenario is inevitably the responsibility of the architect of this scenario.