Dear iPhone/iPad device owners, do you use mobile banking apps? If so, then you might like to know that most of the iOS mobile banking apps for the top 60 leading banks are miserably insecure; in fact, most are leaky messes that leave users vulnerable and at risk of attack.
IOActive Labs researcher Ariel Sanchez tested 40 mobile banking apps from the “top 60 most influential banks in the world.” Initially, Sanchez was skeptical about finding flaws in iOS banking apps, but he soon found out that many of the banks failed to implement basic security protections . . . even after being notified of vulnerabilities.
Although Sanchez doesn’t delve into specific vulnerabilities found, or show how to exploit the apps, he tested the security of 40 iOS mobile banking apps for 40 hours. All of the apps allowed installation on a jailbroken iOS device, something the apps should detect; Sanchez suggested anti-jailbreak protection. The following tests were conducted on the client side of each app: transport security; compiler protection, UIWebViews, insecure data storage, logging and binary analysis.
Transport security tests included determining if sensitive info is sent in plaintext, if the session is secure, and if SSL certificates are properly handled. This is stuff you probably don’t consider, but instead take for granted that the right security is built into the app. However, Sanchez found:
40% of the audited apps did not validate the authenticity of SSL certificates presented. This makes them susceptible to man-in-the-middle (MiTM) attacks.
“I think that more of these mobile banking apps are using non-SSL links because, in some cases, they don’t see how all these non-SSL links can be used to compromise the app and the customer using these apps,” Sanchez told Threatpost.
Even worse, he found hardcoded credentials in the code. “By using hardcoded credentials, an attacker could gain access to the development infrastructure of the bank and infest the application with malware causing a massive infection for all of the application’s users.”
Although you hear a lot about multi-factor authentication, 70% of the apps offered no alternative authentication solutions to help “mitigate the risk of impersonation attacks.”
Sanchez explained the other black box analysis, which resulted in:
A new generation of phishing attacks has become very popular in which the victim is prompted to retype his username and password “because the online banking password has expired”. The attacker steals the victim’s credentials and gains full access to the customer’s account.
Sanchez showed the following example of vulnerable UIWebView implementation in a banking app; it could allow a fake HTML form to be injected and thereby trick the user into entering his or her username and password, which could be sent to an attacker’s malicious site.
He also found, “Internal functionality exposed via plaintext connections (HTTP) could allow an attacker with access to the network traffic to intercept or tamper with data.” Another 20% of the apps sent the activation code in the clear; while that may not sound too ominous, Sanchez explained that “if attacker intercepts the traffic he could hijack a session and steal the victim’s account without any notification or evidence to detect the attack.”
Sensitive information was exposed in many of the log files, like crash reports. At first blush that might not seem so bad, but think again along the lines of how the NSA exploits unencrypted Windows crash reports to learn "information on security holes that might be exploitable for planting malware or spyware on the unwitting victim's computer." The spooks use it so often that some NSA snoop created this internal slide.
About that sensitive info exposed in iOS log files, Sanchez warned, “This information could be leaked and help attackers to find and develop 0day exploits with the intention of targeting users of the application.” The sensitive info was disclosed via the Apple system log for most of mobile banking apps.
Yet another insecure design problem, according to Sanchez included:
After taking a close look at the file system of each app, some of them used an unencrypted Sqlite database and stored sensitive information, such as details of customer’s banking account and transaction history. An attacker could use an exploit to access this data remotely, or if they have physical access to the device, could install jailbreak software in order to steal to the information from the file system of the victim’s device.
Although he didn’t name the 60 leading banks, IOActive's Sanchez did report the vulnerabilities he found to some of them. Sadly, none of the banks bothered to patch the security issues as of yet. If the banks blow off the risk, should you? None of this is a flat out red alert, but if an attacker collected what is leaked, then he or she could get their head wrapped around the “internal layout of the app and server-side infrastructure” before launching attacks that target both.
You can read more in-depth analysis on IOActive.