Over 20k apps allowing access to enterprise data stored on Amazon S3
During the investigation of Eavesdropper, Appthority researchers noticed that apps with the vulnerability often made the same mistake with many other services. One of the most prominent third party services used is S3 (Simple Storage Service), Amazon’s cloud storage solution. With S3, developers can provision “buckets”, file storage locations hosted in Amazon’s cloud. More information on S3 buckets can be found here.
Approximately 40% of the apps analyzed by Appthority with the Eavesdropper vulnerability also have Amazon credentials exposed, including two of the case study apps from the Eavesdropper Mobile Threat Report. In total, we observed the credentials for 2,030 Amazon accounts in 20,098 apps. and validated that 902 of these accounts are active, allowing access to list 21,866 live data storage buckets. The remainder of the accounts are either no longer active, explicitly blocked bucket access or had additional security measures, or had the credentials changed or disabled.
The data exposure is much larger than just the mobile app’s resources. S3 bucket names are globally unique, encouraging them to be descriptive, and usually limited to 100 per account, which often leads to data not being properly compartmentalized. Based on the names of the buckets, credential leakage often exposes information including the developers’ Amazon infrastructure and network resources, including company information such as customers and sales data through database backups. The mobile app vulnerability, in many cases, opens the door to a company’s entire hosted network.
Below is an example of Amazon S3 credentials hardcoded in an app:
- The aws_secret_access_key (Reference 00ec7fac)
- The aws_access_key_id (Reference 00ec7fd5)
Apps with these credentials directly exposed are not the only ones vulnerable. The three attack scenarios described in the Eavesdropper MTR are also applicable here, including “side-channel” attacks where multiple apps reuse a single bucket, and “historical” attacks where the app is updated to remove an exposed credential, but the credential is not changed or otherwise secured.
Appthority has contacted Amazon with details of the vulnerable apps and associated accounts, and is working with them to resolve the problem.
Key Differences in Data Exposure
Hardcoded credentials for services such as Twilio expose well structured data via a REST API. In the case of Eavesdropper, this includes text/SMS metadata, call metadata, billing information, and recordings. Often the apps using third party services need to expose richer data, such as account user avatars, documents, images, and locations. Commonly this was done through storing the richer data in Amazon S3.
Unlike Twilio, Amazon S3 is almost entirely unstructured. For most purposes, developers can store any type of data. In the vast majority of cases, where the Amazon credentials were proven to be active, our research found that the data stored was very likely not limited to that created or used by the mobile application, based on the bucket names.
Since the only way to validate S3 data is to download and analyze it, we are limiting our analysis to the metadata – i.e., the S3 bucket names – and the numbers describing the scope of the vulnerability. The data leakage from hardcoded credentials for other third party services is just a drop in the bucket compared to S3.
Out of respect for data privacy, we chose to scan bucket names for keywords suggesting they may store sensitive data. As S3 bucket names are globally unique, we are partially redacting the names to avoid developer identification.
Buckets frequently referenced data stored related to other Amazon services. This might allow an attacker to gain access to additional services that the developer has set up on Amazon’s network.
19 buckets reference Athena, e.g:
38 buckets reference EC2, e.g.:
503 buckets reference elastic-beanstalk, e.g.:
S3 is a frequently used service for storing user data generated by an app. While many buckets describe the type of data, some also include additional information about the platform that generated it.
86 buckets reference Android, e.g.:
210 buckets reference iOS, e.g.:
72 buckets reference iPhone, e.g.:
Backup and Databases
583 buckets reference backup, many including the name of database software or a product, e.g.:
Database software includes MySQL, CassandraDB, Couchbase, DynamoDB, Redis, and MongoDB. Services include Elastic Beanstalk, and company name mentions include Atlassian. Note that these are likely backups of these databases, services, or software products, a mistake on the part of the developers and administrators, not the makers of these technologies.
Additionally, 11 buckets reference Elasticsearch, e.g.:
19 buckets contain “credentials” in the name, some implying that they are for production services, e.g.:
Obfuscated or generic names may hide the nature of some data, but others are labeled more clearly. Looking for a collection of interesting terms finds a number of buckets that likely contain sensitive data.
61 buckets referencing VPN, secret, privacy, security, secure, kubernetes, e.g.:
68 buckets reference email, e.g.:
89 buckets referencing chat or dating, e.g.:
What To Do Now
Much like Eavesdropper, remediation of this data exposure is difficult, relying on the understanding and cooperation of the app developers and requiring them to take multiple actions. To fix the problem, a developer must both update their apps to stop using hardcoded credentials, and also change the credentials that have been compromised. If the credentials are changed without an app update, it is very likely the app will stop working. If the credentials are removed but not changed, the future app versions will be susceptible to historical attacks.
Unlike Eavesdropper, the credentials here may give a direct line into many additional assets hosted in Amazon’s cloud, requiring a far more substantial amount of work to secure those (supposedly) internal services. These numbers and examples represent only a small amount of what is available to download and analyze for an attacker with no restrictions.
The best approach for an enterprise is to identify vulnerable apps in their environment and determine whether the data exposed by the app is sensitive. Not all conversations involve confidential information and the nature of the app’s use in the enterprise may not involve data that is sensitive or of concern.
There may not be much that can be done about data already exposed. However, a lot that can be done to protect future exposures, including either addressing and confirming the fix with the developer or finding an alternate app that has the same or similar functionality without this vulnerability. In all cases, the enterprise should contact the developer to have them delete exposed files.
Appthority customers have built-in protection for this vulnerability and can create policies to detect apps with exposed Amazon credentials. We also recommend customers encourage employees to delete vulnerable apps and install non-affected apps instead. Employees can also use the Appthority Mobile Threat Protection App to search the Apple App Store or Google Play for compliant apps to avoid a “hit and miss” approach to finding apps with messaging and recording capabilities that aren’t vulnerable to this vulnerability.