And this leak is only the tip of a bigger cybersecurity risk iceberg: cloud misconfiguration and cavalier mitigation attitudes by vendors.

A Microsoft Azure feature known as a Shared Access Signature (SAS) token has been called out recently as a cyber risk, because it allows users (with the right link) to access a data repository that is supposed to be private.

The at-risk repository is from Microsoft’s AI research division, which had since 2020 directed users to download open source images and code from the Azure Storage bucket via an SAS link that was misconfigured. Consequently, this allowed access to the entire private storage instance, (38TB) making the sensitive files and data public, according to cloud-data security firm Wiz, whose Chief Technology Officer Ami Luttwak had added that even write permissions had been granted.

Microsoft has acknowledged the incident and vulnerability disclosure of 22 June, with the official statements: “Data exposed in this storage account included backups of two former employees’ workstation profiles and internal Microsoft Teams messages of these two employees with their colleagues) stated in an advisory. No customer data was exposed, and no other internal services were put at risk because of this issue. No customer action is required in response to this issue.”

The official reactions

While the potential severity of the incident is being downplayed, Luttwak has been quoted saying that, since there is no way in Azure to monitor which permissions have been granted (because Azure does not know about all of the tokens being created, security teams actually have little observability or governance over this SAS tokens. To exacerbate the situation, other advisories in the past have warned of Azure storage misconfiguration and related cyber risks arising due to security teams’ know-how, and their use of default deployments that often lack strong controls

Microsoft’s consistent response has been to issue advisories for Azure users to:

    • Use only short-lived SAS tokens
    • Apply zero trust least privilege policies
    • Have a revocation plan
    • Create and handle SAS tokens appropriately
    • Follow best practices to minimize the risk of unintended access or abuse
    • Take note that GitHub’s secret spanning service, which monitors all public open source code changes for plaintext exposure of credentials and other secrets, has been expanded to include any SAS token that may have overly permissive expirations or privileges

Luttwak’s recommendations are more realistic and pragmatic:

    • There are too many pitfalls in setting up SAS tokens properly, so never ever use the mechanism to share files from a private cloud storage account
    • To share public data, create an appropriate, completely separate public account from which resources are shared

Editor’s note: with the massive volumes of exposed internal (and sensitive) data of AI research having been available publicly since 2020 — to those who have wanted it — one will not require much stretching of the imagination to extrapolate the devastating global cyber consequences when generative AI bots are abused to sniff out and exploit such vulnerabilities and strategic data every minute of the day.