![]() ![]() ![]() Use a SAS Expiration Policy to detect clients using long-lived SAS URLs. Monitor and audit your application: Track how requests to your storage account are authorized by enabling Azure Monitor and Azure Storage Logs. ![]() Be ready to remove the stored access policy or rotate storage account keys if a SAS or shared key is leaked. Have a revocation plan: Associate SAS tokens with a stored access policy for fine-grained revocation of a SAS within a container.Only expose SAS URLs to clients who need access to a storage account. Handle SAS tokens carefully: SAS URLs grant access to your data and should be treated as an application secret.Azure Storage recommends one hour or less for all SAS URLs. Use short-lived SAS: Always use a near-term expiration time when creating a SAS, and have clients request new SAS URLs when needed.a single blob), and limit permissions to only those needed by the application (e.g. Apply the principle of least privilege: Scope SAS URLs to the smallest set of resources required by clients (e.g.Best practices for SAS tokensĪllowing others to learn from their mistakes, Microsoft shared some tips on working with SAS URLs. Microsoft also said that as a result of Wiz’s research, it has expanded GitHub’s secret spanning service, which monitors all public open source code changes for plaintext exposure of credentials and other secrets to include any SAS token that may have overly permissive expirations or privileges. Customers do not need to take any additional action to remain secure.” No customer data was exposed, and no other Microsoft services were put at risk because of this issue. Microsoft stated that: “The information that was exposed consisted of information unique to two former Microsoft employees and these former employees’ workstations. “An attacker could have injected malicious code into all the AI models in this storage account, and every user who trusts Microsoft’s GitHub repository would’ve been infected by it.”Īfter Wiz shared its findings with Microsoft on JMicrosoft revoked the SAS token two days later. It was configured to grant permissions on the entire storage account, thus exposing the additional sensitive data by mistake.īut exposing sensitive data is not even the worst that could have happened, Wiz explains. The URL allowed access to more than just the open-source models. This URL included an overly-permissive SAS token for an internal storage account. They are a type of URI (Uniform Resource Identifier) that offer specific access rights to specified Azure Storage resources, like a blob, or a whole range of blobs.Ī Microsoft employee shared a URL for a blob store in a public GitHub repository while contributing to open-source AI learning models. Azure Storage SAS tokens are essentially strings that allow access to Azure Storage services in a secure manner. A "blob," which is short for Binary Large Object, is a mass of data in binary form. How long a client has access (start time, end time)īlob storage is a type of cloud storage for unstructured data.What network a client can access from (HTTPS, IP address).What operations a client can perform (read, write, list, delete).The backups contained sensitive data, including passwords to Microsoft services, secret keys, and over 30,000 internal Microsoft Teams messages from 359 Microsoft employees.Īn Azure feature called Shared Access Signature (SAS) tokens, which allows users to share data from Azure Storage accounts, was the source of the problem. Wiz Research found that Microsoft’s AI research team, while publishing a bucket of open-source training data on GitHub, accidentally exposed 38 terabytes of additional private data - including a disk backup of two employees’ workstations. That's how Microsoft managed to leak access to 38 terabytes of data. But what if a misconfiguration ends in a supposed internal storage account becoming suddenly accessible to everyone? It should speak for itself that you don’t just hand over the keys to your data. Warnings about including credentials, keys, and tokens when sharing code on publicly accessible repositories shouldn’t be necessary. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |