This seems to be the natural outcome of Amazon's excellent customer service policy, where they have on numerous occasions[0] refunded costs for hacked instances. When they commit to that policy, they have a huge incentive to limit customer security breaches.<p>I love examples like that where a company's policies result in incentives that are so well-aligned with those of their users. Does anyone have other good examples to share?<p>[0] <a href="https://securosis.com/blog/my-500-cloud-security-screwup" rel="nofollow">https://securosis.com/blog/my-500-cloud-security-screwup</a> and <a href="http://vertis.io/2013/12/17/an-update-on-my-aws-bill.html" rel="nofollow">http://vertis.io/2013/12/17/an-update-on-my-aws-bill.html</a> are two examples.
I don't think they are inspecting the app ; they don't need to. They can see that there are a higher-than-average number of API accesses from a given platform, using the AWS Secret Key as the login credential.
Facebook does the same thing. I got a notice about an application I published years ago in March:<p>> Security Notice - Your App Secret<p>> We see that your app, XYZ, is embedding the Facebook integration’s App Secret inside the Android Play Store app bundle for your app. This is a serious vulnerability that violates our published recommendations for proper login security. Someone with access to the app secret for your app can act on behalf of the app - this includes changing configurations for the app, accessing some types of information associated with people who have granted permissions to the app, and posting on behalf of those people.<p>> To mitigate this sizable risk, we have reset the app secret for your app. If your app is mobile-only, this should not cause any issues. If it has a server-side component, there is a greater likelihood that it has caused some issues for your app that you will need to address. Going forward, please do not include the app secret in your app bundle, or disclose it publicly. You can read more about app secrets and how to secure your Facebook app here.
I understand perfectly how people end up mistakenly pushing credentials into public source repos when releasing server-side stuff. But I don't get how a seemingly sane person develops an application intended for distribution to the public which contains AWS credentials.<p>At what point in your development process do you say "I want this application, which will be distributed to unknown persons, to contain the means to control my AWS account."?
Anyone who reads the article can see that the author is drawing conclusions from conjecture.<p>"We were made aware" does not equal "we are downloading apps and inspecting them."<p>If they were doing that, that would be great! But let's not leap to conclusions.
I see nothing wrong here. They are probably doing this now because it in fact a major problem, even with large, professionally developed apps. About 8 months ago I did a brief analysis of the then-current Vine apk and relatively quickly extracted their S3 credentials (they were not stored in plain text, but close enough). Very bad idea.
MixRank analyzes mobiles apps (android and ios) and we often see apps with embedded api secrets, private keys, and passwords. It's really surprising.<p>If you'd like to send an email like this to your users, send me an email (in profile) and I can query our database and check to see if any of them are including their api keys.
I wonder how they would identify a string that appears to be an API secret, and queries their database for it. For every plausible string in every app? I guess they decompile it and find string literals of the correct length?
I will think they inspect apps based on the number of hits generated to AWS.<p>The advantages of doing this are 1) showing Amazon thinks for the customers (well, also for itself) 2) proves it has pro-actively notified the customer and done its due diligence.<p>This step could serve as a solid proof in any dispute on later security issues or/and related costs.<p>Smart, I will say.
I'm curious why some apps need API to access to AWS. What's the use case? Surely not to spin up an EC2 instance when the user clicks a button? Save files to S3? I'm not being sarcastic, genuinely curious. And what's the proposed solution suggested by AWS?
great for them. i worked for an unnamed company who was shipping AWS credentials in clients for years. worse, they were not clients that required a packaged binary (no need to decompile). it's long since patched but i can't believe no one ever sniffed that out.
We wrote a blog post that shows how you can authenticate your users and get temporary security credentials from AWS based on the user tokens to avoid putting your keys on the client (both JavaScript apps in the browser or native apps). This technique is using Auth0 so you don't have to deploy a TVM and it works with all the APIs (S3, EC2, SQS, SES, etc.). Behind the scenes what we do is generating a SAML Token based on the user JSON Web Token and exchange that for AWS Temp Credentials using AssumeRoleWithSAML AWS API.<p><a href="http://blog.auth0.com/2014/03/25/consume-aws-apis-from-the-browser-securely/" rel="nofollow">http://blog.auth0.com/2014/03/25/consume-aws-apis-from-the-b...</a>
Does Google Play have a public API for downloading APKs? Does it work for paid apps as well? (I'm not able to construct good keywords for search here: Google thinks I'm looking for an APK for the store app instead)
Well, this is very cool and an approach that some security companies are taking at the moment. "Security outside your network" they call it.<p>I'm myself working (side/pet project so far) in something similar. I don't have any working software at the moment but some "INTEL" and it is incredible how easy anyone would be able to compromise/hurt people and companies just using available information published by themselves.<p>If anyone more technical (I'm looking at you, devs!) wants to team up to create a service like this please get in touch.
I hope other developers see this and take action if they aren't properly securing cloud API keys. Data access by an unauthorized party is not something you want to deal with.
I'm being dumb. I can see that it is preferable to embed credentials for a restricted IAM acct, not your root/master AWS account.<p>But how does using a TVM improve the situation? Surely you still need to embed creds which allow the app to use the TVM? In that case, an attacker can extract <i>those</i> creds, and ask the TVM for a time-limited token any time they like.<p>How does using a TVM improve security over embedding the creds of a restricted account?
Ultimately, Web Identity Federation or Federated Identity is the only way to secure apps in walled gardens, which means aligning yourself with a virtual land Barron. I, for one, welcome our new fiefdom overlords. Everything else is just pushing new credentials through temp credentials and obfuscating it with protocol complexity.
Conjecture, and I guess you're welcome? My guess is if you embedded your Google cloud credentials in your app and it was compromised Google would be happy to bill you, terminate your account, or otherwise provide zero latitude as a customer. At least they dropped their prices, right?