Rorie Hood, Security Consultant
10 mins read
Online banking has become the norm for most consumers in the UK, with 57% using it on a regular basis. That statistic is being rapidly caught up by the use of mobile banking (38%). Users are drawn in by the convenience of mobile banking and major banks are responding in kind, improving the security of their mobile banking apps on a regular basis.
There is also another benefit to mobile app banking over the traditional PC, and that’s security. Due to the increasingly secure mobile operating systems that are offered by Apple and Google, it seems that banking on your phone is significantly safer than using your laptop. This article examines the reasons behind this development and makes some suggestions to help users improve their online safety.
Mobile application banking has brought with it some interesting security benefits. Perhaps the most notable contrast between mobile and desktop banking is the security of operating systems themselves.
Typically, desktop users on a Windows PC or an Apple Mac will have administrative control over the machine. In environments where the user has administrative privileges, there is a greater risk that the user will inadvertently install malware on the device that is capable of compromising the users’ bank details.
In fact, the UK’s National Crime Agency warned in October that it believed thousands of computers in the UK were infected with Dridex malware, the majority being Windows users, resulting in criminals being able to steal millions of pounds from UK bank accounts.
On mobile platforms such as iOS and Android this threat is greatly reduced as the user does not normally possess an elevated level of control over the device.
In this highly-managed environment, the mobile Operating System is able to offer enhanced security through the following key features:
The main advantage of the mobile ecosystem is the App Store distribution model. In the App Store model, apps are downloaded from the App Store vendor. These applications are signed using the developers’ certificate. This allows the vendor (such as Apple or Google) to verify the developer that uploaded the application. As such, the user’s device is able to verify the authenticity of the application upon installation. Both Apple and Google have mechanisms in place to help prevent malware being uploaded to the App and Play stores. While not always successful, they are able to prevent the majority of malicious application that get submitted to the approval process from making it onto the stores.
One of the most useful security mechanisms that can be implemented in a mobile application is certificate pinning. This mechanism relies on the SSL public key of the web server being hardcoded into the application. The application will use this public key to verify that the SSL certificate being presented by the server it is connecting to is indeed the one that the application is expecting. If the public keys do not match, it is an indicator that the connection is being intercepted by an attacker (who is presenting the application with an alternative SSL certificate) and the application will subsequently kill the connection.
This technique would be difficult to implement in desktop banking because the users web browser would not know ahead of the connection what the public key of the web server should be. However as mobile applications are installed via an App Store, it is possible for the App developers to include the public key of the web server in the application before the connection between the application and the web server takes place. After an application has been obfuscated, and tamper protection has been applied, there is a much reduced risk that the public keys embedded in the application have been tampered with as the integrity of the application can be verified upon installation.
Application sandboxing protects application resources by limiting it to the application that resource belongs to. In the case where applications are required to share resources between them for operational purposes, secure channels for data sharing are provided by the operating system.
Often, these methods verify the developer’ signature of the applications and ensure that both applications were written by the same developer (as is the case with the iOS Shared Keychain), preventing a 3rd party application from getting access to the data. This mechanism relies on the device enforcing permission levels correctly on applications, and does not offer sufficient protection on devices that have been jailbroken.
By default, users (and applications they install) do not have administrator level privileges on the device. This restricts the functionality that apps can perform & allows the enforcement of device features such as application sandboxing & keychain storage. In order for a user to obtain administrative level control over the device they will have to go through the process of jailbreaking (or rooting) their device.
This process involves utilising a publicly known exploit in the operating system in order to gain administrative privileges.
The vast majority of mobile users do not utilise a jailbreak in order to gain root access on their device. Often, jailbroken devices are limited to enthusiasts, developers and security professionals. A jailbroken device that gets compromised can undermine the majority (if not all) of the security functionality provided by the operating system.
Features such as keychain storage, that offer adequate secure data storage on a non-jailbroken device, suddenly provide no security at all when the device is jailbroken. Many large organisations have come to terms with this as mobile banking applications have matured and now take steps to prevent their applications being run on jailbroken devices. This is commonly known as “Jailbreak Detection”. Often implemented on a best effort basis, the application will attempt to detect if it is being run on a jailbroken device and prevent the normal application execution flow.
There are many common methods of detecting if a device has been jailbroken. Some methods include checking for applications that are only ever installed on a jailbroken device (such as the “Cydia” app store on iOS devices), checking if the “su” (superuser) binary can be executed, and attempting to write to areas of the file system that only the root user would have access to.
Due to the limited number of methods that can be implemented to detect a jailbroken device, there is no fool proof mechanism. A determined attacker with enough time investment will always be able to bypass the jailbreak detection in an application, as they have control of the filesystem, syscalls etc, that the application depends on in order to perform jailbreak detection.
Many large organisations will take steps in order make it difficult for attackers to bypass their jailbreak detection. It is common that applications from such vendors put their mobile applications through source code obfuscation in order to make reverse engineering of the functionality more difficult for attackers. This technique adds little overhead to the end binary, but an attacker disassembling it will find the logic flow of the application to be substantially more complicated to understand, often featuring method names that give little context as to their intended purpose.
In addition to making jailbreak detection more difficult to bypass, source code obfuscation makes it more difficult to find vulnerabilities in the application via reverse engineering. Flaws in the application logic that would be easy for an attacker to identify in unobfuscated source code become harder to identify after source code has been obfuscated. While not a fool proof mechanism, source code obfuscation increases the time investment required by an attacker to find vulnerabilities in the application.
Some applications will go as far as to verify the integrity of their methods at runtime in order to detect if an attacker has tried to hook the methods in the application. This helps to protect against attackers who are attempting to change the logic flow of the application. Jailbreak detection is often the target of such modification, so that the app believes it is running on a non-jailbroken device. Method integrity checking requires the attack to also patch the functionality of the applications integrity checking methods to prevent it from detecting that they are patching the applications jailbreak detection routines. This can dramatically increase the time investment required by the attacker.
Mobile banking faces a different set of challenges to desktop banking. The primary difference regarding security is that mobile banking does so on a fundamentally more secure platform and ecosystem.
This does not mean the mobile banking applications are completely secure and it is worth remembering that mobile platforms bring with them their own set of development challenges and security issues. Users wishing to make use of mobile banking should do so with security in mind. In general, users should avoid attempting to perform mobile banking on a jailbroken device. While jailbroken/rooted phones provide the end user with a greater freedom of control on the device, they are often less secure, and undermine the security features that modern mobile devices provide.
This will help mitigate some of the main risks associated with performing banking actions on a mobile device. Users should pay attention to where they do their mobile banking, be wary of untrusted networks and avoid downloading banking applications from any source other than the operating system vendor’s application store.