Live data from Hacker News

Data accidentally exposed by Microsoft AI researchers

wiz.io

211–220 of 238 posts

Re: Data accidentally exposed by Microsoft AI researchers

#211
post #177

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.

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

#212
post #211
post #177

Earlier 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?

Sharing of datasets, disk images, ISOs, ML models, etc, as well as public websites.

Re: Data accidentally exposed by Microsoft AI researchers

#213
This is very similar to how some security researchers got access to TikTok's S3 bucket: https://medium.com/berkeleyischool/cloudsquatting-taking-ove...

They 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

#214

Earlier 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.

The terminal backlog is just sitting in memory as well. Just don’t leave passwords there, remove them immediately. You also have an option not to save the command in history, e.g. whitespace prefix in bash. Half of my bash commands that are longer than 20 symbols start with ^R to look up a similar command and edit it, not having history would make that much slower.

Re: Data accidentally exposed by Microsoft AI researchers

#215
post #38

A 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 ?

You can’t edit them in Word, so that must be too advanced for most people. LibreOffice never opened the PDFs too well for me, but Inkspace was pretty good, one page at a time though.

Re: Data accidentally exposed by Microsoft AI researchers

#216
post #144

Two 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…

FileDownloaderAccount had no copy pastable secret that can be leaked. Shared passwords are unnecessary of course and not good. If people are going to do that just use OneDrive/Dropbox rather than letting people use advanced things.

Re: Data accidentally exposed by Microsoft AI researchers

#217

Earlier 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.

Sure. But, you could auto-encrypt your ~/.bash_history if you're concerned about it being a problem and might need it for backtracing any issues etc?

Re: Data accidentally exposed by Microsoft AI researchers

#218
post #38

A 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…

The other aspect that pertains to AI is the data-maximalist mindset around these tools: grab as much data, aggregate it all together, and to hell with any concerns about what and how the data is being used; more data is the competitive advantage. This means a failure that might otherwise be quite limited in scope becomes huge.

Re: Data accidentally exposed by Microsoft AI researchers

#219

Amazing 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.

It’s easy.

“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

#220
post #46

Earlier 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.

It's great if it's done exhaustively
Post reply on HN