The article tries to play up the AI angle, but this was a pretty standard misconfiguration of a storage token. This kind of thing happens shockingly often, and it’s why frequent pentests are important.
It was so common that S3 added several features to make it really, really hard to accidentally leave a whole bucket public. Looks like Azure hasn't done similarly.
Data accidentally exposed by Microsoft AI researchers
211–220 of 238 posts
Re: Data accidentally exposed by Microsoft AI researchers
#212Earlier quoted context omitted.
It was so common that S3 added several features to make it really, really hard to accidentally leave a whole bucket public. Looks like Azure hasn't done similarly.
Is there any valid use case for when it's a good idea to publicly expose a S3 bucket?
Re: Data accidentally exposed by Microsoft AI researchers
#213They used the same mechanism of using common crawl or other publicly available web crawler data to source dns records for s3 buckets.
Re: Data accidentally exposed by Microsoft AI researchers
#214Earlier quoted context omitted.
laughs in log4j vuln A good fraction of the flaws we found at Matasano involved pentests against statically typed languages. If an adversary has root access to your storage box, they can likely find ways to pivot their access. Netpens were designed to do that, and those were the most fun; they’d parachute us into a random network, give us non-root creds, and say “try to find as many other servers that you can get to.…
Am I one of few people who is frightened by shell history files? I always disable mine because it just seems like a roadmap to interesting stuff for anyone who might gain access to it. Including even stuff like sudo passwords typed at the wrong time or into the wrong window.
Re: Data accidentally exposed by Microsoft AI researchers
#215A number of replies here are noting (correctly) how this doesn't have much to do with AI (despite some sentences in this article kind of implicating it; the title doesn't really, fwiw) and is more of an issue with cloud providers, confusing ways in which security tokens apply to data being shared publicly, and dealing with big data downloads (which isn't terribly new)... ...but one notable way in which it does implic…
So, a little bit like a lot of people think that (non-checksummed/non-encrypted) PDFs cannot be modified, even though they are easily editable with Libre freaking Office ?
Re: Data accidentally exposed by Microsoft AI researchers
#216Two of the things that make me cringe are mentioned. Pickle files and SAS tokens. I get nervous dealing with Azure storage. Use RBAC. They should depreciate SAS and account keys IMO. SOC2 type auditing should have been done here so I am surprised of the reach. Having the SAS with no expiry and then the deep level of access it gave including machine backups with their own tokens. A lot of lack of defence in depth goin…
So SAS tokens are worse that some admin setting up "FileDownloaderAccount" and then sharing its password with multiple users or using the same for different applications? I take SAS tokens with expiration over people setting up shared RBAC account and sharing password for it. Yes people should do proper RBAC, but point a company and I will find dozens "shared" accounts. People don't care and don't mind. When beating…
Re: Data accidentally exposed by Microsoft AI researchers
#217Earlier quoted context omitted.
laughs in log4j vuln A good fraction of the flaws we found at Matasano involved pentests against statically typed languages. If an adversary has root access to your storage box, they can likely find ways to pivot their access. Netpens were designed to do that, and those were the most fun; they’d parachute us into a random network, give us non-root creds, and say “try to find as many other servers that you can get to.…
Am I one of few people who is frightened by shell history files? I always disable mine because it just seems like a roadmap to interesting stuff for anyone who might gain access to it. Including even stuff like sudo passwords typed at the wrong time or into the wrong window.
Re: Data accidentally exposed by Microsoft AI researchers
#218A number of replies here are noting (correctly) how this doesn't have much to do with AI (despite some sentences in this article kind of implicating it; the title doesn't really, fwiw) and is more of an issue with cloud providers, confusing ways in which security tokens apply to data being shared publicly, and dealing with big data downloads (which isn't terribly new)... ...but one notable way in which it does implic…
Re: Data accidentally exposed by Microsoft AI researchers
#219Amazing how ingrained it is in some people to just go around security controls. someone chose to make that SAS have a long expiry and someone chose to make it read-write.
“ugh, this thing needs to get out by end of week and I can’t scope this key properly, nothing’s working with it.”
“just give it admin privileges and we’ll fix it later”
sometimes they’ll put a short TTL on it, aware of the risk. Then something major breaks a few months later, gets a 15 year expiry, never is remediated.
It’s common because it’s tempting and easy to tell yourself you’ll fix it later, refactor, etc. But then people leave, stuff gets dropped, and security is very rarely a priority in most orgs - let alone remediation of old security issues.
Re: Data accidentally exposed by Microsoft AI researchers
#220Earlier quoted context omitted.
Pentests where people actually get out of bed to do stuff (read code, read API docs etc) and then try to really hack your system are rare. Pentests where people go through the motions, send you report with a few unimportant bits highlit while patting you on the back for your exemplary security so you can check the box on whatever audit you're going through are common.
Yep, most pentests go through the OWASP list and call it done.