Summary Summary

Azure provides developers and security operations staff a wide array of configurable security options to meet organizational needs. Throughout the software development lifecycle, it is important for customers to understand the shared responsibility model, as well as be familiar with various security best practices. This is particularly important in deploying Azure Functions and in provisioning Azure Role Based Access Control as customers are responsible for configuring and managing applications, identity, and data. It is possible for customers to grant overly broad permissions. When this happens, there is a risk that these permissions could be abused to gain access to additional resources within a customer’s tenant. One such issue was recently reported by Orca Security and investigated by the Microsoft Security Response Center who determined it was not a security issue. However, the situation warranted discussion and improvement to help customers more effectively deploy environments with least privilege and defense-in-depth to be more resilient against attackers.

As part of ongoing experience improvements, the Azure Functions team plans to update how Functions client tools work with storage accounts. This includes changes to better support scenarios using identity. After identity-based connections for AzureWebJobsStorage are generally available and the new experiences are validated, identity will become the default mode for AzureWebJobsStorage, which is intended to move away from shared key authorization.  

Additionally, customers should review the guidance below to ensure their environments are configured to their organizational needs with least privilege.

Azure Functions and Azure Storage Authorization In-Depth Azure Functions and Azure Storage Authorization In-Depth

Azure Functions uses storage for several purposes. The AzureWebJobsStorage connection is used for general runtime behaviors, such as handling trigger checkpointing data and distributed lock management. Azure Functions code may be stored in the account specified by the AzureWebJobsStorage connection, but this depends on the deployment method selected. This is not the default for most setups, and Functions offers multiple deployment options for application code, including referencing content stored in a different blob store. The AzureWebJobsStorage connection uses a storage account connection string by default, though there is a preview of identity-based connections for AzureWebJobsStorage.  

In addition to leveraging the default storage account connection string, customers may want to provision access to users within their environment. Per the shared responsibility model, access management is a responsibility of the cloud customer and an important aspect of creating role assignments is the selection of the correct scope of assignment adhering to the security principle of least privilege. Apps and users should not be given broader access than is strictly necessary. Azure also offers features for granting bounded access through privileged identity management.  

By default, the only individuals that have access to listKeys is the individual that created the storage account and any inherited owners. Microsoft recommends providing granular access to users, using built-in roles such as Storage Blob Data Reader or Storage File Data SMB Share Reader, to grant permission to read storage account contents. Neither of these roles include permission to list storage account keys or otherwise modify content. Storage account keys provide full access to your storage account’s configuration and all its data, and like any access credential should be carefully protected. Other built-in roles may grant the Microsoft.Storage/storageAccounts/listKeys/action permission that is excessive for users only requiring read access.

Should excessive privileges be granted and subsequently used, customers could still gain insights into the data plane actions taken against that storage account through Azure Monitor. The Activity Log describes control plane operations, and can be used to monitor which users have accessed the shared storage keys. Activity logs are enabled by default for all storage accounts.  Customers can do this by searching for “listKeys” in the storage account where their Azure Function is stored. Resource logs can also be enabled and configured in Azure Monitor to identify any modifications to the contents of the storage account.  Customers are highly encouraged to have activity logs and resource logs configured on their storage accounts and consistently review their logs for suspicious activity. You can also monitor how clients authorize access to storage accounts, as well as identify clients that are authorizing their storage requests using shared keys or shared access signature (SAS).

As part of ongoing experience improvements, the Azure Functions team plans to update how Functions client tools work with storage accounts. This includes changes to better support scenarios using identity. After identity-based connections for AzureWebJobsStorage are generally available and the new experiences are validated, identity will become the default mode for AzureWebJobsStorage.  Going forward, Azure Functions clients will also help users enable ‘StorageWrite’ resource logging for storage accounts created in those experiences. Additionally, we have updated the Azure Functions documentation to better clarify best practices to configure storage account access for users with least privileges.

Azure Storage also continues to invest in security, including comprehensive support for identity-based authorization. Blob Storage offers full support for role-based access control (RBAC), including role-assignment conditions with Azure ABAC. We provide a comprehensive set of built-in roles to easily limit access with minimum privileges. Azure Files now includes support for Azure AD Kerberos over SMB and is adding support for OAuth over REST. This will also enable support for identity-based authorization for accessing Files in the Azure portal. We’re also planning for guidance and support so that new storage accounts can have shared key and shared access signature (SAS) authorization disabled by default  to encourage use of role-based access. In the interim, organizations can enforce the use of identity-based authorization for Storage using Azure Policy.

Microsoft Defender for Cloud (MDC) also provides enhanced monitoring for Storage accounts, to include automatic discovery of sensitive data to enrich security alerts,  malware scanning, and detections for unusual access patterns, use of compromised authentication tokens, and data exfiltration.

Recommended Actions for Customers Recommended Actions for Customers

To minimize the overall risk of abuse, we recommend that customers employ the following practices regarding user access to storage accounts:

1. Review the permissions of users to ensure least-privilege access to the storage account. Furthermore, you can limit the permission grants to the minimum scope required (ex. Storage account or resource group).

2. Monitor Activity Log for access to account keys

3. Enable StorageWrite resource logs for storage accounts that host Azure Functions along with a lifecycle policy to manage retention of the logs for a duration of your choice.

4. When storing application code in blob storage, consider using a storage account dedicated to that purpose so that you can limit access.

5. Enable MDC for storage accounts

In addition to the above recommended actions, we have made updates to existing documentation. Customers are encouraged to review the updated documents:

Storage considerations for Azure Functions

Securing Azure Functions

Conclusion Conclusion

In summary, we appreciate the opportunity to investigate the findings reported by Orca Security. We encourage all researchers to work with vendors under Coordinated Vulnerability Disclosure (CVD) and abide by the rules of engagement for penetration testing to avoid impacting customer data while conducting security research. Researchers who report security issues to the Microsoft Security Response Center are also eligible to participate in Microsoft’s Bug Bounty Program.

Orca’s report has highlighted opportunities for us to continue to improve to help customers correctly configure their environments with least privilege. The risk of these scenarios can be minimized by applying proper RBAC administration and ensuring that users are delegated the lowest level of permissions necessary. Using identity-based connections for AzureWebJobsStorage, currently in preview, prevents use of over-privileged permissions. Azure Storage also offers robust monitoring to detect unusual or unauthorized changes on a storage resource. At the same time, we believe that our guidance for customers around properly configuring user privileges for storage account access can be clarified further, so we have made updates to our existing documentation to reflect that. As always, we encourage our customers to follow security best practices to limit their exposure to vulnerabilities and other types of security events.