Microsoft worker accidentally exposes 38TB of sensitive data in GitHub blunder
(2023/09/18)
- Reference: 1695060191
- News link: https://www.theregister.co.uk/2023/09/18/more_microsoft_token_trouble/
- Source link:
A Microsoft employee accidentally exposed 38 terabytes of private data while publishing a bucket of open-source AI training data on GitHub, according to Wiz security researchers who spotted the leaky account and reported it to the Windows giant.
And Redmond, in a Monday write-up, downplayed the blunder, and said it was merely "sharing the learnings" to help customers avoid making similar mistakes. This is despite Wiz claiming the leaky data bucket had private keys, passwords, and over 30,000 internal Microsoft Teams messages, as well as backup data from two employees' workstations.
"No customer data was exposed, and no other internal services were put at risk because of this issue," the Microsoft Security Response Center team [1]said . "No customer action is required in response to this issue."
[2]
In a [3]report published on Monday, Wiz researchers Hillai Ben-Sasson and Ronny Greenberg detailed what happened. While they were scanning for misconfigured storage containers, they came across a GitHub repository belonging to the Microsoft AI research team that provides open-source code and machine learning models for image recognition.
[4]
[5]
This repository contained a URL with an overly-permissive Shared Access Signature (SAS) token for a Microsoft-owned internal Azure storage account containing private data.
A [6]SAS token is a signed URL that grants some level of access to Azure Storage resources. The user can customize the level of access, from read-only to full-control, and in this case, the SAS token was misconfigured with full-control permissions.
[7]
This not only gave the Wiz team — and potentially more nefarious-minded snoops — the ability to view everything in the storage account, but they also could have deleted or altered existing files.
"Our scan shows that this account contained 38TB of additional data — including Microsoft employees' personal computer backups," Ben-Sasson and Greenberg said. "The backups contained sensitive personal data, including passwords to Microsoft services, secret keys, and over 30,000 internal Microsoft Teams messages from 359 Microsoft employees."
Microsoft, for its part, says the personal computer backups belonged to two former employees. After being notified about the exposure on June 22, Redmond says it revoked the SAS token to prevent any external access to the storage account, and it plugged the leak on June 24.
[8]Microsoft: China stole secret key that unlocked US govt email from crash debug dump
[9]Stolen Microsoft key may have opened up a lot more than US govt email inboxes
[10]Grab those updates: Microsoft flings out fixes for already-exploited bugs
[11]Scattered Spider traps 100+ victims in its web as it moves into ransomware
"Additional investigation then took place to understand any potential impact to our customers and/or business continuity," the MSRC report says. "Our investigation concluded that there was no risk to customers as a result of this exposure."
Also in the write-up, Redmond recommended a series of best practices for SAS to minimize the risk of overly permissive tokens. This includes limiting the scope of the URLs to the smallest set of resources required, and also limiting permissions to only those needed by the application.
[12]
There's also a feature that allows users to set an expiration time, and Microsoft recommends one hour or less for SAS URLs. This is all good advice, it's just a pity Redmond didn't eat its own dog food in this instance.
Finally, Redmond promises to do better on its end of things: "Microsoft is also making ongoing improvements to our detections and scanning toolset to proactively identify such cases of over-provisioned SAS URLs and bolster our secure-by-default posture."
This, of course, isn't Microsoft's only issue with key-based authentication in recent months.
In July, [13]Chinese spies stole a secret Microsoft key and used to break into US government email accounts. Wiz researchers [14]weighed in on that security snafu, too. ®
Get our [15]Tech Resources
[1] https://msrc.microsoft.com/blog/2023/09/microsoft-mitigated-exposure-of-internal-information-in-a-storage-account-due-to-overly-permissive-sas-token/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZQjIg4D4kp@FpBt45W2BCwAAAM0&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.wiz.io/blog/38-terabytes-of-private-data-accidentally-exposed-by-microsoft-ai-researchers
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZQjIg4D4kp@FpBt45W2BCwAAAM0&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZQjIg4D4kp@FpBt45W2BCwAAAM0&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZQjIg4D4kp@FpBt45W2BCwAAAM0&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2023/09/06/microsoft_stolen_key_analysis/
[9] https://www.theregister.com/2023/07/21/microsoft_key_skeleton/
[10] https://www.theregister.com/2023/09/12/september_2023_patch_tuesday/
[11] https://www.theregister.com/2023/09/15/scattered_spider_snares_100_victims/
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZQjIg4D4kp@FpBt45W2BCwAAAM0&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[13] https://www.theregister.com/2023/09/06/microsoft_stolen_key_analysis/
[14] https://www.theregister.com/2023/07/21/microsoft_key_skeleton/
[15] https://whitepapers.theregister.com/
And Redmond, in a Monday write-up, downplayed the blunder, and said it was merely "sharing the learnings" to help customers avoid making similar mistakes. This is despite Wiz claiming the leaky data bucket had private keys, passwords, and over 30,000 internal Microsoft Teams messages, as well as backup data from two employees' workstations.
"No customer data was exposed, and no other internal services were put at risk because of this issue," the Microsoft Security Response Center team [1]said . "No customer action is required in response to this issue."
[2]
In a [3]report published on Monday, Wiz researchers Hillai Ben-Sasson and Ronny Greenberg detailed what happened. While they were scanning for misconfigured storage containers, they came across a GitHub repository belonging to the Microsoft AI research team that provides open-source code and machine learning models for image recognition.
[4]
[5]
This repository contained a URL with an overly-permissive Shared Access Signature (SAS) token for a Microsoft-owned internal Azure storage account containing private data.
A [6]SAS token is a signed URL that grants some level of access to Azure Storage resources. The user can customize the level of access, from read-only to full-control, and in this case, the SAS token was misconfigured with full-control permissions.
[7]
This not only gave the Wiz team — and potentially more nefarious-minded snoops — the ability to view everything in the storage account, but they also could have deleted or altered existing files.
"Our scan shows that this account contained 38TB of additional data — including Microsoft employees' personal computer backups," Ben-Sasson and Greenberg said. "The backups contained sensitive personal data, including passwords to Microsoft services, secret keys, and over 30,000 internal Microsoft Teams messages from 359 Microsoft employees."
Microsoft, for its part, says the personal computer backups belonged to two former employees. After being notified about the exposure on June 22, Redmond says it revoked the SAS token to prevent any external access to the storage account, and it plugged the leak on June 24.
[8]Microsoft: China stole secret key that unlocked US govt email from crash debug dump
[9]Stolen Microsoft key may have opened up a lot more than US govt email inboxes
[10]Grab those updates: Microsoft flings out fixes for already-exploited bugs
[11]Scattered Spider traps 100+ victims in its web as it moves into ransomware
"Additional investigation then took place to understand any potential impact to our customers and/or business continuity," the MSRC report says. "Our investigation concluded that there was no risk to customers as a result of this exposure."
Also in the write-up, Redmond recommended a series of best practices for SAS to minimize the risk of overly permissive tokens. This includes limiting the scope of the URLs to the smallest set of resources required, and also limiting permissions to only those needed by the application.
[12]
There's also a feature that allows users to set an expiration time, and Microsoft recommends one hour or less for SAS URLs. This is all good advice, it's just a pity Redmond didn't eat its own dog food in this instance.
Finally, Redmond promises to do better on its end of things: "Microsoft is also making ongoing improvements to our detections and scanning toolset to proactively identify such cases of over-provisioned SAS URLs and bolster our secure-by-default posture."
This, of course, isn't Microsoft's only issue with key-based authentication in recent months.
In July, [13]Chinese spies stole a secret Microsoft key and used to break into US government email accounts. Wiz researchers [14]weighed in on that security snafu, too. ®
Get our [15]Tech Resources
[1] https://msrc.microsoft.com/blog/2023/09/microsoft-mitigated-exposure-of-internal-information-in-a-storage-account-due-to-overly-permissive-sas-token/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZQjIg4D4kp@FpBt45W2BCwAAAM0&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.wiz.io/blog/38-terabytes-of-private-data-accidentally-exposed-by-microsoft-ai-researchers
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZQjIg4D4kp@FpBt45W2BCwAAAM0&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZQjIg4D4kp@FpBt45W2BCwAAAM0&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZQjIg4D4kp@FpBt45W2BCwAAAM0&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2023/09/06/microsoft_stolen_key_analysis/
[9] https://www.theregister.com/2023/07/21/microsoft_key_skeleton/
[10] https://www.theregister.com/2023/09/12/september_2023_patch_tuesday/
[11] https://www.theregister.com/2023/09/15/scattered_spider_snares_100_victims/
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZQjIg4D4kp@FpBt45W2BCwAAAM0&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[13] https://www.theregister.com/2023/09/06/microsoft_stolen_key_analysis/
[14] https://www.theregister.com/2023/07/21/microsoft_key_skeleton/
[15] https://whitepapers.theregister.com/
Oh noes
m4r35n357
My public SSH key was up there ;)
sten2012
The "whoopsie daisy, no harm done" response leaves a lot to be desired from a large company. Let alone one that goes out their way to force me to share data from operating systems coming preinstalled and several monopolies.
If they didn't own GitHub I bet they'd be trying to fingerpoint over there, but whoopsie daisy again. Bought their own scapegoat.
I don't know what is worse, losing 38TB of sensitive data or the use of the phrase "sharing the learnings"...
Yes, from orbit -->