AWS AccessKeyId and SecretKey in mobile app

Question

I have a security question around setting up a mobile app with AWS as a backend. To get started with the mobile SDK you need an awsconfiguration.json, which contains AppClientId and AppClientSecret. Though according to the documentation, it says best practices are to "Manage your access keys as securely as you do your user name and password.". Furthermore if you were to look inside an IPA/APK file you would easily be able to extract these keys. My question is - does this really matter? What are the security risks? I know they are used to sign requests, so could anyone use these keys to sign arbitrary requests? I have the user pool setup to only allow an authenticated user to invoke a lambda function.

Answer 1

YOUR QUESTIONS

To get started with the mobile SDK you need an awsconfiguration.json, which contains AppClientId and AppClientSecret.

From the moment you ship a secret in the binary of a mobile app, you must consider it as belonging to the public domain, thus not a secret anymore, because it's up for grabs by attackers, and subject to be reused and abused in order to make requests to your backend in behalf of your mobile app, the what in the request, and your authenticated user, the who in the request.

The list of open source and paid tools that make easy to attack your mobile app is endless, but you can see a list of a few of them in my personal Github gist.

Furthermore if you were to look inside an IPA/APK file you would easily be able to extract these keys. My question is - does this really matter?

Depends in how much you value the data that can be delivered through your backend endpoints,and how much money you are willing to pay in AWS bills.

Has you say, secrets are easy to find by static analysis of your mobile app binary, but you can make them much more hard to find, and in this Github repo for a simple Android demo app, you can see here the use of native C code to hide the API Key. You can find more info in the official docs from Google, here and here.

What are the security risks? I know they are used to sign requests, so could anyone use these keys to sign arbitrary requests?

Even if the above JNI technique may deter a lot of less skilled attackers from stealing your AWS secrets, you must bear in mind that during runtime an attacker can use an instrumentation framework, like Frida, to hook into your code and extract any secret from it. So no matter how you hide it, even if encrypted, the attacker just needs to find the function that returns or uses the secret unencrypted to be able to extract it, and send it to a remote control server, from where they can reuse it to sign the requests to your AWS backend on behalf of your mobile app, therefore spoofing what it's making the request, thereby the reply to your question it's yes.

I have the user pool setup to only allow an authenticated user to invoke a lambda function.

This user pool will identify the authenticated user, by other words the who in the request, but it is not able to identify/authenticate what is making the request.

Think of the what as if the request is being made by your genuine mobile app, exactly as you uploaded it to the app store, or it's a modified version of it, one being instrumented by Frida or similar framework, or its a request from Postman or Curl.

POSSIBLE SOLUTION

I would recommend you to use the AWS API gateway in conjunction with a Mobile App Attestation solution to identify/authenticate what is making the request in behalf of the who, your authenticated user, and as already suggested, I would use AWS STS tokens for the authenticated user:

You can use the AWS Security Token Service (AWS STS) to create and provide trusted users with temporary security credentials that can control access to your AWS resources.

GOING THE EXTRA MILE

I always like to recommend the excellent work and effort that OWASP puts in helping developers with security of their applications, therefore I would recommend you the Github repo OWASP - Mobile Security Testing Guide:

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.

Answer 2

You need to secure it in two steps

1) you need to create a logic to encode and decode your credentials

Best Place to Store Included AWS Credentials in an iOS Application

2) now the SDK allows passing a JSONObject containing the configuration from the awsconfiguration.json file. You can store the information in JSONObject in your own security mechanism and provide it at runtime through the constructor.

https://github.com/aws-amplify/aws-sdk-android/issues/711

Answer 3

If you hard code IAM keys into your application (which is generally not advisable), do it with the assumption that anyone in the world will be able to use these credentials. Lock those permissions down to the point where you could comfortably post them to reddit.

The real answer is to use AWS cognito identities to generate STS tokens for a given role, and have the role with the permissions you need. This allows you to have an audit trail (of sorts) for each individual user. It allows you to disable registration or kill the permissions of individual users without breaking the app for everyone else. It allows you to have different users have different permissions in much more controllable and scalable way.

The problem with hard-coded API keys in your app is that you can't granular revoke permissions if you discover a vulnerability or abuse without possibly breaking the app for everybody. You can't rotate the API keys without pushing out a software update (and how often do your users update, really?). And most of all, you can't track requests at all, you just know when the API keys are abused (and I think cloudtrail will give you the calling IP address if you can make use of that), and any change you make will affect all of your users immediately.

There is documentation here with example apps and quick start guides to get you up and running with Cognito: https://aws.amazon.com/cognito/dev-resources/