On Day 9 of cybersecurity awareness month, learn the best practices and recommendations to prevent security risks associated with Shared Access Signatures in Azure AD. Stay tuned for the upcoming blogs in our Cybersecurity blog series.
A few days back, Microsoft made a public disclosure that Microsoft AI researchers had exposed 38TB of private data through Microsoft’s AI GitHub repository. Customers who heard the news were stunned by Microsoft’s exploitation. However, MS asked their customers not to worry about this data exposure and stated that ‘No customer data was exposed, and they don’t want any additional security to use Microsoft 365 services’. Still, we all are curious about what data might be exposed and how they did it. Do you want to know? Let’s dive into the exploit.
As Kevin says,
The weakest link in the security chain is the human element.
– Kevin Mitnick
Microsoft’s data exploitation is due to the misconfiguration of shared access signature tokens in Azure by the AI research team. What actually happened is that the team usually shares the tutorial videos in their GitHub repository for learning the AI stuff. Instead of giving access to specific files in the Azure storage account, they misconfigured the permissions and accidentally gave access to the entire storage account along with the 38TB of private data, including passwords, sensitive data, and 30,000 internal Teams messages from Microsoft employees. Isn’t it harmful?
Now, let’s explore how shared access signature (SAS) tokens become vulnerable and how to overcome the security risks.
What is Shared Access Signatures?
A Shared Access Signature token is a signed URL used to delegate access to the Azure storage account with full access, read, write, list, or delete access permissions. This string of characters contains details about access permissions, validity, and more. Users can provide granular delegation to Azure resources. For example, they can grant access to either a single file, a container, or an entire storage account. By using a SAS token, you can decide how a client can access your data and for how long they can access the resources along with limited permissions.
Types of Shared Access Signatures
Azure storage (blob, files, queue, table, and disks) supports three types of shared access signatures that.
- User delegation SAS – It is generated and secured with Azure AD credentials, and it applies only to Blob storage.
- Service SAS – It is secured with a storage account key, and it applies to one of the Azure storage services like blob, queue, table, or Azure files.
- Account SAS – It is secured with a storage account key, and it applies to one or more of the Azure storage services.
SAS tokens can be in the below two forms.
- Ad hoc SAS: In this form, you can specify the start time, expiry time, and access permissions in the SAS URI.
- Service SAS with stored access policy: The stored access policy will be defined on a resource container such as blob, table, queue, or file share. It can be used to manage one or more service SAS, and the start time, expiry time, and permissions can be inherited from the stored access policy.
Note: Stored access policies are not supported for user delegation and account SAS. So, they must be in ad hoc form.
When Do Shared Access Signature Tokens Become Vulnerable?
Users can generate an SAS token for an Azure storage account from the Azure portal, PowerShell, Azure CLI, or any of the Azure Storage SDKs. Users append the SAS tokens to the URI, and it contains a set of query parameters to denote how the resources should be accessed by the client. It is signed with the key, namely, the user delegated key or storage account key (Shared Key). Let’s see the demerits of using SAS tokens, which makes them vulnerable.
- Anonymous sharing of resources: Although creating SAS tokens seems to grant secure access, they give access to anonymous users. For example, any user with a valid SAS token can access the delegated resources. Thus, it poses a risk of data exposure.
- Excessive Access Privileges: Users can grant full access, write, list, delete, or read access to an Azure Storage account, allowing them to delete files or even overwrite the existing files. It can lead to unwanted exposure of data in the wrong hands.
- Infinite SAS Token Expiration: Since the SAS token doesn’t have an expiration limit, organizations configure an expiry period with a very long time gap. Therefore, if an SAS token gets leaked, hackers may have enough time to inject any malicious files.
- No Audit Logging Availability for SAS Activities: As the SAS tokens are generated on the client side, admins cannot audit the SAS token generation, issuance, delegated permissions, or any other details. Thus, managing SAS tokens and preventing security vulnerabilities becomes difficult.
- No Revocation of SAS Tokens: There is no way to revoke a single SAS token, instead users need to revoke the entire account key. In this case, the other SAS tokens created using that key will also be revoked.
The cases mentioned above highlight the major disadvantages of using SAS, and there will be more when you dig deeper into it. Besides the advantages, admins need to understand how risky it is to use SAS in their Azure Storage accounts. Take a deep breath! No need to worry, as always, there will be bulletproof for every bullet!
Best Practices for SAS Token Security
For securing the Azure Storage resources, there are some guidelines that every organization must follow when using SAS tokens to share resources.
- It is always recommended to use HTTPS to create or distribute SAS tokens. Using HTTP might allow attackers to execute a man-in-the-middle attack and steal the token to access the resources.
- You can create a separate Azure Storage account for external access. Even if a user accidentally provides access to the entire storage account, it won’t expose any sensitive information.
- For better security, you should grant the least privileges as much as possible. Delegate access only to the required resources, along with the required permissions to perform actions on data. For example, don’t provide full access to the user who requires read-only access.
- Microsoft recommends organizations to use user delegation SAS whenever possible. As the user delegation SAS is secured with Azure AD credentials, it provides superior security and doesn’t require storing the account key.
- If you want to share resources for a minimal time, keep a shorter time interval for the expiration period when using ad hoc SAS, service SAS, or account SAS. Otherwise, you can consider using user delegation SAS, as the expiration period is limited to 7 days.
- While using service SAS, create a stored access policy as it has the convenience of revoking permissions for service SAS without requiring the regeneration of the storage account keys.
- If you want to specify a recommended interval for SAS tokens, you can configure a SAS expiration policy for the storage account. Thus, users can create SAS tokens with an expiration period that exceeds the recommended interval.
- To monitor SAS token usage, you must enable Azure Storage Analytics logs or use Azure Monitor, which provides details on SAS token access, signing key, and delegated permissions. Only active SAS tokens will be logged in Storage Analytics logs. Also, the authorization failure occurrences due to the outage of the SAS provider can be tracked.
- Try to use short-lived SAS as sometimes over-privileges can lead to a budget boost in the organization. If you provide excessive access to users, you need to pay additional costs if they unnecessarily upload data to Blob or download the files multiple times.
- Another helpful recommendation is that you should set the start time to 15 minutes past the current time to avoid failures in the SAS token generation due to the different time zones on different machines (i.e., clock skew).
- Also, try to avoid storing your SAS tokens in unencrypted files or sharing them over insecure platforms like email.
- You must monitor the active SAS token usage periodically and unusual activity pattern alerts triggered in your organization. Thus, you can identify and respond to potential security risks effectively.
- To avoid the usage of entire SAS tokens, you can disable SAS access for each storage account separately in the organization.
I hope this blog helps to understand the Microsoft exploit and the security risks involved in using the Shared Access Signatures in Azure AD. If you use SAS in your organization, follow the best practices and stay ahead in SAS security. If you find any other best practices, share them with us through the comment section. Happy securing!
