The mobile app security hole that should keep bankers up at night

Researchers have found a glaring set of vulnerabilities in the ways that banks on both sides of the Atlantic establish secure, encrypted connections between their servers and customers’ mobile devices.

The transport layer security, or TLS, protocols banks use to secure online banking sessions are as baffling as they are essential. They involve the participation of multiple entities—a bank’s server, client-side validators, and security certificate authorities—all of which provide necessary reputational and cryptographic checks on the system. As complex as it is, TLS gets the job done, at least on web browsers.

But mobile applications are another story altogether. The developers who build these apps are increasingly opting for simplified implementations, and recent blunders suggest that modifying TLS for mobile financial applications is much more difficult than it seems.

In some cases, app developers are just getting it completely wrong in ways that could have detrimental consequences for customers.

chones - Fotolia

For example, researchers from the University of Birmingham in England discovered a vulnerability in mobile banking apps used by two major banks in the U.K. If exploited, the vulnerability would allow an attacker to intervene on a session and decrypt all data passing between the app and the user.

“If this attacker carries out this attack and they’re on the same network, then they’ll be able to perform any banking actions that a legitimate user would do on a mobile app in their victims’ names” and steal login information for follow-up snooping, said Chris McMahon Stone, one of the researchers on the paper, who presented his work last month at a financial cryptography conference in Malta.

Stone and his colleagues at Birmingham University are now digging into North American banking apps, to see if the same vulnerability is replicated on this side of the pond.

Separately, the consulting firm Accenture and NowSecure, a company focused on mobile app security, investigated the banking apps used by 15 major North American financial institutions and found that all of them contained at least one security flaw. TLS problems were a “recurring theme,” according to their report, released last week, “as 40% of security issues identified were mapped back to insecure communication.”

“This recurring vulnerability suggests that security around the transfer of data across communication channels is a challenge for developers and that they may be placing too much confidence in secure end-user behavior and back-end server-side communications,” the report said. It did not identify the institutions or their specific countries.

Every HTTPS-enabled website has a digital document that it presents to the browser called a security certificate. It specifies, among other things, the hostname of the server delivering the content, and a cryptographic key that it uses to set up encrypted communication with the user.

Such a document presented on its own would be useless. Without anyone vouching for the validity of the certificate, a browser would have no reason to believe that it was actually created by the website the user was trying to reach.

That’s where certificate authorities come in. This large, diverse group of companies (Symantec, VeriSign and Comodo are among the biggest names) takes on the job of vetting websites and making sure they are who they say they are. If everything checks out, a certificate authority will sign the website’s certificate. In the application reside all the keys needed to verify the signed certificates.

A properly designed banking app will check an incoming certificate to verify both that it was signed by a trusted certificate authority and that the hostname on the document is the same as the one used by the server the user is trying to reach. Stone found that some apps are missing the second check entirely.

When that was the case, he was able to obtain a valid certificate for a website under his control, convince the application that it belonged to the bank, begin a session and decrypt all the traffic coming from the user (the researchers only executed the attack on their own accounts).

In other words, for the banking apps in question, Stone and his colleagues were able to execute
man-in-the-middle attacks on TLS connections and take full control of a victim’s account.

Ironically, this vulnerability has been introduced as banks have modified their TLS implementations to make them more secure. Increasingly, banks are using a strategy called certificate pinning that restricts the number of certificate authorities considered valid from over 100 to just a handful, or even just one.

There are multiple reasons why a bank might want to narrow the field of certificate authorities it trusts. For one thing, the companies may be compromised. One high-profile case occurred in 2011, when the Dutch certificate authority DigiNotar fell prey to hackers who used their access to issue fraudulent certificates, leading to a large-scale breach of Iranian Gmail accounts.

Other certificate authorities might be inherently suspect if they are operated by governments known to censor or snoop on communications.

In light of these concerns, banks are implementing pinning to reduce the attack surfaces of their applications. But they underestimate the complexity of their design problem, said John Kozyrakis, a security consultant at Synopsys Software Integrity Group.

“We have seen that a lot of organizations do not necessarily yet understand what pinning involves and they think pinning is something that you put in place like a firewall and it just works and you don’t need to do anything like that. And it’s nothing like that,” he said. “You need to manage the pins. You need to update the certificates. You need to figure out how to handle it.”

The blame, argues Kozyrakis, does not fall squarely on the banks. Google and Apple (but mostly Google, according to both Kozyrakis and the NowSecure report) have lagged in their support and saddled developers with clumsy platforms.

“The APIs that were provided up until last year by the systems were not up to the task,” Kozyrakis said. “It was very easy to shoot yourself in the foot.”

Neither Google nor Apple was immediately available for comment.

Stone is putting the final touches on a tool for detecting hostname verification flaws that security firms could use when performing penetration tests on banking apps. But, according to Kozyrakis, avoiding this specific flaw, and perhaps others, may be best achieved by seeking help in the initial stages of development.

“The proper way to do this ... is design the software properly from the ground up,” he said.