MITM Vulnerabilities Found in Mobile Banking Apps

A team of researchers has found issues with the validation of TLS certificates for mobile banking and other security-focused applications that could allow man-in-the-middle (MITM) attackers to decrypt their traffic. Some of the apps are from high-profile financial institutions and are used by millions of people.

The fact that many mobile applications don’t properly validate TLS certificates has been shown in the past by other studies that analyzed large datasets. However, researchers from the University of Birmingham in the UK wanted to know the prevalence of such errors across high-security applications such as those used for mobile banking, stock trading, cryptocurrency and VPN.

Given their sensitive nature, these apps are created by security-aware developers and some of them use certificate pinning, a technique that limits the certificates they accept and trust. This also makes it difficult for researchers to analyze their certificate validation practices at scale without actually buying hundreds of valid certificates.

However, the University of Birmingham researchers have developed a method that allows such large-scale testing to be performed for free and they built a testing framework that will be released under a Creative Commons License.

For their test, the researchers chose 400 apps—250 Android and 150 iOS—by selecting the top 20 apps in different security-sensitive categories from the U.S., UK, Belgian and Indian versions of the app stores. After using their framework to analyze their apps, they found 24 applications that failed certificate hostname verification.

Hostname verification is an important part of validating a certificate. Without it, attackers can intercept connections from a client to a TLS server and present a certificate issued for a totally different domain. If the client accepts that certificate, the attackers are able to decrypt its traffic, which can include sensitive information such as login credentials.

Out of the 24 applications, the researchers determined that six banking apps from developing countries accepted self-signed certificates, which is an even more serious issue because attackers can easily generate those. Nine other apps accepted certificates for any hostname as long as they had been issued by a publicly trusted certificate authority (CA). Such certificates also can be obtained for free from CAs including Let’s Encrypt.

The remaining nine apps that failed to validate certificate hostnames used certificate pinning, which means they checked that the presented certificates were issued by a particular CA.

Certificate chains are composed of a root CA certificate that’s trusted by operating systems, one or more intermediary certificates signed by that root CA and a domain or “leaf” certificate signed by one of the intermediaries. Developers can pin any of the certificates in the chain in their apps, but pinning leaf certificates is not very flexible because every time the domain’s certificate changes, the app needs to be updated.

Understanding that limitation, most app developers pin either a root certificate or an intermediary certificate, which provides some protection against cases where one of the many CAs trusted by an OS by default is compromised and attackers can obtain certificates for any domains they wish. With pinning, to be trusted by an app attackers would need to obtain a fraudulent certificate from the particular CA trusted by that app.

The fact that nine apps used certificate pinning but failed to validate certificate hostnames was somewhat unusual, because clearly their developers cared enough about security to use pinning—which is not very common—in the first place. Moreover, some of those apps were from large organizations including Bank of America and HSBC (five apps). The rest were from Meezan Bank, Smile Bank and TunnelBear VPN.

The researchers decided to reverse-engineer the apps and determine why they failed to validate hostnames. They found that most of the errors were caused by a misunderstanding of implementation subtleties in third-party certificate validation APIs such as the SSLSocketFactory object from the Apache HttpClient Java Library.

“Clearly, the abundance of pinning implementation options available to developers has played a role in causing these flaws to be made,” the researchers concluded. “Platform providers can make this less of an issue by providing standardized implementations with clear documentation. To this end, Google has introduced Network Security Configuration in the Android 7.0 SDK. This provides a easy way to configure certificate verification, including the ability to specify certificate pins and associated hostnames in an XML file. If app developers make use of these standard implementations, instead of rolling out their own or using third-party libraries, these errors will be much less likely to occur.”

Lucian Constantin

Lucian has been covering computer security and the hacker culture for almost a decade, his work appearing in many technology publications including PCWorld, Computerworld, Network World, CIO, CSO, Forbes and The Inquirer. He has a bachelor’s degree in political science, but has been passionate about computers and cybersecurity from an early age. Before he chose a career in journalism, Lucian worked as a system and network administrator. He enjoys attending security conferences and delving into interesting research papers. You can reach him at lucian@constantinsecurity.com or @lconstantin on Twitter. For encrypted email, his PGP key’s fingerprint is: 7A66 4901 5CDA 844E 8C6D 04D5 2BB4 6332 FC52 6D42

lucian-constantin has 58 posts and counting.See all posts by lucian-constantin