Here's how 5 mobile banking apps put 300,000 users' digital fingerprints at risk
- Reference: 1662026646
- News link: https://www.theregister.co.uk/2022/09/01/mobile_apps_leaked_biometrics/
- Source link:
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 [1]research published today.
[2]
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 .
[3]
[4]
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.
[5]
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."
[6]
Here are a few examples of what the researchers found.
Sensitive info exposed
In one case, a provider of B2B services gave out a mobile SDK to its customers to integrate into their applications. It turned out the SDK contained the provider's cloud infrastructure keys, which potentially exposed all of its data — including financials, employee information, files on more than 15,000 medium and large-sized companies, and other information — that was stored on the platform.
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.
[7]Find a security hole in Google's open source and you could bag a $31,337 reward
[8]PyPI warns of first-ever phishing campaign against its users
[9]Now Oktapus gets access to some DoorDash customer info via phishing attack
[10]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 [11]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." ®
Get our [12]Tech Resources
[1] https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/mobile-supply-chain-aws
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YxDXG7Gzo0k2w6H68s2-WAAAAI8&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YxDXG7Gzo0k2w6H68s2-WAAAAI8&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YxDXG7Gzo0k2w6H68s2-WAAAAI8&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YxDXG7Gzo0k2w6H68s2-WAAAAI8&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YxDXG7Gzo0k2w6H68s2-WAAAAI8&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://www.theregister.com/2022/08/30/google_open_source_bug_bounty/
[8] https://www.theregister.com/2022/08/26/pypi_warns_of_firstever_phishing/
[9] https://www.theregister.com/2022/08/26/doordash_oktapus_phishing/
[10] https://www.theregister.com/2022/08/30/nitrokod_crypto_malware_google/
[11] https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html
[12] https://whitepapers.theregister.com/
Re: Assuming they were properly hashed
Still not good enough and terrible security practice. Worrying that 98% were iOS apps as users on that have a impression of greater security from the platform which is heavily eroded if a lot of developers tend undo a load of good work by being lazy.
The other 2%
> Worrying that 98% were iOS apps
Actually, as an Android user, I am hugely relieved to hear that.
Surely the Best Practice for Mobile Banking Apps is ...
... not to use them at all.
biometric HASHES
From the headline it reads like people's fingerprints were stolen. From reading it, what was stolen were fingerprint hashes. There will be no way to convert these back to a representation of individuals fingerprints. Bit of a clickbaity headline...
Re: biometric HASHES
There's no way of converting them back, but you could easily use the purloined hashes to work out if a person is present in the dataset. You could also use the fingerprint equivalent of credential stuffing for a brute force attack...
Re: biometric HASHES
Not if the hashes are properly salted you can't.
Blind trust?
I would hope that any software libraries, SDKs, etc. that are used when security is concerned are audited and not simply accepted as trusted.
Similarly, there should be a formal development process in place that verifies that the project's security requirements are satisfied (including that "dead code" / unused code / test code is not present).
It always surprises me that processes from the safety domain that are also of relevance to security-related projects are generally not adopted (and that "safety" and "security" are seen as being different).
Re: Blind trust?
" I would hope that any software libraries, SDKs, etc. that are used when security is concerned are audited "
They never are, primarily because they're taken on trust, and in any case the expertise required is not available at the point of use. It's even more problematic where libraries are accessed dynamically from remote repositories, as contamination at source can occur at any time. Both dynamic access to remote libraries and their contamination at source are on the increase, and this is the primary paradox of the web. Even as the demand for security grows with applications being applied to ever more sensitive purposes, actual security diminishes due to ever greater susceptibility to malicious action against the required resources.
Re: Blind trust?
How are you supposed to do the auditing?
Negligence
Difficult not to conclude that this much of this is professional negligence and in breach of data protection regulations in many countries. It's certainly in breach of AWS' terms and conditions to hard code credentials making companies liable for any data exfiltrated.
You must always authenticate before you authorise.
Imagine if this was compromised
Bland statement from the HackedBank: our bank were the subject of a sophisticated attack whereby state-backed actors discovered our hard baked credentials. A very small number of our customers were affected. We treat our customer. data and security very seriously. Blah blah blah.
Where did these fingerprints come from?
Genuine question, as the article does not make this clear. As far as I know, Apple's TouchID and FaceID don't allow apps to grab fingerprints or face scans. That data always stays on the device (which is why when you switch iPhones you always have to set it up again)
Instead, when an app requests authentication, all it will get is a "yes" or a "no" (Apparently in the case of TouchID iOS won't even tell *which* finger was presented, just that *a* valid finger was presented) but certainly not the data the scanner read.
If this is the case, then where did that fingerprint data come from?
I'm assuming Android works much the same.
"Best Practices"
And no company has ever used a lashed-together test system as a production system, or used the production system as a test system. Right?
It's Not As If Banking Is Risky Enough Already
A deposit sent via BANS from the Royal Courts to HSBC, where I have had an account since 1967 (that's correct, 1967).
HSBC said nothing to me instead it opened up a new account in my name and refused to acknowledge the existence of this transfer. It was only transferred to me (as a person) after eight months during which time it ignored my communications, denied knowledge of it, etc. If it was for the assistance of persistent civil servants and a Whistle-Blower in the HSBC call centre in India**, I would be still bereft of this transfer!
E-banking might be profitable for the banks but until they accept errors can & do occur, I suggest you check account activity regularly.
**India is world fraud country N0.2, after Nigeria.
Assuming they were properly hashed
What's the big deal ?