An alarming percentage of mobile banking applications for iOS fail to implement basic protections that would safeguard against man-in-the-middle attacks, session hijacking, memory corruption, and credential theft.
Ariel Sanchez, a researcher with IOActive based in Argentina, put 40 mobile apps from 60 leading banks worldwide through a series of tests that analyzed the security of their transport mechanism, compiler, user interface, storage, logging and binaries.
IOActive reported the vulnerabilities to the respective banks, Sanchez said, but to date, none of the banks have reported patching any of the security issues.
Sanchez said the most worrisome problem he discovered came during static analysis of each app’s binary code was the number of hardcoded development credentials buried in the binaries.
“This vulnerability could be used to gain access to the development infrastructure of the bank and infect the application with malware, causing a massive infection for all of the application’s users,” Sanchez said.
Sanchez said 90 percent of the applications he looked at sent users to a number of links that were not encrypted with SSL, while close to half of the apps did not validate the SSL certificates presented, putting customers at risk to man-in-the-middle attacks where an attacker could inject malicious javascript or HTML code as part of a phishing scam, for example.
“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 use to compromise the app and the customer using these apps.”
Sanchez also found serious issues in 50 percent of the apps’ iOS UIWebView implementations, in particular there were occasions where native iOS functionality was exposed where a javascript attack could be used to inject a phony HTML log-in form that could lead to credential theft. Compounding the authentication issue is the reluctance of 70 percent of the banks to require a second form of authentication, sometimes sent via SMS message.
Only 10 percent of the apps, Sanchez said, had jailbreak detection capabilities. Attackers, using a jailbroken iPhone, for example, could load any number of illicit debugging tools and find vulnerabilities on a device.
Sanchez also discovered that the apps leak information via system logs and crash reports. An attacker intercepting a crash report, for example, could learn a wealth of system information that could allow them to build targeted exploits. A similar issue was recently reported with Microsoft Windows Error Reporting, which are sent by default by the operating system to Microsoft unencrypted.
“Someone with the right skills could use this information to detect potential bugs and after some research could develop an exploit or malware to compromise the customers of the affected banking apps,” Sanchez said. “We could say that it is the first step for a potential security threat.”
Sanchez’s static analysis of app binaries revealed additional information leaks such as internal IP addresses and file system paths as well as the use of unencrypted SQLite databases to store information or the transmission of activation codes in plaintext.
The lack of encryption puts any data the app interacts with at risk, Sanchez said.
“You only need the binary of the app, and also one tool to decrypt the code and another to disassemble the code,” he said. “There is a large number of public papers where it describes how to decrypt and disassemble the code of these apps. Someone with some time and without any expertise can easily follow it.”
