Mobile banking apps put 300,000 digital fingerprints at risk • The register
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, that contain embedded 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 it to access the apps’ backend Amazon hosting 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.
In addition, nearly half (47 percent) contained valid AWS tokens that provided 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 problem, said Dick O’Brien, Editor-in-Chief of Symantec’s Threat Hunter Team. The register.
We’re told that the creators of these apps may not have baked in the credentials themselves, or even know they’re there: the symbols 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 that make up “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 insert hard-coded credentials could potentially affect thousands of different apps , depending on how much it is used.”
Not all 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 “quite alarming,” O’Brien said. “What we saw, the profile of the applications and the nature of the businesses involved, would definitely give you pause.”
Here are some examples of what the researchers found.
Sensitive information exposed
In one case, we’re told, a B2B provider of intranet and communications services released a mobile SDK to its customers to use to access the platform. It turned out that the SDK contained the vendor’s cloud infrastructure keys, potentially exposing 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 companies was exposed.
The SDK had a hardcoded AWS token to access an Amazon-powered translation service. However, this token granted full access to the provider’s backend systems, rather than just the translation tool. “Instead of restricting the hard-coded access token for use with the translation cloud service, anyone with the token had full unfettered access to all of the B2B company’s AWS cloud services,” wrote Symantec’s Kevin Watkins.
In another example of what not to do in mobile app development: the security store found five iOS banking apps that used the same vulnerable digital identity AI SDK.
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 the identities can be costly and require expertise to get right.”
However, it can also lead to leaking data. In this case, the SDK included embedded credentials that revealed the users’ biometric digital fingerprint used for authentication along with their name and date of birth. “Over 300,000 people’s fingerprints were exposed,” O’Brien said.
In addition to bank 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 those organizations about the flaws.
Why apps use hardcoded access keys
There are several reasons why these different apps have built-in access keys. Some are legitimate: the app needs to download resources or access certain cloud services, such as the AWS translation service, which require authentication. Sometimes it’s a matter of a developer using dead code, or using software to test 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 your credentials to access one resource in the cloud, you’re then exposing everything else that’s available 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 the developers.”
Organizations can protect themselves from these software supply chain failures by following best practices for sharing and using cloud IT provider resources, 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 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.” ®