Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Data Breach Exposes Thousands of Job Seekers Citing Top Secret Government Work

gizmodo.com

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Data Breach Exposes Thousands of Job Seekers Citing Top Secret Government Work

#21

Post by btown »

cyberferret wrote: post #20
tarr11 wrote: post #15

Setting permissions on s3 buckets is absurdly complicated. Though it's no excuse, it's not surprising people leave it open, it's too hard to figure out how to lock it down. Amazon needs to share some of the blame here and create a sane UI.

Well, I've used S3 on many projects since it pretty much came out. TBH, security is not much harder that in any &nix based systems. Default settings are usually NO public read, and it actually takes more work to make stuff publicly readable on S3 than to just leave it as private. I am thinking the biggest stuff up with this vendor is that they made the entire bucket or bucket key available publicly, which is a pretty…

The one time permission links are quite simple to implement, with libraries for practically every language. So there's really no excuse.

Re: Data Breach Exposes Thousands of Job Seekers Citing Top Secret Government Work

#23

Post by yeukhon »

ufmace wrote: post #18
yeukhon wrote: post #12

Time Warner Cable also had the same data breach. I wonder by passwordless did they mean someone was able to do a ls command on the bucket and was able to download as a public/anon user (direct s3 link)? If this was done I bet you someone probably didn't have time to implement secure link, just decided to make the bucket open.

> someone probably didn't have time to implement secure link, just decided to make the bucket open. That sounds more likely. AWS permissions are tricky, but not so tricky that it's easy to leave a bucket wide open like that. In my experience, they're much more likely to lock out someone who should be able to access them than to allow someone who shouldn't. Just bad practice to give up and allow anyone in.

Another possibility: someone was doing testing (and at thr stage too lazy), they made it public, and forgot about it even after they implemented authorization at the application level. Could have used trusted advisor...

Re: Data Breach Exposes Thousands of Job Seekers Citing Top Secret Government Work

#24

Post by yeukhon »

pmiller2 wrote: post #16
yeukhon wrote: post #12

Time Warner Cable also had the same data breach. I wonder by passwordless did they mean someone was able to do a ls command on the bucket and was able to download as a public/anon user (direct s3 link)? If this was done I bet you someone probably didn't have time to implement secure link, just decided to make the bucket open.

There's always time to implement basic security when it comes to personally identifiable info. This was simple ineptitude.

Yes agree, but incident like this usually orginatrd from laziness/ forgetting about turning the switch off.

Re: Data Breach Exposes Thousands of Job Seekers Citing Top Secret Government Work

#25

Post by graystevens »

AWS S3 storage, as mentioned previously in this thread, are a real treasure trove of leaks and breaches. I have been scanning them as part of a project and regularly have to reach out to businesses to tell them they're leaking information publicly.

You name it, I've probably come across it - lots are for hosting static content of websites which is pretty common, but there are also website and database backups, user uploaded content (from a sensitive 'dating' website), development and staging environments with sensitive internal information, a sea of CVs etc.

The hardest part is trying to responsibly disclose this stuff to the businesses - trying to find a security contact is often impossible, leaving it up to info@ or support@ emails.

And obviously AWS aren't the only cloud storage provider out there... there is more to be found with the other providers.

Re: Data Breach Exposes Thousands of Job Seekers Citing Top Secret Government Work

#26

Post by bostik »

cyberferret wrote: post #20
tarr11 wrote: post #15

Setting permissions on s3 buckets is absurdly complicated. Though it's no excuse, it's not surprising people leave it open, it's too hard to figure out how to lock it down. Amazon needs to share some of the blame here and create a sane UI.

Well, I've used S3 on many projects since it pretty much came out. TBH, security is not much harder that in any &nix based systems. Default settings are usually NO public read, and it actually takes more work to make stuff publicly readable on S3 than to just leave it as private. I am thinking the biggest stuff up with this vendor is that they made the entire bucket or bucket key available publicly, which is a pretty…

> Default settings are usually NO public read, and it actually takes more work to make stuff publicly readable on S3 than to just leave it as private.

While true, and a very sensible default, this misses one crucial point.

Setting granular permissions for an S3 bucket is hideously difficult. Want to limit access to a whitelisted set of users or origins? Write a bucket policy. This is where the UI completely fails.

0: The policies can become awfully difficult to understand even for straightforward use cases.

1: You can have policies with sensible rule sets, but the S3 UI doesn't allow to pick-and-attach any of them.

2: The "permissions" tab has a very convenient and extremely dangerous option as the top item: "allow access for any logged in user"

I'll let the last one sink in. It's not "any logged in user in MY organisation", it's really "ANY logged in AWS user". Putting the bucket essentially world-readable by accident is far too easy.

Re: Data Breach Exposes Thousands of Job Seekers Citing Top Secret Government Work

#27

Post by mirimir »

andy_ppp wrote: post #3

If you are a spook I wonder how you give references? And if you’ve done anything good you can’t write it on your CV without breaking the law.

After publication of the first few NSA documents via Snowden, people searched Linked In for keywords like XKeyscore. And found users who had cited them in work history. Security by obscurity?

Re: Data Breach Exposes Thousands of Job Seekers Citing Top Secret Government Work

#28

Post by jaclaz »

warent wrote: post #11
leggomylibro wrote: post #6

Earlier quoted context omitted.

Close, but not quite how it works - there's actually a series of documentaries about the practice of retiring spies called The Prisoner. https://en.wikipedia.org/wiki/The_Prisoner

I'm not sure those are documentaries so much as fiction. Not to say it's inaccurate storytelling, but it's definitely not a documentary

Well, I am sure that it is entirely fiction.

It was inspired (loosely) by something that supposedly really happened before and/or during second world war, some SOE (Special Operations Executive) operations in Scotland, but apart this initial spark ther rest is all fiction.

http://www.secretscotland.org.uk/index.php/Secrets/Inverlair...

Re: Data Breach Exposes Thousands of Job Seekers Citing Top Secret Government Work

#29

Post by cyberferret »

bostik wrote: post #26
cyberferret wrote: post #20

Earlier quoted context omitted.

Well, I've used S3 on many projects since it pretty much came out. TBH, security is not much harder that in any &nix based systems. Default settings are usually NO public read, and it actually takes more work to make stuff publicly readable on S3 than to just leave it as private. I am thinking the biggest stuff up with this vendor is that they made the entire bucket or bucket key available publicly, which is a pretty…

> Default settings are usually NO public read, and it actually takes more work to make stuff publicly readable on S3 than to just leave it as private. While true, and a very sensible default, this misses one crucial point. Setting granular permissions for an S3 bucket is hideously difficult. Want to limit access to a whitelisted set of users or origins? Write a bucket policy. This is where the UI completely fails. 0:…

Point taken. Granular policies ARE a royal PITA to try and build. I wish their policy editor had a nice easy ARN selector, and a 'policy building' GUI that would help you with syntax and grouping.

Most of my projects use either totally restricted buckets, or buckets with access to a particular IAM, which is basic, but works.

Post reply on HN