
Data Breach Exposes Thousands of Job Seekers Citing Top Secret Government Work - nthcolumn
http://gizmodo.com/thousands-of-job-applicants-citing-top-secret-us-govern-1798733354?utm_medium=sharefromsite&utm_source=Gizmodo_twitter
======
tarr11
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.

~~~
cyberferret
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 dumb, and
_deliberate_ thing.

If you wanted people to access resumes on an individual basis via a known web
link, then just make the documents individually publicly readable, but don't
make the entire bucket readable by default.

Better still, use Amazon's 'one time' or time based permissions to make
sensitive files only available to a certain person or for a limited time.

Re: UI - Amazons new S3 console is spades better than their old one - plenty
of auditing and analytics tools there too which can prevent silly mistakes
like this.

~~~
bostik
> _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.

~~~
cyberferret
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.

------
warent
Well if Google Reviews are anything to go by, McDonalds is more pleasant than
working at/with TigerSwan.

Also, it's amusing that they're blaming this mysterious third-party
"TalentPen" whose search results are so scant that they have this very article
as one of the top hits. Wouldn't TigerSwan be equally liable for vetting their
vendors?

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

------
mindcrime
S3 is awesome. You can find all sorts of interesting stuff by adding
site:s3.amazonaws.com to a google search. You'd seriously be amazed (or not)
at the stuff people leave in open S3 buckets.

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

~~~
ufmace
> 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.

~~~
yeukhon
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...

------
zie
Putting top secret anything on the Internet seems like the opposite of a good
idea.

~~~
leeoniya
4 million people have top secret clearance. what is and isn't a good idea
given this state of affairs is ummm...

[1]
[https://www.washingtonpost.com/news/worldviews/wp/2013/06/12...](https://www.washingtonpost.com/news/worldviews/wp/2013/06/12/top-
secret-clearance-holders-so-numerous-they-include-
packerscraters/?utm_term=.583c7cee7e89)

~~~
zie
Holy smuckers. Thanks for that link. I hope this mark everything secret
mentality is not to get around FOIA...

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

~~~
badlucklottery
If you're getting another job in intel, you send the references over email on
a secure network.

If you're leaving the intel community, chances are your references are really
pertinent. All the "I can't say" responses will derail a lot of interviewers
though.

~~~
user5994461
>>> All the "I can't say" responses will derail a lot of interviewers though.

Not so sure about that.

The majority of interviews in the HN bubbles is hours of technical questions
and quizzes, where the interviewers will not ask a single question about your
resume.

Outside of this bubble, the more mature interviewers, who did hundreds and
hundreds of interviewers, are not moved by a "This is confidential... I could
talk about -other thing- instead".

------
mindslight
URI or GTFO. What use is "reporting" on the snake oil industry's own
FUDmongering press releases? "Permissions are hard, let's go shopping!"

Let's see some independent analyses of this dataset. Start turning on the
right lights and the roaches will scatter.

