ZDI-23-1527 and ZDI-23-1528: The Potential Impact of Overly Permissive SAS Tokens on PC Manager Supply Chains
In ZDI-23-1527 and ZDI-23-1528 we uncover two possible scenarios where attackers could have compromised the Microsoft PC Manager supply chain.
Save to Folio
Summary:
- This blog explores two possible scenarios where PC Manager releases could have been hijacked by attackers via WinGet repository, 'aka.ms' URLs, and an official subdomain of Microsoft, due to overly permissive SAS tokens.
- If an attack had been carried out, cybercriminals could have compromised software supply chains for distribution of malware, allowed them to replace software releases, and alter distributed PC Manager executables.
- These issues detailed in this blog have been reported to Microsoft and have since been resolved. This blog details recommendations on how to avoid similar potential compromises.
- This blog entry documents the outcome of security research conducted in 2023. Microsoft has since provided additional guidance and updates to the rules of engagement of the Azure Bounty Program. This blog is for educational purposes only.
In this blog entry, we look at overly permissive cloud service credentials in Microsoft’s public-facing assets and assess their potential implications on software supply chain and software integrity. We do this by exploring two scenarios involving PC Manager, a tool designed to help optimize and manage Windows computers. PC Manager includes features for cleaning up temporary files, managing startup programs, monitoring system health, and improving overall performance, and aims to provide users with a straightforward method for maintaining their machine’s efficiency and security.
The two scenarios we explore include one related to the official PC Manager website, and another to the WinGet package manager. Both instances involve overly permissive shared access signature (SAS) tokens which, if abused, could allow unauthorized modifications to PC Manager releases. These unauthorized modifications can be used to impact trust in the software distribution process, thereby posing a risk to users relying on open-source package managers and officially trusted resources. Note that these issues have since been reported to Microsoft and resolved.
To help address the challenges that this blog will present, we will also share detection and hunting strategies that defenders can build upon to identify overly permissive SAS tokens. This blog highlights the importance of securing cloud credentials to protect software integrity and the broader software supply chain, particularly in environments where cloud services are used for software distribution via official and open-source channels.
This blog entry documents the outcome of security research conducted in 2023. Microsoft has since provided additional guidance and updates to the rules of engagement of the Azure Bounty Program. Tools and techniques documented in this blog may now be prohibited by the latest bounty rules of engagements. We recommend familiarizing yourself with the latest rules of engagement outlined in the Microsoft Bug Bounty Program prior to conducting similar security research. It should be noted that this blog is for educational purposes only. Trend Micro does not condone unethical or illegal activities.
ZDI-23-1527: Hijacking PC Manager via WinGet packages
WinGet is a package manager built for Windows OS that allows a user to install WinGet packages using the WinGet CLI. Package definitions are well-defined in the Windows manifest, while YAML files can be found in the GitHub repository microsoft/winget-pkgs. Figure 1 shows the manifest for Microsoft PC Manager from September 2023. Figure 2 shows that the WinGet package manifest schema is well-defined in Microsoft’s official documentation.
In the WinGet manifest of PC Manager, the value of InstallerUrl can be seen as follows:
https://pcmanager.officeplus.cn/mvp/10000/54247/MSPCManagerOffline_20230918.54247.exe?sv=2021-10-04&se=2024-03-16T09:17:53Z&sr=c&sp=rwdl&sig=qIe380lbv19nAKzFkC1EBBLzQzhtuZwG/M1uyHLCItc=
When a user tries to install the package named Microsoft.PCManager.CN, the WinGet CLI will fetch this manifest and parse the different fields. Then, based on the value of InstallerUrl, it will download and run the executable if InstallerSha256 matches.
Note the URL parameters, which are part of a shared access signature (SAS) token. SAS tokens are signed URLs that help delegate access to the Azure Storage Account along with optional parameters to specify the supported IP address or address range from which requests can originate, the supported protocol with which a request can be made, or an optional access policy identifier that's associated with the request. There are three types of SAS tokens:
- User delegation SAS - secured with Microsoft Entra ID credentials, with a max validity of seven days
- Service SAS – secured with an Account Key, with a max validity of 9,999 years
- Account SAS – secured with an Account Key, with a max validity of 9,999 years
Resource:
https://pcmanager.officeplus.cn/mvp/10000/54247/MSPCManagerOffline_20230918.54247.exe
SAS token:
sv=2021-10-04&se=2024-03-16T09:17:53Z&sr=c&sp=rwdl&sig=qle380lbv19nAKzFkC1EBBLzQzhtuZwG/M1uyHLCItc=
SAS token URL parameters are well-defined in the official documentation. The SAS token in the WinGet repository as shown in the code above is a service SAS token with the following properties:
| Parameter | Value | Details |
| sv | 2021-10-04 | This field contains the service version of the shared access signature. This value specifies the version of Shared Key authorization that's used by this shared access signature (in the signature field). It also specifies the service version for requests that are made with this shared access signature. |
| se | 2024-03-16T09:17:53Z | The time when the shared access signature becomes invalid, expressed in one of the accepted ISO 8601 UTC formats (in this case, being March 16, 2024). |
| sr | c | The resources are accessible using the token. In this instance, access is granted to the content and metadata of any blob in the container. |
| sp | rwdl | The permissions that are associated with the shared access signature. The user is restricted to operations that are allowed by the permissions. The token grants permissions to read, write, delete, and list on the containers and its blobs |
| sig | qIe380lbv19nAKzFkC1EBBLzQzhtuZwG/M1uyHLCItc= | The signature is a hash-based message authentication code (HMAC) that's computed over a string-to-sign and key by using the SHA256 algorithm and then encoded by using Base-64 encoding. The key is the Storage Account’s Access Key for account and service SAS tokens |
Table 1. Properties of the service SAS token
Given the SAS token’s privilege and validity at the time of discovery, we were able to find the Storage Account that was being used to fetch the PC Manager executable. The UriPath key in the error message below shows a storage account named distributestorage in the Azure China region (based on the host value blob.core.chinacloudapi.cn).
With the storage account hostname and the SAS token at hand, an attacker could use the Azure Storage Explorer or AzCopy tool to verify the read, write, delete, list operations granted by the SAS token.
At this point we would like it to be noted that Trend Research staff follow strict guidelines when conducting research. In the investigation of this issue, we made no unauthorized modification to the data that is not wholly our own. Throughout the investigation, we worked closely with Microsoft to determine the impact of our findings and address this issue.
Microsoft has provided the following comments for researchers who wish to conduct similar research in the future:
- Using tokens or credentials to access data that is not your own is a violation of Microsoft Azure Bounty Rules of Engagement.
- Future researchers may simply report a suspected overly-permissive SAS token to the bounty program without using the Azure Storage Explorer tool to verify the validity of the token. The Microsoft Security Response Center will perform necessary investigations to determine the impact and scope of the reported token on behalf of the submitter.
We found that the size of the container mvp was 358 GiB (or 384 GB). Based on our analysis, the accessible container potentially contained multiple releases of Microsoft PC Manager.
The earliest GitHub pull request containing an overly permissive SAS token was on November 4, 2022. Through November 2022 to September 2023, an unauthorized attacker could have potentially modified all releases of Microsoft PC Manager stored on the storage account.
However, in this case, the WinGet CLI would still prompt the user with a message stating that the SHA256 hash of the installer does not match the file downloaded from the storage account. While this would normally raise suspicion, implicit trust could play a part and the user might still opt to proceed with the execution of the attacker-controlled executable since it is delivered by a trusted entity, which in this case is the WinGet manifest.
We reported this issue to Microsoft as ZDI-23-1527.
ZDI-23-1528: Hijacking PC Manager via pcmanager.microsoft.com
While doing further analysis on PC Manager, we saw the tool mentioned in numerous blogs, YouTube videos, and official Microsoft forums as a substitute for users without WinGet. Mentions of PC Manager said it could still be installed from pcmanager.microsoft.com, a legitimate subdomain owned by Microsoft. This, apart from two other official ways to install PC Manager: via the Microsoft App Store, and via WinGet CLI as a WinGet package.
While inspecting how the executable is downloaded from pcmanager.microsoft.com, we observed an interesting flow:
When users click on the download button, it redirects them to aka.ms/PCManager500000. aka.ms is Microsoft's official link shortener, designed to create short, easily shareable links that redirect users to longer or more complex URLs. This link shortener is widely used for Microsoft services, products, and resources, making it convenient for sharing links in emails, presentations, or on social media.
We found these aka.ms URLs on the Microsoft support forums for PC Manager. The final URL from which the executable is downloaded is found below:
https://pcmdistributestorage.blob.core.windows.net/mvp/500000/52752/MSPCManagerSetup.exe?sv=2021-10-04&se=2024-03-06T05%3A53%3A27Z&sr=c&sp=rwdl&sig=m4niDUHZxUz%2BZnSvzuebFIl0EINy5xZL87nolDEHZIQ%3D
In this case, we have a different SAS token being used with a different storage account. The SAS token has the following details:
- It has an expiry value of 6th March 2024
- It allows container and object-level API operations
- Its permissions allow for “rwdl” (read, write, delete, list) operations.
Using the overly permissive SAS token, we were able to gain read, write, delete, list access to the container named ‘mvp’ and the blobs on the storage account named pcmdistributestorage in Azure Global. Furthermore, we found that the size of the container mvp was 118 GiB (or 126.7 GBs), which potentially consists of multiple releases of Microsoft PC Manager that were being distributed via pcmanager.microsoft.com.
Microsoft has provided the following comments for researchers who wish to conduct similar research in the future:
- Using tokens or credentials to access data that is not your own is a violation of Microsoft Azure Bounty Rules of Engagement.
- Future researchers may simply report a suspected overly-permissive SAS token to the bounty program without using the Azure Storage Explorer tool to verify the validity of the token. The Microsoft Security Response Center will perform necessary investigations to determine the impact and scope of the reported token on behalf of the submitter.
Unlike the WinGet manifest InstallerUrl hijack, this technique presents a more impactful method for conducting a supply chain attack by modifying the PC Manager releases from the official website pcmanager.microsoft.com.
This is compounded by the fact that in certain releases of PC Manager, auto updates are enabled by default. Therefore, an attacker’s malicious executable could potentially masquerade as an executable that would be propagated to every single installation of PC Manager, given its default configuration is unchanged.
However, it is important to note that the MSI installers would not be digitally signed as there were no certificates found in the storage account. Nevertheless, attackers could still abuse implicit trust by using ZIP files containing attacker-controlled malicious scripts, binaries signed with leaked certificates, and so on.
This issue was reported to Microsoft as ZDI-23-1528.
Resolution
After we reported our findings to Microsoft, they initially changed the overly permissive SAS token with a read-only SAS token. Later, the links were replaced with the Microsoft App Store URL, thus preventing the direct download of the binary. As for the WinGet manifests, Microsoft removed the SAS token in the following GitHub pull requests.
Challenges
The creation of a SAS token happens on the client’s end, where there are no Azure logs generated, and so account and service SAS tokens are generated from a shared access key. Hence, if a Storage Account’s access key is leaked, an attacker can create numerous overly permissive SAS tokens and use them to maintain persistent access to the publicly reachable storage account. To invalidate a SAS token, the user must either use Stored Access Policies or rotate the Storage Account’s access key. However, rotating the Storage Account’s Access Key invalidates all the SAS tokens ever generated.
Detection opportunities
To detect the use of SAS tokens for storage accounts, users can enable Azure Storage Analytics logs. However, depending on usage, this can come at a significant additional cost. Users cannot infer the SAS token as-is since the sig signature field from the SAS token is not logged. However, users can leverage AuthenticationHash to find which SAS token is being used. The logs could also be leveraged to gather the following information when a storage account is accessed using a SAS token. Note that these detection ideas can help defenders get started to build queries for their environments and tooling:
- Data Exfiltration. To detect when abnormally large amounts of data being exfiltrated to a known malicious or suspicious IP address, response-packet-size can be leveraged.
- Overly Permissive SAS Token. To check whether a Storage Account is being requested by an overly permissive SAS token, request-url contains the sp parameter (SAS permission).
- Anonymous Access. To determine whether the Storage Account is accessible anonymously, authentication-type can be leveraged.
- File Name Heuristics. To determine whether sensitive files are being accessed from a known-bad IP address, requested-object-key contains the name of the file being requested. Based on patterns such as .env, password, config, secret, and auth, among others, heuristic detections can be built.
- Malicious IP. To determine whether known malicious IP addresses are accessing the Storage Account successfully, requester-ip-address can be leveraged.
- Anonymous or SAS token requests. To determine if there are anonymous or SAS token requests, requester-account-name == '' and request-status == success can be leveraged.
- Suspicious User Agents. To detect suspicious user agents, user-agent-header values in a list of known suspicious user agents. Although user-agents can be morphed by the user, this can still help to reduce noise from internal environments.
To hunt for overly-permissive SAS tokens in codebases, the logic listed below can be used.
For service SAS tokens, only check the URL parameters for detecting SAS tokens, as the host could be different. Of the URL parameters sv, se, sr, sp, sig, the important parameters to look out for are:
Check value:
- sp (permissions of the SAS token) – the value of sp parameter starts with rw
- se (expiry of the SAS token) – the value of se parameter is sometime later than the current time
Check existence:
- sig (HMAC-256 encoded signature)
- sv (version of the SAS)
- sr (resources the SAS token delegates access to)
For account SAS tokens, of the URL parameters sv, ss, srt, sp, se, st, spr, and sig, the important parameters to look out for are:
Check value:
- sp (permissions of the SAS token) - the value of sp parameter starts with rw
- se (expiry of the SAS token) – the value of se parameter is sometime later than the current time
Check existence:
- sv (storage version used to request authorization)
- ss (services accessible using the SAS)
- srt (signed resource types that are accessible using the SAS)
- sig (HMAC-256 encoded signature)
Trend solutions
Trend Vision One™ Cloud Risk Management is a continuous assurance tool that provides peace of mind for cloud infrastructure, delivering over 750 automated best practice checks. Cloud Risk Management users can leverage the following Azure Storage Account rules:
- Allow Shared Access Signature Tokens Over HTTPS Only ensures that SAS tokens are allowed only over the HTTPS protocol.
- Check for Overly Permissive Stored Access Policies ensures that Azure Storage SAS tokens are not using overly permissive access policies.
- Check for Publicly Accessible Web Containers ensure that Azure Storage containers created to host static websites aren't publicly accessible.
- Disable Anonymous Access to Blob Containers ensures that anonymous access to blob containers is disabled within the Azure Storage account.
- Disable Public Access to Storage Accounts with Blob Containers ensures that public access to blob containers is disabled for Azure storage accounts to override any ACL configurations allowing access.
- Enable Immutable Blob Storage ensures that critical Azure Blob Storage data is protected from accidental deletion or modification.
- Enable Logging for Azure Storage Blob Service ensures that storage logging is enabled for the Azure Storage Blob service.
- Enable Logging for Azure Storage Queue Service ensures that detailed storage logging is enabled for the Azure Storage Queue service.
- Enable Logging for Azure Storage Table Service ensures that storage logging is enabled for the Azure Storage Table service.
- Enable Secure Transfer in Azure Storage ensures that the "Secure transfer required" security feature is enabled within the Azure Storage account configuration.
- Expire Shared Access Signature Tokens ensure that your SAS tokens expire within an hour.
- Limit Storage Account Access by IP Address ensures that Azure Storage account access is limited only to specific IP addresses.
Conclusion
Credentials in URL parameters are a known issue (such as CWE-598); be it a JWT for a Jupyter notebook or a SAS token, as we observed in this article, and there are many tools used by DevSecOps teams such as GitLeaks and Trufflehog to scan for and provide alerts when credentials are found in CI/CD pipelines. Misconfigurations consisting of lesser-known credentials may happen, even from cloud providers themselves. This issue can be preempted if there are proactive processes in place to scan code for overly permissive cloud service credentials.
Since these tokens are URL parameters that serve as an authorization context, it will not be difficult to craft a regex expression to search for it in codebases. However, it is also important to note that HTTP proxy logs may contain these tokens in cleartext.
Abuse of leaked SAS tokens is not new; researchers from NotSoSecure explored the risks back in 2019. In June 2023, Microsoft remediated a 38 TB data exposure incident consisting of employee backups and AI research artifacts that happened due to an overly permissive SAS token.
We strongly emphasize the following best practices while using SAS tokens as outlined by Microsoft:
- Apply the principle of least privilege. Scope SAS URLs to the smallest set of resources required by clients (e.g., a single blob), and limit permissions to only those needed by the application (e.g., read-only, write-only).
- Use short-lived SAS tokens. Always use a near-term expiration time when creating a SAS, and have clients request new SAS URLs when needed. Azure Storage recommends 1 hour or less for all SAS URLs.
- Handle SAS tokens carefully. SAS URLs grant access to data and should be treated as an application secret. Only expose SAS URLs to clients who need access to a storage account.
- Ensure that there is a revocation plan. Associate SAS tokens with a Stored Access Policy for fine-grained revocation of a SAS within a container. Be ready to remove the Stored Access Policy or rotate Storage Account Keys if a SAS or Shared Key is leaked.
- Monitor and audit applications. Track how requests to storage accounts are authorized by enabling Azure Monitor and Azure Storage Logs. Use an SAS Expiration Policy to detect clients using long-lived SAS URLs.