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?
 https://securosis.com/blog/my-500-cloud-security-screwup and http://vertis.io/2013/12/17/an-update-on-my-aws-bill.html are two examples.
I really like their customer service and hope it stays how it is. I think if Walmart or insert big box company here did stuff like that, people would shop there more. Look at Nordstrom's with their insane refund policy (in the customer's favor). I think Costco does something like this as well, but I'm not a cardholder.
Facebook at that point had a huge incentive to avoid those accounts from being taken over by spammers.
Also, Amazon would use Aho-Corasick if they were really in the mood for violating the Google Play TOS.
It's more likely that they have an alert when the secret key is used to access an account from many different IP addresses, and looking at the user-agent string in the HTTP headers probably pointed them towards an Android app.
It wouldn't be too hard for them to then look to see who owns the AWS account and then search for that person's name in the Android app store.
> Security Notice - Your App Secret
> 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.
> 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.
You would provide a list of secret strings, and ask to have them monitored on search engines but also from mobile applications, browser extensions, published JARs etc.
But seriously, treat them like passwords.
Don't have the service store the secrets, have the service store hashes of the secrets with a regex for prefiltering (because hashing every word everywhere would be prohibitively expensive).
Why not? You can use the service to make sure it doesn't leak its own secrets so it's safe ;-)
But seriously yes I really like your approach.
You could even provide a second set of API to do the opposite: given a block of text see if there's any sensitive string inside. Google & co could use it before publishing an app in their Store.
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."?
(And more often than not, they get there all by themselves -- such people usually appear on my radar asking questions showing they've figured out for themselves that it's a bad idea, they just need help turning that knowledge into practice.)
If you're using a web services API from a 3rd party that requires developer authentication keys you may be storing those keys in the code because there's not a great alternative.
It's not an "alternative", it's the correct solution.
In fact, you still have to do a lighter-weight version of it with AWS -- you need an API to generate and hand out the restricted keys to your apps.
With a few very rare exceptions, you don't use third-party APIs as a complete substitute for building your own services, you use them to make building your own services easier.
For example the push notifications SDK from Urban Airship and app analytics SDK from Flurry depend on having credentials stored in the app.
These examples are not unique to them. I don't disagree that it's wrong, but I don't know how to work around this to be candid.
This was implemented deliberately and with full knowledge of managers and developers.
Stuff like this happens....
"We were made aware" does not equal "we are downloading apps and inspecting them."
If they were doing that, that would be great! But let's not leap to conclusions.
That's not conjecture.
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.
False positives (people who are legitimately using AWS credentials from their phone for some reason, or somebody who is legitimately using AWS credentials from their computer but with an incorrect useragent for some reason) would cause an inconvenience as time is wasted to inspect it, but ultimately little harm would be done.
False negatives (improperly using AWS credentials but with a useragent that looks reasonable) would not be a deviation from the status quo.
You don't need 0% false negative and false positive rates to make this sort of sanity checking worthwhile. Even if you only find a few of the many instances of improperly used credentials, you're better off than if you had done nothing.
(Of course there is the issue of correlating misused credentials with the specific application that is misusing them. I don't know how that is done if they are basing their investigation off of useragents.)
No intention to misguide. I think it's completely accurate. They downloaded my app, inspected it, found AWS credentials and emailed me as a result.
Amazon surely has automated this with monitoring. I doubt they ever scan Google Play and download the APKs and scan them. Not only is that extremely wasteful it's most definitely violating the Google Play terms of service.
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.
This step could serve as a solid proof in any dispute on later security issues or/and related costs.
Smart, I will say.
AWS supports temporary access keys, and one of the recommended solutions is to have an API which generates temporary credentials for a specific task that will expire shortly after.
Heres a link http://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingSessi...
- Store/retrieve state in/from DynamoDB or RDS
- Pull an object from S3
- Send an SNS notification
- Add a message to an SQS queue
- Dispatch email via SES
1) Client: "Hey, I want to upload a file."
2) Server: "Okay, here's a temporary key good for the next <n> minutes. The file has to be named <blah> and can't be more than <x> MB long" (there are other restrictions you can set, too, IIRC)
3) Client posts the form to S3 including the temporary key as a field.
There's no "public API" but have fun: https://github.com/kanzure/googleplay-api
(because otherwise how does Google Play itself participate in downloading apps?)
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.
If anyone more technical (I'm looking at you, devs!) wants to team up to create a service like this please get in touch.
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 those creds, and ask the TVM for a time-limited token any time they like.
How does using a TVM improve security over embedding the creds of a restricted account?
In one case directly (via an IAM limited account), in another via a token they can request. In both cases, the acct is limited to one specific AWS resource. In both cases, the creds can be revoked centrally. In both cases the creds are embedded in the app.
Smart people who build these things (AWS) seem to think a TVM is a better solution. I don't understand why.