Most of us, by now, have been impacted in some way by supply chain issues. An increase in the price of fuel and other items, delivery delays, and a lack of product availability are just some of the consequences of supply chain issues stemming from recent events around the world. However, in the context of software and technology infrastructure, the consequences resulting from supply chain issues are very different. Mobile apps, for example, can contain vulnerabilities introduced in the supply chain that can potentially lead to the exposure of sensitive information, which in turn could be used by threat actors for other attacks.
Mobile app supply chain vulnerabilities are often added by app developers, both knowingly and unknowingly, who are likely unaware of the downstream security impacts putting not only the app users’ privacy at risk, but sometimes putting their company and employer’s privacy and data at risk too.
The mobile app supply chain problem
Similar to the supply chain for material goods, mobile application software development undergoes a process that includes: the collection of materials, such as software libraries and software development kit (SDKs); manufacturing or developing the mobile application; and shipping the end result to the customer, often using mobile app stores.
This blog examines the type of upstream supply chain issues that can make their way into mobile apps, making them vulnerable. These issues include:
- Mobile app developers unknowingly using vulnerable external software libraries and SDKs
- Companies outsourcing the development of their mobile apps, which then end up with vulnerabilities that put them at risk
- Companies, often larger ones developing multiple apps across teams, using cross-team vulnerable libraries in their apps
In order to better understand the prevalence and scope of these supply chain vulnerabilities, we took a look at publicly available apps in our global app collection that contained hard-coded Amazon Web Services (AWS) credentials. Hard-coded cloud credentials is a type of vulnerability we've been looking at for years and have extensively covered in the past. This time, in order to get to the bottom of the supply chain impacts caused by this issue, we've looked into why app developers hard-code cloud credentials inside apps; where the hard-coded credentials are located in the apps - tracking the sequence, or chain of events leading to the vulnerability; and finally, the size of the problem and its impact.
Scope of the problem
We identified 1,859 publicly available apps, both Android and iOS, containing hard-coded AWS credentials. Almost all were iOS apps (98%) - a trend and difference between the platforms we've been tracking for years, possibly linked to different app store vetting practices and policies. In any case, we examined the scope and extent of the risks involved when AWS credentials were found embedded inside apps. We found the following:
- Over three-quarters (77%) of the apps contained valid AWS access tokens allowing access to private AWS cloud services
- Close to half (47%) of those apps contained valid AWS tokens that also gave full access to numerous, often millions, of private files via the Amazon Simple Storage Service (Amazon S3)
We will explore the type of private data exposed in the examples discussed later in this blog, but the message is clear: apps with hard-coded AWS access tokens are vulnerable, active, and present a serious risk.
Source of the problem
We then looked into why and where exactly the AWS access tokens were inside the apps, and if they are found in other apps.
We discovered that over half (53%) of the apps were using the same AWS access tokens found in other apps. Interestingly, these apps were often from different app developers and companies. This pointed at a supply chain vulnerability, and that's exactly what we found. The AWS access tokens could be traced to a shared library, third-party SDK, or other shared component used in developing the apps.
As for the remaining question of why app developers are using hard-coded access keys, we found the reasons to include:
- Downloading or uploading assets and resources required for the app, usually large media files, recordings, or images
- Accessing configuration files for the app and/or registering the device and collecting device information and storing it in the cloud
- Accessing cloud services that require authentication, such as translation services, for example
- No specific reason, dead code, and/or used for testing and never removed
If an access key only has permission to access a specific cloud service or asset, for example accessing public image files from the corporate Amazon S3 service, the impact may be minimal. Some app developers may be assuming this is the case when they embed and use hard-coded AWS access tokens to access a single bucket or file in Amazon S3. The problem is often the same AWS access token exposes all files and buckets in the Amazon S3 cloud, often corporate files, infrastructure files and components, database backups, etc. Not to mention cloud services beyond Amazon S3 that are accessible using the same AWS access token.
Imagine a business-to-business (B2B) company providing access to its service using a third-party SDK and embedding an AWS hard-coded access key, exposing not only the private data of the app using the third-party SDK, but also the private data of all apps using the third-party component. Unfortunately, this is not an uncommon occurrence, as you can see in the following case study examples.
Intranet platform SDK
We found a B2B company providing an intranet and communication platform had also provided a mobile SDK that its customers could use to access the platform. Unfortunately, the SDK also contained the B2B company’s cloud infrastructure keys, exposing all of its customers' private data on the B2B company’s platform. Their customers' corporate data, financial records, and employees' private data was exposed. All the files the company used on its intranet for over 15,000 medium-to-large-sized companies were also exposed.
Why did the company hard-code the AWS access token? In order to access the AWS translation service. Instead of limiting the hard-coded access token for use with the translation cloud service, anyone with the token had full unfettered access to all the B2B company’s AWS cloud services.
Digital identity and authentication
We discovered several popular banking apps on iOS that rely on the same vulnerable third-party AI Digital Identity SDK. Outsourcing the digital identity and authentication component of an app is a common development pattern as the complexities of providing different forms of authentication, maintaining the secure infrastructure, and accessing and managing the identities can incur a high cost and requires expertise in order to do it right. Unfortunately, in this case, things were not done right.
Embedded in the SDK were cloud credentials that could place entire infrastructures at risk. The credentials could expose private authentication data and keys belonging to every banking and financial app using the SDK. Furthermore, users' biometric digital fingerprints used for authentication, along with users’ personal data (names, dates of birth, etc.), were exposed in the cloud.
In addition, the access key exposed the infrastructure server and blueprints, including the API source code and AI models, used for the whole operation.
In total, over 300,000 biometric digital fingerprints were leaked across five mobile banking apps using the SDK.
Online gaming technology platform
Often already established companies rely on outsourcing, or partnering, with other B2B companies for their digital and online services. This allows them to quickly move their brand online without having to build and support the underlying technology platform. At the same time, by relying on the outsourced company to run the technology platform, they often have to give exclusive access to their business data. Furthermore, they have to trust that the outsourced company will protect the online private data, not to mention the reputation of the brand overall.
We found a large hospitality and entertainment company depending on another company for their technology platform, even forming a sports betting joint venture with the company.
With a highly regulated sports betting market the complexities of building and supporting infrastructure for online gambling cannot be understated. Unfortunately, by giving the joint venture company exclusive access to that part of its business, the company also exposed its gaming operations, business data, and customer data to the world.
In total, 16 different online gambling apps using the vulnerable library exposed full infrastructure and cloud services across all AWS cloud services with full read/write root account credentials.
All of the organizations whose vulnerable apps were discussed in these case studies have been notified about the issues we uncovered.
Avoiding supply chain issues
Protecting yourself from these types of supply chain issues is possible. Adding security scanning solutions to the app development lifecycle and, if using an outsourced provider, requiring and reviewing Mobile App Report Cards, which can identify any unwanted app behaviors or vulnerabilities for every release of a mobile app, can all be helpful in highlighting potential issues. As an app developer, look for a report card that both scans SDKs and frameworks in your application and identifies the source of any vulnerabilities or unwanted behaviors.
Developers shouldn’t assume that their DevOps, IT, or cloud service provider adequately protects their app users’ private and sensitive data
We encourage you to share your thoughts on your favorite social platform.