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

Critical Vulnerability: AWS Credential Disclosure

blog.trustlook.com

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Critical Vulnerability: AWS Credential Disclosure

#11

Post by ossreality »

mantrax4 wrote: post #6

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…

Except that you don't understand the problem either and have replicated it and just moved it.

Re: Critical Vulnerability: AWS Credential Disclosure

#12

Post by aluskuiuc »

mantrax4 wrote: post #6

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…

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

Re: Critical Vulnerability: AWS Credential Disclosure

#13

Post by 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?

Re: Critical Vulnerability: AWS Credential Disclosure

#15

Post by 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?

Re: Critical Vulnerability: AWS Credential Disclosure

#16

Post by konceptz »

konceptz wrote: post #8

I wrote a program which could help with this. 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.

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.

Re: Critical Vulnerability: AWS Credential Disclosure

#17

Post by jug6ernaut »

majiaguan wrote: post #7
gtaylor wrote: post #4

Earlier quoted context omitted.

This isn't specific to Android, as you can pull symbols out of many kinds of binaries with some work. Being silly with you credentials can hurt you, regardless of the platform or using a compiled or interpreted environment.

I believe this vulnerability is existing for IOS apps, too. Trustlook they may only focus on Android

This vulnerability exists with EVERY client application. It is just much easier to obtain the applications with android(as opposed to IOS) which is the only reason i can assume Trustlook focused on android.

This isnt as much a "vulnerability" as it is a complete miss understanding of security and the technology they are using. Everything on the client side should be assumed as obtainable.

Re: Critical Vulnerability: AWS Credential Disclosure

#18

Post by mantrax4 »

aluskuiuc wrote: post #12
mantrax4 wrote: post #6

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…

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

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! :)

Re: Critical Vulnerability: AWS Credential Disclosure

#19

Post by mahmoudimus »

If you use Chef, at Balanced (https://github.com/balanced), we've built a pretty awesome tool called: "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.

Re: Critical Vulnerability: AWS Credential Disclosure

#20

Post by DigitalBison »

trustlook wrote: post #9
mantrax4 wrote: post #6

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…

Besides AWS, so many SDKs are used client oriented design, like Dropbox and Facebook. The consequence of leaking those keys may not critical as the AWS though.

Maybe not as critical in a strict financial sense, but absolutely critical in a privacy and data confidentiality sense.
Post reply on HN