Many apps use third-party code that banks do not analyse deeply enough
Many banks not interested in fixing the problems, says security researcher
MOBILE banking apps are becoming increasingly popular, especially in Asia. The number of mobile banking users in China reached 150 million in 2012, accounting for more than 40% of mobile banking users worldwide.
Major commercial banks saw more than 100% growth in mobile banking users in 2012, and more than 300% growth in mobile banking transaction value.
According to Bank Negara Malaysia statistics, as at end-June 2014, mobile banking subscribers numbered 5.1 million, representing 16.9% of the population and 11.8% of mobile subscribers in the country.
More and more banks are offering mobile banking applications to their customers to meet demand for accessibility.
However, it’s not always done deal when it comes to security. Speaking to Digital News Asia (DNA) on the sidelines of the Black Hat Asia security conference in Singapore, Paul Irolla, an IT engineer working at the ESIEA (C + V)^O Lab in France, pointed out that a lot of trust and personal information gets fed into these banking apps.
“We feed these mobile apps with passwords, private information, and more critically, access to our money. Do those applications protect our private life? Are they containing vulnerabilities that could be exploited by attackers?” he posed.
It was this line of questioning that formed the basis of his research and presentation entitled (in)Security of Mobile Banking, conducted with colleague Eric Filiol, the head of Operational Cryptology and Virology at ESIEA (École Supérieure D'informatique, Électronique, Automatique), the French engineering school in computer science, electronics and control science.
READ ALSO: Partnership the key to combating cybercrime: Interpol
Irolla said that if there was one recurring issue, it was the fact that many of these applications use third-party code with no deep analysis by the bank into what the code really does.
“In many cases, the app will make plain text requests, which can be modified by a third party. It’s a recurring problem where via the modified text, a hacker can then gain access and control the phone through the app,” he said.
Irolla highlighted some of the mobile banking apps that have been analysed to date during his presentation, all of which were on the Android platform and available via Google Play.
JP Morgan Access application, which has been downloaded between 10,000 and 50,000 times according to Google Play statistics, uses a framework to check if the mobile device is infected with malware.
“But the way they do it is by sending shell commands to the phone on the fly. It may seem innocent but the fact is, that it is still a remote shell and that’s a kind of backdoor that hackers could exploit,” Irolla said.
Irolla (pic) said that technical details were sent to the bank in December 2014, but there has been no news since, with the vulnerability still active and nothing corrected.
“In fact, JP Morgan could control a user’s phone if it wanted to. I don’t think it does, but the option is there,” he added.
In the case of the Bank of China (Hong Kong)’s mobile application, which has been downloaded between 100,000 and 500,000 times, Irolla found that the app checks for available updates regularly.
A link to the official market is sent whenever a new update is available for the app to download. Other navigation links loaded up the app can also be received.
The problem? The entire process is done entirely on HTTP, and not the more secure HTTPS protocol.
“This opens up the user to attack via social engineering means, where an app installation request or web page link seems to be from the bank but in fact could be malware,” said Irolla.
“There is also a gap with a few banking apps where HTTPS is used only for connecting to the banking account, but is not applied to other functionalities in the app itself,” he added.
Asian banks boast higher vigilance
But it’s not all doom and gloom, with Irolla sharing that the overall security awareness of Asian banks seems superior to what he has observed in European and American banks.
“In particular, the use of custom obfuscation, security routines on the native layer, and custom trusted SSL (Secure Socket Layer) root CA (Certification Authority) is prevalent and shows a significant care for security,” said Irolla.
“Therefore the analysis was much harder than what we performed for Western banks apps – about 50% of them blocked my dynamic analysis tool so I couldn’t get much insight into the apps,” he added.
Irolla pointed out that of all the Asian banking apps analysed, only two held any real vulnerabilities, namely the Bank of China (Hong Kong) and the State Bank of Mongolia.
“When you have unencrypted communications, someone can modify it and someone will exploit it,” he said.
He said that most of the banks have been contacted by the team to provide, at no cost, all the technical details related to security vulnerabilities it discovered – even before the team first presented its findings at the Chaos Communication Congress last December.
“Up to now, only a very few have answered and only a few like BNP Paribas are currently correcting part of the problems we reported.
“It makes it seem like a wasted effort on our part, with many banks not interested in fixing the problems. So now we do the presentations first, and then expect the bank to contact us for the technical details – we don’t have time to waste,” he added.
Asked what advice he’d give to banks regarding the development of their mobile banking apps, Irolla said that more analysis of their own apps must be done.
“Use less bloated code, less third-party code, and control it – you have to know exactly what the app does,” he added.
Irolla said that the ESIEA team intends to cover all banking apps available in the global market, with plans to extend its analysis to other app categories such as games, email clients, and security tools.
“Just having malware detection is not enough – you need malware detection, vulnerability detection, user tracking information insights, and information leakage detection to really say ‘I can trust this app’,” he said.
In addition, as part of his doctoral thesis, which he began in January, Irolla plans to further improve the analytical tools initially developed for this project by incorporating advance mathematics and algorithms.
But among the conclusions that can be drawn from the research conducted so far is the fact that mobile banking apps are “far from being totally clean,” and beyond a few cases of vulnerabilities, it appears that users’ privacy is not the priority of developers or outsourced parties.
“The bank apps market is not mature and has developed too quickly. Functionalities take precedence over security and users’ fundamental rights for privacy and data confidentiality,” he said.
“In addition, it is very difficult to identify a visible contact point to report security issues,” he added.
It is not just the banks that have a role to play in ensuring privacy and security. Irolla noted that all the tested apps were available via Google Play, which he argued illustrates that Google Inc “does not perform security analysis for apps at all.”
“User privacy is clearly not a priority; Google has the power to force developers to do a better job when it comes to securing apps,” he said.
Irolla’s message to end-users? “Use open source apps whenever possible, and if you’re really concerned about security, stick to using your desktop for banking for now.”
“Your phone contains a lot of personal information. In fact is probably the single device that contains the most personal information a person can have, and you need to be more careful with it than any other device,” he added.
Malaysia among countries most hit by e-ban king malware: Trend Micro
Trojans out for your credit card data and money, warns Kaspersky
Mobile penetration vs banking penetration = APAC m-commerce growth: Frost
Mobile advertising up, m-banking in ho-hum stage: BuzzCity report
For more technology news and the latest updates, follow us on Twitter, LinkedIn or Like us on Facebook.