ZDI-23-1527 and ZDI-23-1528: The Potential Implication of Excessively Lenient SAS Tokens on PC Manager Supply Chains
Below are the comments from Microsoft for researchers interested in similar research endeavors:
- Breaching Microsoft Azure Bounty Rules of Engagement by utilizing tokens or credentials to access unauthorized data is prohibited.
- Researchers in the future can report a suspected overly-permissive SAS token directly to the bounty program without requiring the use of the Azure Storage Explorer tool to validate the token. The Microsoft Security Response Center will handle the necessary investigations regarding the impact and extent of the reported token on behalf of the submitter.
In contrast to the WinGet manifest InstallerUrl hijack, this method introduces a more forceful approach for executing a supply chain assault by altering the PC Manager releases from the official website pcmanager.microsoft.com.
This is exacerbated by the fact that certain versions of PC Manager have automatic updates enabled by default. Consequently, a malicious executable from an attacker could disguise itself as a legitimate executable that would be disseminated to all PC Manager installations, assuming the default configuration remains unaltered.
Notably, the MSI installers lack digital signatures since there were no certificates discovered in the storage account. However, assailants could still exploit implicit trust by utilizing ZIP files containing malicious scripts controlled by the attacker, binaries signed with leaked certificates, and other similar methods.
This matter was brought to the attention of Microsoft under the reference ZDI-23-1528.
Resolution
Upon being notified of our discoveries, Microsoft promptly replaced the overly permissive SAS token with a read-only SAS token. Subsequently, the links were substituted with the Microsoft App Store URL, effectively preventing the direct download of the binary. Furthermore, Microsoft eliminated the SAS token from the following GitHub pull requests.
Challenges
The generation of a SAS token occurs on the client’s side, where no Azure logs are created, leading to the creation of account and service SAS tokens from a shared access key. Consequently, if a Storage Account’s access key is compromised, an attacker can generate numerous overly permissive SAS tokens to maintain persistent access to the publicly accessible storage account. To render a SAS token invalid, the user must either leverage Stored Access Policies or opt to rotate the Storage Account’s access key. However, rotating the Access Key of the Storage Account will invalidate all the SAS tokens ever created.
Detection opportunities
To identify the utilization of SAS tokens for storage accounts, users can activate Azure Storage Analytics logs. Nevertheless, this may result in substantial additional costs depending on usage. Given that the sig signature field from the SAS token is not logged, users cannot directly discern the SAS token as-is. However, users can refer to the AuthenticationHash to identify which SAS token is currently in use. The logs could also be referenced to extract the following details when a storage account is being accessed using a SAS token. It’s important to note that these detection principles can aid defenders in initiating the development of queries tailored to their environments and tooling:
- Data extraction. Detect instances where abnormally large data volumes are being transferred to a known malicious or suspicious IP address by analyzing the response-packet-size.
- Excessive SAS Token Permissions. Check for indications that a Storage Account is being accessed by an overly permissive SAS token by examining if the request-url includes the sp parameter (SAS permission).
- Unauthenticated Access. Assess if the Storage Account is accessible anonymously by examining the authentication-type.
- File Classification. Identify if sensitive files are being retrieved from a suspicious IP address by analyzing the requested-object-key that contains file names. Based on patterns such as .env, password, config, secret, and auth, among others, heuristic detections can be established.
- Malware-related IP. Determine if known malicious IP addresses have successfully accessed the Storage Account by inspecting the requester-ip-address.
- Anonymous or SAS token requests. Identify the nature of requests – anonymous or using SAS tokens – by assessing if requester-account-name == ” and request-status == success.
- Suspicious User Agents. Spotting suspicious user agents can be achieved by examining the values of user-agent-header against a list of known suspicious user agents. Although user-agents might be altered by users, this step can help mitigate noise from internal operations.
To track down overly-permissive SAS tokens in code repositories, the described logic can be applied.
For service SAS tokens, concentrate solely on the URL parameters for SAS token detection, as the host may vary. From the URL parameters sv, se, sr, sp, sig, the crucial parameters to keep an eye on are:
Validation:
- sp (SAS token permissions) – check if the sp parameter value initiates with rw
- se (SAS token expiration) – confirm that the se parameter value corresponds to a time later than the current time
Identification:
- sig (HMAC-256 encoded signature)
- sv (SAS version)
- sr (resources accessible via SAS token)
For account SAS tokens, among the URL parameters sv, ss, srt, sp, se, st, spr, and sig, the pertinent parameters to look out for are:
Validation:
- sp (SAS token permissions) – confirm that the sp parameter value starts with rw
- se (SAS token expiration) – verify that the se parameter value corresponds to a time later than the current time
Identification:
- sv (storage version used for authorization request)
- ss (services accessible via SAS)
- srt (signed resource types accessible via SAS)
- sig (HMAC-256 encoded signature)
About Author
