
Critical Vulnerability: AWS Credential Disclosure - zhongjiewu
http://blog.trustlook.com/2014/03/31/critical-vulnerability-bad-practice-leads-to-aws-credential-disclosure/
======
ludicast
1) This is as many said, just an example of bad practice rather than something
specific to AWS. I remember in my php days seeing commented-out php code in
html that included db passwords. If putting passwords, api keys, etc. in
client-side code doesn't make your hair stand up, well, something is wrong.

2) I would be curious what the backends were in these instances. With the
growth of the BaaS-model for app development, I think we're going to see a lot
more "offshoring" of these security things, where keys are thrown in the
front-end app. "I do it with firebase, why not twilio or aws?"

~~~
varkson
How would someone manage to get commented out PHP in the HTML? Has the
behaviour changed? The only way I can think of doing it would be to replace
the PHP open and close with HTML comments. I can't imagine anyone doing that.

~~~
ludicast
Html commented around the php tags. Don't know behavior these days but back
then the php tag with contents was visible in html source.

Guy I was consulting for was famous designer who needed help with web project
he talked his way into. Can't be arrogant though, he'd probably laugh at my
font, color and layout choices as equally naive/catastrophic.

------
mahmoudimus
If you use Chef, at Balanced
([https://github.com/balanced](https://github.com/balanced)), we've built a
pretty awesome tool called: "Citadel" ([https://github.com/balanced-
cookbooks/citadel](https://github.com/balanced-cookbooks/citadel)) that uses
IAM policies for fetching secrets securely stored in S3 buckets.

It's pretty awesome. We're porting all of our code to use this, so we can open
source most of our code freely and not have to necessary find ourselves
working around security hurdles like this one -- though I'm not sure how it
would've helped in this particular use case.

~~~
systemizer
Cool. I'm curious: what was your motivation for doing this rather than using
Chef's encrypted data bags?

Is it because it's tightly integrated with IAM? If that's the case, does that
mean you guys use a cookbook that tightly couples system users with IAM roles?

~~~
mahmoudimus
We're strong believers that data bags are an anti-pattern. One of our
engineers, [https://github.com/coderanger](https://github.com/coderanger),
wrote something up: [https://coderanger.net/2014/02/data-
bags/](https://coderanger.net/2014/02/data-bags/)

He was employed previously at Opscode, now Chef Inc.

------
DigitalBison
I don't mean to downplay the severity of this, and I could be missing
something, but I fail to see how this is a new vulnerability that TrustLook
has "discovered". We've seen countless stories on HN (unless I'm wildly
misremembering) of credentials being leaked via client-side applications,
including AWS credentials. Haven't developers been getting this wrong since
the dawn of client-server authentication?

~~~
scottm01
This does seem like a PR department writing rather then security researcher.
Calling out AWS credentials seems to be particularly trolling, they just
happen to be the secrets that were easiest to grep for I guess.

~~~
jlgaddis
Indeed. I took a quick look at the "front page" of their blog and many of the
post titles are what you would expect to see on press releases.

According to their "About Us" page, however, they are "a global leader in
next-generation mobile security solutions." That's pretty remarkable to me
considering the company was "founded in 2013" \-- not bad for a year or so's
work.

But I suppose that's easy to do when your "team consists of security industry
veterans" (that shall go unnamed, it seems).

Maybe next week they'll reveal how my home is vulnerable to being broken into
by a burglar armed with a battering ram.

------
yeukhon
The title is so catchy. I came to think AWS credentials were leaked because
Amazon didn't handle it properly. Instead, this is about someone committing
credentials in app. This is like me committing a password into my git repo.
How is this even new discovery?

I read about a similar one a few months ago. If I were to search for
credentials, I should just search through bitbucket, google code and github.
There are tons of passwords committed and many are probably still usable...

------
yogo
I'm not even sure this should be filed under vulnerability. How is this any
different from embedding credentials on a webpage so that JavaScript can talk
directly with the service lol.

~~~
samstave
It ___is_ __a vulnerability in __ _your_ __environment if you 're using some
of these tools and your keys are in them. It is not a vulnerability of AWS
itself.

------
vanilla
There was a Blog-post on HN 10 days ago, showing Amazon is actively scanning
for this and warns developers.

[https://news.ycombinator.com/item?id=7491272](https://news.ycombinator.com/item?id=7491272)

it also predates this blog post

~~~
Patrick_Devine
Yeah, I'm not sure how anyone could consider this a "Critical Vulnerability".
It's kind of cool and slightly frightening that Amazon scans for API keys. I'd
love to know how they're going about the scan though; maybe using excess
capacity to do a crawl and analyzing the results? Maybe through Alexa?

------
carterehsmith
The title is misleading. This is not “AWS vulnerability”. What happened was
that someone shared his/her admin-level credentials with the world.

Whether credentials are for their AWS account, or Rackspace account, or Azure
account, or their personal banking account, makes no difference, it is not
“AWS vulnerability” or “Rackspace vulnerability”, or whatever, it is just a
big, big, rookie mistake made by the developer.

------
kehrlann
A story about this was posted about 10 days ago here on HN :
[https://news.ycombinator.com/item?id=7491272](https://news.ycombinator.com/item?id=7491272)

Amazon themselves check random apps on the Play Store to make sure you don't
embed your cretendial in your code.

------
jbert
So - there has to be some trust to the client, unless the resource is public
(or locked down with end-user creds).

In this case, some kind of creds need to go into the app, right?

So the best practise is simply to make those some creds which: 1) have limited
privileges (e.g. just access one S3 bucket) and 2) can be centrally revoked
(requiring app update for everyone?)

I've read the link on the amazon Token Vending Machine approach, but I still
don't understand why that is better.

If I have the embedded creds to get a token from the TVM, and that token
allows me to access an S3 bucket, how is that more secure from using limited
IAM creds which just allow direct access to the bucket?

In both cases:

\- the creds can be revoked centrally

\- possession of the embedded creds allows access to the S3 bucket (either
directly, or by fetching a token first)

~~~
dmpatierno
STS (Security Token Service) can generate credentials with much finer-grained
control than just access to a whole bucket. You can require user
authentication, do rate limiting, and set expire times. To allow a client to
upload an image, for example, you can generate credentials that only grant
privileges to a specific file location. It's _much_ better than embedding
master IAM credentials in a client.

~~~
jbert
Thanks very much for that.

In terms of comparing the two approaches, I can see that if you are granting
different creds based on a user auth, an STS is useful to grant temporary
creds limited to a subset.

I'll need to look up the details of how much more fine-grained the STS tokens
are than the IAM creds to see how much difference there is in the anonymous
case.

------
eduardordm
In my company we have an application that stores an API key in its local
storage. This API key is generated by the client app when it's first run and
it's individual. If it gets stolen only that client will have its security
compromised. That happened to us a couple of times, always on rooted android
phones with pirated software installed.

I'm a heavy AWS user but not too familiar with S3 keys, couldn't the keys be
generated and isolated per user?

~~~
wangsanli
Yes. You can request Temporary Credentials for s3 service. However, the only
secure way to do it is on server side not on client.

------
twistedpair
A few times I've found myself looking to automate some AWS task to add/remove
a bunch of widgets that their API does not easily allow. Turns out there are a
few webapps that will do these things for you. On opening the app, they ask
you to give them your AWS keys.

Who actually does this? Personally I fear most devs are not properly creating
several groups and users and permissioning them to the bare minimum depending
on the app/dev's minimum needs. Then again, AWS's tools don't help as doing X
with AWS CLI might really require permission X, Y and Z, something you don't
want to discover in production.

------
konceptz
I wrote a program which could help with this.
[https://github.com/konceptz/AmazonS3-Rest](https://github.com/konceptz/AmazonS3-Rest)

This will let you take a pre-authorized token and make these same requests. No
one should be sharing S3 Secrets even if it isn't hardcoded like the
implementations trustlook found.

~~~
konceptz
To be more explicit, and for those who do not know. Secured Amazon S3 buckets
require signed strings to be passed with requests along with the request.
These requests are generated by using the secret key of the owner's account.

Here's an example of a signed request:

GET foo HTTP/1.1\r\n Host: myawsserver.amazonaws.com\r\n Date: Mon, 7 Apr 2014
15:26:45 EDT\r\n Range: bytes=0-10\r\n" Authorization: AWS
AKIAOSF0DNN7EXAMPLE:UC901LzExamplebsGIQdEBeW+tt4=\r\n\r\n

In the above example a request that gets the first 11 bytes of file foo, the
"UC901LzExamplebsGIQdEBeW+tt4=" is generated by using your secret key to sign
a string, HMAC_S3Secret(string_to_sign).

There are many tools on Amazon, like boto and S3cUrl which help developers
learn how to write S3 requests into their code. The problem is that they
abstract the signing a lot.

It's possible, and probably a better idea, to pre-sign a token for a specific
request either by generating on the server side on the fly, or creating a pool
of valid request tokens.

The difficulty is that Amazon's documentation isn't very good if you're doing
something like trying to limit file access to specific byte portions of a
file, or limit access times.

I found that valid tokens last for 15 minutes from the time they specify in
the signature. Anyways, hope this helps.

------
labguy10001
The key problem is, Android is a front-end technique. Everything you put in
code/resource is transparent. But so many developers treat it like back-end
and believe it's save to put sensitive info inside...

~~~
revelation
The key problem is thinking anything the _client_ does is secure, or even
worse, that it may be _trusted_. A developer that hasn't grasped this very
simple fact will inevitably not only screw up the client side (i.e. exposing
AWS credentials), but also the server side.

~~~
yogo
Exactly, rule number 1 is always that client data cannot be trusted.

------
bowlofpetunias
Security aside, I don't even understand what goes through developers' heads by
distributing hardcoded credentials to a third party service together with
their apps.

There are so many things wrong with that picture.

------
wangsanli
my god. This is huge! Imagine what hackers can do with this full control of
AWS.

~~~
labguy10002
How about opening some large GPU instances and mine some btc ;)

------
mantrax4
One more example I'll use next time someone asks me "why service oriented
architecture".

Interaction with AWS should be wrapped in an app service. So the keys will be
on your server. Your web sites or apps talk with that service, not the
underlying implementation behind it (i.e. AWS). The API exposed by your app
service should be secure by default.

Sometimes some of those apps start as web sites, and they keep a lot of their
logic in their controllers, even views. So when time comes to port this to a
native phone app for ex., database logins, secret keys and other private
implementation details "naturally" end up in application code, since an app
consists of the native code version of said controllers and views.

This could've been easily avoided if you automatically split things in secure
services from the very start.

~~~
aluskuiuc
That said; the AWS APIs offer a lot of tools to hand keys to clients with
extremely limited scope, both in API access and time boundaries. For example;
a game could be given access keys that allow it to write a high score only to
a particular _row_ of a DynamoDB table, the one corresponding to that user.

Direct device->AWS use can make a lot of scaling issues very simple without
needing a middleman service on every request. However this does not obviate
the need for a federation brokering-type service that auths the device, calls
AWS to get a time-limited token with permissions scoped just so, and hands
that back to the client.

AWS provides Amazon/Google/FB web identity federation for just this use case:
[http://aws.amazon.com/iam/details/manage-
federation/](http://aws.amazon.com/iam/details/manage-federation/).

~~~
mantrax4
This is all great, and indeed solves the security issues in exposing AWS.

And I'm sure it does wonders for locking in clients to AWS APIs ;)

As for scalability, there's no inherent scalability issue with middlemen
services. There's potentially some added lag (not necessarily), but a pure
middleman service (with maybe a bit of caching) is an "embarrassingly
parallel" workload. If it gets slow, you just add more servers. And they could
be Amazon EC2 servers, nothing bad about that! :)

------
majiaguan
holly crap!

------
stcredzero
Basically, it's UDID all over again, only worse.

