In the last few posts, we have looked into non-technical topics like patents, SCA for corporate transactions, and the challenges of enrolment and re-enrolment within an app. Now it is time for a more technical blog post, where we go a bit more in detail on the practical aspects of how you can evaluate the security of your mobile banking app. The topics we go through in this post and the next one mirrors some of the design decisions that we made during the design of the Okay SCA solution.

In this first post, we’ll look at network attacks, aka where an attacker does not have to touch the device itself. This is often the simplest type of attack to implement, so it is a safe guess that an attacker would strike here first. A second benefit for an attacker when doing a network attack is attacking a lot of devices at the same time, or accessing a lot of accounts if the server-side protections are weak.

In a very general sense, all mobile banking apps work in the same way: A user interacts with the user interface of the app, which usually contains some kind of business logic and a stored identity of some kind. The app communicates with a network server, hopefully using some kind of encryption. Every component and link involved in the process can have one or more security vulnerability, but in general, there are either attacks on the device itself, e.g. with malware or the network infrastructure and servers, as is the topic of this post.

The first thing an attacker would do is to passively listen in on the network traffic, just to get a feel of what is happening when a user authenticates or does a transaction. There are excellent tools for this available, such as Wireshark. Simply looking at the traffic lets you at the very least know where the traffic is going (what the “endpoints” are), but today most communication also happens on top of some sort of web traffic, which Wireshark can easily decode. 

In 2020 it is unlikely that any security-conscious app is using un-encrypted traffic, so the next step is to do a man-in-the-middle type of attack, where you use a program which pretends to be the server that the app is supposed to communicate with, passing every request on to the correct server.

When testing your app for this type of vulnerability, the first step is to configure a wireless network where traffic is sent to your server instead of to the proper internet connection. On your server, you then run a “proxy” service which can pretend to be the endpoint you found with Wireshark above. A nice app for doing this is mitmproxy, which can automate much of the technical aspects. It can even automatically generate certificates that pretend to be for the right server. It won’t be the correct certificate, but if your app trusts any certificate for “secureserver.mycompany.com”, the proxy will be able to decrypt the traffic and possibly even change it. A secure app should use at least use certificate pinning to verify that it is in fact talking to the right server, but a lot of apps don’t do that. (For more on certificates, check out our latest post on KYC and Trust Anchors.)

If you’re able to use the app through the man-in-the-middle proxy and view the data transferred in clear-text, you’re halfway to having a working attack. Then it is very likely that you would be able to modify the traffic as well, such as account numbers and amounts used for transactions. Depending on the protocol you might even be able to fake the entire SCA process. 

If you’re able to create a proxy which can modify the transactions going through it to whatever you want, there are a few ways an attacker can target your app:  The simplest method is to set up a “rogue WiFi network”, but the number of users that might reach in such an attack is usually low. The second option is to attack the infrastructure, such as network protocols that mobile operators use to communicate with each other, like the “Signalling System No. 7”, or SS7.  This video is a good and practical introduction to the possibilities. Using a BGP hijack is another method that can be used as a mass-attack vector. 

The second major way of evaluating the security of an app is to look at the endpoint that you found with Wireshark above, and testing if there are any vulnerabilities in the API used to access it. From an academic perspective, vulnerabilities can be categorised into attacks on authenticity, integrity and confidentiality. 

The first type of attack is to check if the endpoint does sufficient tests of the authenticity of the communication. A way to do this is to use Wireshark and to do a “replay attack”, where you look at what happens if you send the same traffic again. An example is the initial authentication: If you can send the same network traffic again and have your app end up in a “signed on” state there are obvious issues with your security. (The right way here is to use nonces so that the same traffic can’t be reused.)

The second type of attack is to attack the integrity of the communication, which is similar to what we talked about with the man-in-the-middle attack. Basically, if you can get access to the clear-text of the communication you might be able to change the content of the message sent to the server. If your server is badly programmed it might trust the user identity provided by the app, not the one provided through a SCA process, or just assume that an end-user won’t try a transfer from an account they don’t have access to. 

A last category of attacks is to attack the confidentiality of the endpoint or messages. There are quite a few common frameworks which can leak information about the endpoint if you just query it the right way, such as looking for common method names on a SOAP service. A common tool for validating endpoints is to use Metasploit as it already has a lot of exploits and test of known exploits built-in. Using something like Metasploit to scan and evaluate the security of your public APIs is a minimum.

In the next post, we’ll talk more about how you can check if your app is vulnerable to malware running on the device itself.