Here's how 5 mobile banking apps put 300,000 users' digital fingerprints at risk

Massive amounts of private data – including more than 300,000 biometric digital fingerprints used by five mobile banking apps – have been put at risk of theft due to hard-coded Amazon Web Services credentials, according to security researchers.

Symantec's Threat Hunter Team said it discovered 1,859 publicly available apps, both Android and iOS, containing baked-in AWS credentials. That means if someone were to look inside the apps, they would have found the credentials in the code, and could potentially have used that to access the apps' backend Amazon-hosted servers and steal users' data. The vast majority (98 percent) were iOS apps.

In all, 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. 

Additionally, almost half (47 percent) contained valid AWS tokens providing 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 supply-chain issue, Dick O'Brien, principal editor on Symantec's Threat Hunter Team, told The Register.

We're told that the makers of these apps may not have baked in the credentials themselves, or even know that they are 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 said. 

Instead, developers rely on software libraries, software development kits (SDKs), and other third-party components which comprise the "building blocks that apps are made of," he added.

"Each one of them makes decisions about the security of a product that you ultimately end up providing to your customers. So a decision by, say, someone providing an SDK to put in hard-coded credentials could potentially impact thousands of different apps, depending on how widely it is used."

Not all of the apps analyzed by the threat hunters had a massive user base. But a deeper dive into some of the more interesting ones turned out to be "pretty alarming," O'Brien said. "What we saw, the profile of the applications and the nature of businesses that were involved in that, would certainly give you pause."

Here are a few examples of what the researchers found.

Sensitive info exposed

In one case, we're told, a B2B provider of intranet and communications services gave out a mobile SDK to its customers to use to access its platform. It turned out the SDK contained the provider's cloud infrastructure keys, which potentially exposed all of its customers' data — including financial records, employee information, and other information — that was stored on the platform. Data on more than 15,000 medium and large-sized companies were exposed.

The SDK had a hard-coded AWS token to access an Amazon-powered translation service. However, that token granted full access to the provider's backend systems, rather than just the translation tool. "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," Symantec's Kevin Watkins wrote.

• Find a security hole in Google's open source and you could bag a $31,337 reward
• PyPI warns of first-ever phishing campaign against its users
• Now Oktapus gets access to some DoorDash customer info via phishing attack
• That 'clean' Google Translate app is actually Windows crypto-mining malware

In another example of what not to do in mobile app development: the security shop found five iOS banking apps that used the same vulnerable AI digital identity SDK. 

Using third-party software for the authentication component of an app is fairly common.

As Watkins noted: "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."

However, it can also lead to leaky data. In this case, the SDK included embedded credentials that exposed users' biometric digital fingerprints used for authentication along with names and dates of birth. "Over 300,000 people's fingerprints were exposed," O'Brien said.  

Besides the banking customers' personal information, the access key also exposed the server infrastructure and blueprints, including the API source code and AI models used.

Finally, in a third example of mobile app supply chain risk, Symantec found 16 online gambling apps using a vulnerable software library that, according to Watkins, "exposed full infrastructure and cloud services across all AWS cloud services with full read/write root account credentials."  Not a good look for the highly regulated sports betting industry. 

The security firm said it notified all of these organizations about the flaws.

Why apps use hard-coded access keys

There are several reasons why these different apps baked in access keys. Some are legitimate: the app needs to download resources or access certain cloud services, such as the AWS translation service, that require authentication. Sometimes, it's a matter of a developer using dead code, or using software for testing the app and not removing it before it goes into production.

"For the most part, it's driven by a degree of ignorance in terms of what you're exposing," O'Brien said. "By using the credentials to access one resource in the cloud, you're then exposing everything else that is accessible using those credentials. It's probably a combination of a little bit of ignorance and maybe a little bit of sloppiness on the part of developers."

Organizations can protect themselves against these software supply chain flaws by following best practices for sharing and using resources from the cloud IT provider, he added.

"In particular, developers should never reuse cloud shares meant for user data with internal corporate data, and should ensure all shares are appropriately locked down with permissions designed for the data being stored," O'Brien warned. "Short-term keys limited to only the data and cloud services the app requires, nothing more, is the way to go." ®