Two years ago, Ariel Sanchez, a researcher at security assessment company IOActive, published a report on the sort of security you could expect if you were doing your internet banking on an Apple gadget.
The answer, sadly, turned out to be “Very little.”
Two years later, the answer’s a bit better, but it’s still pretty sad.
The good news: over the past two years, more banking apps that run on iOS have begun to protect data better and fend off man-in-the-middle (MiTM) attacks by properly validating SSL certificates or removing plaintext traffic.
The bad news?
Well, how about you get a cup of coffee and pull up a chair.
Plenty of apps are still storing insecure data in their file systems, and many are still susceptible to client-side attacks.
For this year’s research, Sanchez again looked at 40 mobile banking apps, mostly in the continents of Europe, America and Asia.
He didn’t detail the vulnerabilities he found or how to exploit them, but he did contact some of the affected banks to report the issues.
What he found was that few of the mobile banking apps he checked out provide authentication that goes beyond username and password.
Sanchez said that overall, security has improved since he researched banking apps in January 2014, but it hasn’t improved enough, given that many apps remain vulnerable.
Specific findings:
- 12.5% of the apps didn’t validate the authenticity of the SSL certificates presented, making them susceptible to MiTM attacks.
- 35% of the apps contained non-SSL links throughout the application. This allows an attacker to intercept traffic and inject arbitrary JavaScript/HTML code in an attempt to create fake login prompts or similar scams.
- 30% of the apps didn’t validate incoming data and were vulnerable to JavaScript injections via insecure UIWebView implementations. allowing client-side attacks.
- 42.5% of the apps provided alternative authentication solutions to mitigate the risk of leaking user credentials and impersonal attacks.
- Related to client-side information exposed via system or custom logs, 40% of the apps still leak information about user activity or client-server interactions, such as requests or responses from the server.
In 2014, Sanchez had found that 70% of the apps offered no support at all for two-factor authentication (2FA).
That number has since shrunk to 57.5%, which is a step in the right direction.
But that’s still an awful lot of banks that aren’t bothering with the extra security users get when they have to do something like punch in a one-time passcode, sent via SMS (text message), whenever they try to log in.
But the still-concerning lack of 2FA once again pales when compared to the problem of not validating SSL certificates.
Two years ago, 40% of the apps accepted any SSL certificate for secure HTTP traffic.
That’s down to 12.5%, which is another step in the right direction.
HTTPS certificates rely on a chain of trust, and validating that chain is important, given that it signals that a Certificate Authority has vouched for somebody who claims to own a site.
The chain of trust stops anyone who feels like it from blindly tricking users with a certificate that says, “Hey, this is the banking site you’re looking for, trust us!”
According to IOActive’s recent report, one in eight (12.5%) of iOS banking apps still simply don’t produce any warnings when faced with a fake certificate, because they didn’t check whether the certificate had been vetted or whether it was a home-baked piece of bogus.
You can feed those apps any certificate that claims to validate any website, and the app will blindly accept it.
So, if the banking app is misdirected to a phishing site, for example while you’re using an untrusted network such as a Wi-Fi hotspot, you simply won’t know.
We’ve seen multiple SNAFUs in financial apps related to not checking certificates.
For example, in July 2014, the popular Bitcoin wallet Coinbase was found to have a weakness in its Android app, having to do with how the app handled HTTPS certificates, that could allow an attacker to steal authentication codes and access users’ accounts.
It’s not just banking apps that get this wrong.
Other apps that fumble HTTPS have included Pinterest’s iOS app and Microsoft’s iOS Yammer client, both of which failed to give warnings about fake certificates when Dutch security company Securify checked them out in April.
Image of iPhone courtesy of ymgerman / Shutterstock.com.
teejayuu
One out of ten = 12.5%. It’s either 10% or 125 out of 1000.
Paul Ducklin
12.5% is indeed “more than one in ten,” but for clarity I have changed it to “one in eight.” (I have also made the verb plural, because in this context, “one in N” refers to many apps – you can’t take “one” on its own as the subject of the sentence :-)
Brad
So, exactly how are these problems with iOS? iOS provides the mechanism to alleviate and/or eliminate all of these issues, yet the developer chose not to employ them. This appears to be an example of headline grabbing to generate clicks. The indictment should be levied at all the developers, not iOS as the headline suggests.
Paul Ducklin
To be fair, the headline starts with the words “iOS banking app security,” not “iOS security” :-)
Nevertheless, you *can* argue that iOS (by which I mean Apple) is in the frame here, at least a little. After all, Apple will only let you install apps that have passed its own App Store vetting process. And you might reasonably assume that vetting includes some sort of security review, especially for banking apps.
George
Do these risks apply if you are banking at home with an Ipad on a secure wifi network?
Paul Ducklin
Any app that makes secure connections to a remote site but doesn’t check the security certificate used by the other end can be tricked along the way, because a crook can sit along the network path somewhere and pretend to be the bank, and the app simply won’t notice that it is communicating with an imposter.
(Ironically, the connection will be securely *encrypted*, so other crooks can’t listen in while you are being fleeced by the first guy :-)
A Man in The Middle (MiTM) attack is often easiest if you can hack a user’s local Wi-Fi, because it puts you closer to your victim, and may well be the softest target along the way…but even if he’s using his own mobile phone’s 3G connection and avoiding Wi-fi entirely, a MiTM is possible.
Checking HTTPS certificates properly is a vital weapon against MiTMs, and if I may use a double negative, it should never not be done.