Critical Vulnerability: AWS Credential Disclosure • Hacker News Board

Re: Critical Vulnerability: AWS Credential Disclosure

#41

Post by dmpatierno » Mon, Apr 07, 2014, 10:43 PM UTC

jbert wrote: post #21

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

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.

Re: Critical Vulnerability: AWS Credential Disclosure

#42

Post by varkson » Mon, Apr 07, 2014, 10:58 PM UTC

ludicast wrote: post #26

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

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.

Re: Critical Vulnerability: AWS Credential Disclosure

#43

Post by ludicast » Mon, Apr 07, 2014, 11:16 PM UTC

varkson wrote: post #42

ludicast wrote: post #26

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

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.

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.

Re: Critical Vulnerability: AWS Credential Disclosure

#44

Post by carterehsmith » Tue, Apr 08, 2014, 1:13 AM UTC

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.

Re: Critical Vulnerability: AWS Credential Disclosure

#45

Post by jbert » Tue, Apr 08, 2014, 9:02 AM UTC

dmpatierno wrote: post #41

jbert wrote: post #21

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

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.

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.