Research: On the overexposure of Amazon credentials in mobile apps

Florence Broderick    16 November, 2015
The development of mobile applications that interact with common services in mobility environments such as Amazon Simple Storage Service (S3), Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS) or Amazon Mobile Analytics is becoming more frequent.

To interact with these services, apps need to communicate with them and authenticate with some kind of credential (usually based on tokens). We have identified unsafe programming practices in the form of poor management of login credentials, which could allow an attacker to modify the behavior of the affected apps.

Identity management in Amazon AWS

Mobile app developers need their own access keys to programmatically call Amazon Services. They can use the AWS Command Line Interface (AWS CLI)  , AWS SDKs or direct HTTP calls using APIs for AWS individual services.

The latter is more common in apps communications. From the Amazon Management Console, access keys, known as access keys and secret keys can be created, modified, viewed or rotated. These access keys are valid to programmatically interact with the contents or services offered by Amazon. Apps that use these contents must therefore know the access keys.

Although there are more appropriate methods, some programmers embed this information in the app itself. If access is read-only, this can result in a bad programming practice, but not necessarily in a security problem. However, if permissions are poorly established, contents could be controlled. If, in addition, access keys are accessible by anyone analyzing the application, an attacker could modify those contents that later on would be used by the app.

If necessary measures are not taken when setting access permissions of the API keys, anyone with access to the keys could not only access the information, but modify it.

However, access keys can also be introduced into an app through a credentials file located within the APK, in clear text. This way, apps are easier to manage and maintain. This file is generated with the AWS CLI. Its default name is AWSCredentials.properties, and its format is similar to the following:

(Falso) example of credentials

With Tacyt , ElevenPaths’ Cyber intelligence Tool for mobile apps, we have searched how many apps in the different monitored markets contain a file of such type, subsequently verifying the nature of the associated credentials.

First seach in Tacyt for APKs with this kind of files

At the time of writing this report, we found 1,635 APK files containing a file of this type in our database, formed by 4.5 million apps. Those 1,635 files correspond to apps and also to different versions of those same apps (hashes) stored in our database. Unique apps (regardless of their version, and on the basis of unique package name) are actually 478 different apps distributed over different markets.

We have studied the situation of credentials and if they represent any risk.

Data analysis

These are the results obtained after analyzing the apps containing files that could potentially pose a security problem:

  • Of all studied apps, 102 are no longer in the official market and have been removed. Although removed, they still to pose a problem, since the apps remain in the installed devices, and furthermore, credentials do not stop being valid even so.
  • We have found 478 different apps containing valid credentials. 408 of them in Google Play.
  • However, the number of different access keys found in all markets is not too high: 63. This means that several of those 63 credentials are distributed between different apps. In other words, many seemingly different developers share valid AWS accounts. In particular, two different credentials are shared in 523 and 196 different versions of the apps. There are only 26 unique credentials that are not shared and that are found in a sole app.
  • 37 of the 63 access keys found remain fully operational, which means they allow the correct performance of the authentication process. The valid access keys shared have the following distribution. Among the valid access keys, one is distributed in 523 different versions of different apps.  
  • Of these access keys, we have obtained permissions (ACL) from 26 credentials. 
  • 22 access keys kept FULL CONTROL with those credentials. This means that some contents hosted on Amazon could be read, written and even edited.The rest of them allowed Write, which for practical purposes also poses a security problem.
  • The credentials found on Google Play are distributed over 408 different apps. In turn, many seemingly different developers share credentials. It is interesting to see how there is a single credential present in 74 different developers, each one with their respective apps.

Of the 74 credential-sharing developers on Google Play, it should be noted that most of them seem to be magazine publishing companies and media in general, some of them quite known. This suggests that these companies’ apps have been developed by the same team, which has somehow reused part of the resources, including the infrastructure in the cloud and, with it, the access credentials. This exchange of shared credentials between different apps that load contents hosted on a third party opens an interesting attack window, depending on the credentials permissions.

It is necessary to clarify that not all apps containing credentials have to use them. It can simply constitute a “bad practice” if using the appropriate permissions, which means that, even if it involves exposure of sensitive information, in practice it does not open any security breach or attack possibility against app users or developers.

Leave a Reply

Your email address will not be published. Required fields are marked *