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?"
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.
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.
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?
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?
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.
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.
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...
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.
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?
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.
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)
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.
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.
I don't get why this is necessary. Is there no server backend in these cases? I don't do much mobile development, but I would just generate a random token and register that with my server, like a cookie.
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?
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.
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.
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.
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...
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.
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.
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.
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.
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.
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! :)
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.
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?"