About mobile application security

Categories:  eschecker

An increasing number of mobile applications create or handle sensitive data. Some also perform sensitive transactions. This is for instance the case for eHealth mobile applications managing data with a high privacy concern, or also electronic ticketing where mobile applications manage the payment and the access to public transportation. As there is something at stake, an unavoidable threat comes along and protecting these data and transactions is necessary. Trust in the new digital services can be achieved if we are confident that the system cannot be compromised. This requires making sure that security protections are present, efficient and effective.

Getting assurance about a mobile application security is difficult and it is not obvious how to apply the right level of verifications. This sequence of articles explores this challenge. First, this post aims at setting the scene about mobile application security protections: introduce the threat and related attack techniques and finally provide an overview of potential protections.

The threat may have different motivations:

  • the fraud is certainly the most stringent. Depending on the mobile application, an adversary may attempt to collect information, disclose some secrets or downgrade a system security. This will result in an exploitable benefit, whose impact is directly related to the nature of the mobile application and its related assets. We can mention systematic collection of private data without the user’s consent, fraudulent payment or illegal access to data or a service.
  • the reputation damage is a strong threat, whose main issue lies in the difficulty to quantify its impact. All mobile applications dealing with sensitive assets rely on trust. I will not put my weight in a mobile application if I care about this data and I know the system is weak. Merchants will not accept payment via a mobile terminal, knowing the solution has flaws. People demonstrating security issues without benefit are not fraudsters. However, making their work public represents a serious breach of trust.
  • this threat is a bit apart but may raise a strong concern: the intellectual property leakage. Service providers or mobile application developers may be willing to preserve their code and related protocols contained in the mobile application when it is released. Get the information about how things are done usually provides some kind of recipe useful for a competitor or any other players in the ecosystem. The code itself becomes an asset to protect for anyone concerned by intellectual property.
  • Denial of services can be used by concurrent companies, disgruntled employee…To make the service unavailable and cause some massive throwback from the community.
  • Data leakage is subject to big concerns. Recently companies have faced massive data leakage exposing the privacy of millions of users. Even though companies can be fined or may compensate the damage, this is too late and the data breach is irremediable.

To avoid any confusion, this post and the subsequent ones do not cover another strong security concern: the mobile application being a threat for a system or a device. A lot of tools and publications have been tackling this problematic, which is related to the research of malware or wrong behaviours. As an example, we can think about a mobile application collecting malevolently private data and sending them to a server for a mass exploitation. Another example can be found in mobile application concealing a fraudulent code into an apparent innocent application, such as a game. For all these cases, the application does not intend to protect the data or a transaction and deserve a specific way to detect the wrong behaviour. This is subject to specific tests and research. This is beyond the scope of this post.

Back to the need for mobile applications to protect their data or processing, the payment industry offers interesting use cases. Over the past years, the trend has been to make the payment convenient and to improve the experience.

According to the payment forecast book 2019 published by Business Insider Intelligence, “Card payments will tick up as US customers continue to abandon cash, but mobile will remain the brightest growth driver, coming to comprise 44% of the $1.9 trillion in e-commerce and 68% of the $760 billion in P2P payments in 2024.”

Among different initiatives in favor of payment digitalisation, we see that contactless transaction without amount threshold is the more trendy. To achieve this on Android phone ecosystem, different technologies were proposed and some are software only, which means they are generic over different phones. Host Card Emulation payment applications are a good example. AndroidPay is one example of such solution. Even though the stakes of the assets manipulated by the mobile application has been decreased with the tokenization, their exposition dramatically increased due to the nature of a mobile phone: open, multi applicative and highly connected.

To address this, the liability and the security strategy migrated to a risk managed at the system level, where back-end and mobile device interact with each other for fraud detection. Some assets are therefore managed by the mobile application and they deserve some protections to mitigate their exposure and potential vulnerabilities.

On the other side of the payment, the merchant side is also turning more and more to mobile. Mobile Point of Sales. This technology is ideal for small merchants willing to accept card transactions with the connectivity and the affordability of the mobile to process the payment. While the assets in a classical Point of Sales were protected by a secure and controlled hardware, the migration to the mobile represents security challenges. The mobile application has to take into account new attack scenarios to prevent malware collecting sensitive data, such as card numbers.

Assuming the service provider or the developer acknowledges the need for protecting the application, it is necessary to perform a minimum of risk analysis. One of the first steps is to identify the assets requiring protection and to qualify potential adversaries and their profile. This analysis mostly relies on the application. As an example, the following adversaries can be listed:

  • A theft having an access to the victim device and makes use of it. Or anyone losing his device and someone willing to exploit his find. The fact that the device is locked is not necessarily considered as a protection, as the quality or the confidentiality of the passcode or patterns may not be strictly enforced. If you look around you, a few people know your code, such as members of your family or some of your colleagues. A thin portion of these people may be malevolent, but they cannot be discarded when designing a secure system.

  • A fraudster taking benefit remotely of a weakness on your device. This may be triggered by an avoidable and naïve action from the victim, such as opening a suspicious link or document, but also by severe flaws in the device.

  • Anyone, even with limited technical skills, willing to explore the mobile application from its binary. Indeed, the binary can be extracted from the device or even collected from the store. It is therefore subject to analyses such as reverse engineering. Developers keen to preserve their intellectual property of their application must be aware that protecting the binary is not an option and must be implemented.

  • The device owner is also a potential adversary for some applications. This looks surprising for a lot of people, but we may find benefit in tampering our own device. All data managed by an application may not belong to us. We may find valuable to downgrade a processing or get access that we were not supposed to have. A first example is the public transport system: the electronic tickets are managed by the applications. The device owner may be willing to get some extras without paying. A second example concerns the identification of an attack: why not using our own device to qualify an attack and expose the potential attack publicly? Managing the protections against the device owner are certainly the most difficult to tackle since the owner has direct access to the phone.

Now that we see who the potential adversary are, it is important to consider what they can do, and how. The list below does not aim to be exhaustive, but rather to highlight the variety of techniques used to compromise either sensitive data or operations.

  • Reverse engineering is certainly the first threat to consider, as this is often an entry point to go further into an attacker’s scenario. The aim is to understand what the code is doing, and potentially collect different data stored or exchanged by the application. Different techniques can be used, either by observing the binary - this is called a static analysis, or by monitoring the application when it is being executed - this is called a dynamic analysis. As mentioned above, without security protections, this technique is very simple. It can be made very hard by a combination of protection measures that will be detailed later in this post.

  • Cloning the application, i.e. copy from the device A all data useful to operate the same service on the device B. This is damaging when the application holds individual credential corresponding to a single user. A good example can be found in the digital right management: a protected content was purchased by an individual and is supposed to be readable on his devices only and individuals should not be able to share it.

  • Privilege escalation. Most devices strictly reserve the highest privilege of execution, or root access, to a few system processes. This is not available to the normal user. Gaining such privilege grants rights in the devices that are normally segregated by the operating system such as files or memory access, or even code execution. To perform an attack, particularly to defeat protections implemented in the mobile application, privilege escalation is often a necessary prerequisite for further tampering. The ability to get root access highly depends on the device and its version of the operating system.

  • Code lifting. When studying a code in depth, it can be valuable to execute a piece of code on a different environment than the device. Some frameworks provide the possibility to typically analyse the runtime execution and get the full control of the code. This is particularly useful when the code has some levels of protections and it needs some more sophisticated attacks to detangle a complex execution. Code lifting is classically used to make some analyses on secure libraries, such as whiteBox cryptography.

  • Code injection or hooking. Modifying or inserting code is useful when performing dynamic reverse engineering for monitoring the data flow of a specific routine. It can also be exploited to modify either data or the execution of the same routine. This is typically used to perform man-in-the-middle attack scenario.

Luckily, protections exist to make all these techniques difficult. They can be implemented by experienced developers or found in commercial solutions. They address specific attack techniques to either detect them or make them harder to achieve. They become very efficient when they are properly stitched together. Below is a panel of techniques nowadays used in secure mobile applications:

  • Obfuscation is necessary to prevent static reverse-engineering. The principle is to change the code binary or the data in such a way that it becomes unreadable for anyone having access to the binary. Obfuscation is not a monolithic technique: each solution has its own way to make the code harder to analyze. The different solutions differentiate themselves by the various aspects of the code they tackle: the strings, the function names, the execution flow, etc. As a downside, the most efficient techniques commonly creates a significant overhead in the code size and its performance.
  • Root detection is certainly the first protection considered by the mobile developers when it comes to protecting their application. Because a rooted device does not isolate the applications from each other, it increases tremendously each application attack surface. However, it is most of the time not an option for the mobile application developers to block the execution of their application on the rooted device as it means excluding a part of their potential customers, or to face some of them not understanding why the service is not working for them. That question may be raised because some devices may have been rooted without the holder being aware. When it comes to detecting that a device is rooted, the challenge for the security vendor is to cover a broad panel of root techniques specific to the different devices and keep their countermeasure updated.
  • Debug detection avoids giving information or capability for the attack to finely analyse the code by scrutinising its execution. A debugger offers a broad range of capabilities such as performing step by step execution and showing all intermediate execution values.
  • Emulation detection prevents an adversary to perform dynamic analysis using an emulator. An emulator is a tool supporting the code execution and giving an adversary to control the runtime execution.
  • Anti hooking. Some analysis framework, such as Frida or Xposed, injecting code have shown their efficiency. This is why it is so important to prevent as much as possible the use of such technique. This control must be performed at the right time of the execution. Dynamic reverse engineering and code injection are made difficult when this protection is in place.
  • Device binding. The principle is to make sure that a code or a data can be executed on one device only. Well implemented, this should make difficult any attempt of cloning or code lifting. When copied, the data become indeed non-exploitable.
  • Certificate pinning. The mobile application makes connections only to trustworthy servers. To achieve this, a certificate is “pinned” into the mobile application. Once in place, it is possible to create a trusted secure channel between the mobile application and the server, preventing straightforward eavesdropping or network injection.
  • Crypto protections. Behind each security function, there is usually the need of enforcing confidentiality, data or code integrity and authenticity. All of these requirements can be achieved using cryptography. For instance, data are kept confidential if they are encrypted with a secret key. Or a code is authentic, if I can verify his signature. When executed on the device, these algorithms require a proper thought to secure them, as they represent a primary target for an attacker, and particularly when they are executed on a non-trusted device. For this, there is no perfect solution. Using cryptography features backed with a dedicated hardware looks like a safer choice. But it is to the detriment of the solution portability. A pure software approach is possible and has the benefit of being device agnostic: the technology is usually named whitebox cryptography.

Taken individually, all these protections can be circumvented providing some effort and skills from the hacker. However, when combined together in a proper way, it represents a technical challenge. At a certain level, it may no longer be worth the effort. The right security level must take into account the balance between the efforts for a hacker to compromise a system and the benefits he can get. His life can even be made more difficult, if the mobile application and the back-end are working in concert: for instance it is a good practice for the mobile application to raise any detection of anomaly to the back-end for further action on the concerned user. The back-end system must integrate verifications to detect anomalies, but it remains necessary for mobile applications exposed to attacks to avoid vulnerabilities and make sure they can withstand tampering.

comments powered by Disqus