ZDI-23-1527 and ZDI-23-1528: The Potential Impact of Overly Permissive SAS Tokens on PC Manager Supply Chains

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: 

1. 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.
2. 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).
3. Anonymous Access. To determine whether the Storage Account is accessible anonymously, authentication-type can be leveraged. 
4. 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. 
5. Malicious IP. To determine whether known malicious IP addresses are accessing the Storage Account successfully, requester-ip-address can be leveraged.
6. 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.
7. 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)
•  

Read More HERE