According to security researchers, massive amounts of private data — including more than 300,000 biometric digital fingerprints used by five mobile banking apps — are at risk of theft because of hard-coded Amazon Web Services credentials.
Symantec’s Threat Hunter team said it had discovered 1,859 publicly available apps, both Android and iOS, with built-in AWS credentials. That means if someone looked into the apps, they would have found the credentials in the code and could potentially have used it to access the apps’ backend Amazon-hosted servers and steal users’ data. The vast majority (98 percent) were iOS apps.
Overall, 77 percent of these apps contained valid AWS access tokens that allowed access to private AWS cloud services, the intelligence team noted in research published today.
In addition, nearly half (47 percent) contained valid AWS tokens that provide full access to sometimes millions of private files via Amazon S3 buckets. These hard-coded AWS access tokens would be easy to extract and exploit, and reflect a serious problem in the supply chain, Dick O’Brien, editor-in-chief of Symantec’s Threat Hunter Team, said. The register.
We’re told that the makers of these apps may not have baked in the credentials themselves, or even know they’re in there: the tokens may have been introduced by a poorly designed software dependency.
“When you talk about mobile app development, most people don’t start from scratch,” O’Brien says.
Instead, developers rely on software libraries, software development kits (SDKs), and other third-party components that make up the “building blocks from which apps are made,” he added.
“Each of them makes decisions about the security of a product that you eventually deliver to your customers. So a decision by, say, someone providing an SDK to enter hard-coded credentials could potentially affect thousands of different apps, depending on how widely it is used.”
Not all apps analyzed by the threat hunters had a huge user base. But a deeper dive into some of the more interesting ones turned out to be “quite alarming,” O’Brien said. “What we saw, the profile of the applications and the nature of the companies involved, would certainly put you at ease.”
Here are a few examples of what the researchers found.
Sensitive information exposed
In one case, a B2B service provider gave its customers a mobile SDK to integrate into their applications. It turned out that the SDK contained the provider’s cloud infrastructure keys, which may have exposed all of its data — including financial data, employee information, files of more than 15,000 medium and large businesses, and other information — stored on the platform.
The SDK had a hardcoded AWS token to access an Amazon-powered translation service. However, that token gave full access to the provider’s backend systems, rather than just the translation tool. “Rather than restricting the hardcoded access token for use with the translation cloud service, anyone with the token had full, free access to all of the B2B company’s AWS cloud services,” wrote Symantec’s Kevin Watkins.
Another example of what not to do in mobile app development: The security store found five iOS banking apps that used the same vulnerable AI SDK for digital identity.
Using third party software for the authentication component of an app is quite common.
As Watkins noted, “The complexity of providing different forms of authentication, maintaining the secure infrastructure, and accessing and managing identities can be costly and require expertise to do it right.”
However, it can also lead to data leaks. In this case, the SDK contained embedded credentials that exposed users’ biometric digital fingerprints used for authentication, along with names and dates of birth. “More than 300,000 human fingerprints were uncovered,” O’Brien said.
In addition to the bank customers’ personal information, the access key also revealed the server infrastructure and blueprints, including the API source code and AI models used.
Finally, in a third sample of mobile app supply chain risk, Symantec found 16 online gambling apps that used a vulnerable software library that, according to Watkins, “uncovered the entire infrastructure and cloud services for all AWS cloud services with full root read/write account credentials.” Not a good prospect for the highly regulated sports betting.
The security company said it had notified all of these organizations of the flaws.
Why apps use hard-coded access keys
There are several reasons why these various apps are baked into access keys. Some are legitimate: the app must download resources or access certain cloud services, such as the AWS translation service, which require authentication. Sometimes it’s a case of a developer using dead code, or using software to test the app and not uninstalling it before it goes into production.
“For the most part, it’s driven by a certain amount of ignorance in terms of what you’re exposing,” O’Brien said. “By using the credentials to access one resource in the cloud, you are revealing everything else that can be accessed with those credentials. It’s probably a combination of a bit of ignorance and maybe a bit of sloppiness on the part of developers.”
Organizations can protect themselves from these shortcomings in the software supply chain by following best practices for sharing and using resources from the cloud IT provider, he added.
“In particular, developers should never reuse cloud shares intended for user data with internal corporate data, and should ensure that all shares are properly locked with permissions designed for the data being stored,” O’Brien warned. “Short-term keys limited to just the data and cloud services the app needs, nothing more, is the way to go.” ®
