Microsoft's 38TB Data Leak

One misconfigured shared access signature (SAS) token allowed the exposure of 38 terabytes of data on Microsoft's AI GitHub repository. The data included secrets, private keys, passwords to Microsoft services, private source code and more than 30,000 internal Microsoft Teams messages from 359 Microsoft employees. Let's see what we can learn about and from this leak.

Among the exposed private information was a disk backup of the workstations of two employees, which included credentials and internal messages that amounted to more than 30,000. And, truly, what has been more worrying about this leak is the possibility of malicious hackers tampering with the AI training data shared by Microsoft. The repository tells readers to follow the URL, download a file and feed that AI model into a script. Since said file is formatted using pickle, a formatter prone by design to arbitrary code execution (it's possible for a file to run Python code when the file is loaded), were an attacker to inject malicious code into the AI model, they could execute commands in the machines of unsuspecting users.

Shortly after being tipped off about this leak, Microsoft invalidated the SAS token to prevent access to the storage account. Not two weeks later, they replaced the token on GitHub. Reportedly, "no customer data was exposed" (thankfully) and "no customer action is required in response to this issue."

Now, undoubtedly, there's the fact that more and more organizations handle massive piles of data, e.g., as they decide to implement AI, and the cloud provides the availability and scalability they need. So, the solutions that these organizations use to manage these data need to allow secure configurations. This is not to negate, though, that security is a shared responsibility: Organizations should make sure that they configure those solutions in such a way that cybercriminals' prying eyes cannot catch a glimpse of sensitive information.

Firstly, a fact that may be problematic is that generating the account SAS token is not an Azure event, but rather something that is done on the client side: When generating the token, the client's browser is responsible for downloading the account key from Azure and signing the generated token with the key. In turn, the token is not an Azure object. This does not allow for monitoring, so a token can be issued, and an admin, were their knowledge based only on what Azure tells them, would never learn of its creation. And even if they were made aware of its issuance, where the token circulates would also remain unknown. There would be a way, though, to learn of a token as it's used to access a storage account. For this to happen, the storage account should have logging enabled, which can be costly, as prices go up according to the request volume of each account, and logging would need to be paid for per account.

Secondly, revoking the Account SAS token is only possible as the effect of revoking the entire account key that signed the token. Efficient management is thus impaired, as every token signed by that key would be revoked upon applying this solution.

The researchers at Wiz, who discovered the data leak, thoroughly explained the previous issues, as well as the security risks related to the service's allowing for the creation of links granting (optionally) excessive permissions and having (optionally) infinite lifetime. It's true, Azure's tool makes dangerous combinations possible; but, like we said above, the client's responsibility for a secure configuration needs to be taken into account as well. Specifically, Microsoft's data leak sends a message of caution for organizations to review their data management governance in the cloud, lest they end up having their sensitive information up for grabs. So, let's look at what the latter can do from a preventive approach to cybersecurity.

However, if wishing to prevent the creation of SAS tokens, the recommendation has been to block the access to the operation that lists storage account access keys. The generation of user delegation SAS tokens, which rely on a user key instead of an account key, is still possible, though.

We know that many organizations need to handle progressively greater amounts of data in the cloud. If they misconfigure the security features of the cloud services they use, the sensitive data and users they are supposed to secure are at risk. We've talked elsewhere about the importance of checking with CSPM that your cloud-based systems and infrastructures comply with security requirements, prioritizing detected issues and resolving them as soon as possible. Moreover, we've argued that such activities need to be done all the time, keeping pace with development and the evolution of cyber threats (in DevSecOps fashion). That is why we offer Continuous Hacking, which performs CSPM continuously, along with other techniques, and provides the means and guidance to fulfill further vulnerability management steps. If you would like a taste of how we can help you prevent data leaks now, start your free trial.