.png)
Modern mobile operating systems are arguably more secure than traditional desktop operating systems, but problems still appear when security isn’t carefully considered during development. Some key areas in mobile application security that should be considered during development include local data storage, obfuscation, emulation detection, application integrity check, root detection, runtime integrity check, and debug detection. Let’s take a brief look at each one.
The protection of sensitive data, such as credentials and PHI data, is crucial to mobile security. The local database or data in the database used by the application should be encrypted at rest. Storage of the decryption key and access to it can be tightly controlled using KeyChain on iOS and KeyStore on Android.
Obfuscation is the process of transforming code and data to make it more difficult to comprehend. It is an integral part of the software protection scheme. Obfuscation is not something you can just turn off or on, but it can be used to make the application, or parts of it, harder to decipher to various degrees. Tools like Pro-Guard and R8 on Android can be used as part of the compilation process to rename variables, methods, and classes so it will be much harder to read and understand the application.
The goal of emulator detection or device binding is to increase the difficulty of running the application on an emulated device or transferring the application in its current state to a different device. This impedes some tools and techniques that reverse engineers like to use. In some use cases, the application is already bound to specific hardware and will not function without it. In other cases, binding can be achieved using specific device identifiers or by adding a device-specific key to the encryption chain of critical application data.
Reverse engineers can try to decompile and patch the application to alter its behavior. An effective way to make this process more involved is to implement validation on the application's bytecode. The idea is to have additional controls in place so that the application only runs correctly in its unmodified state, even if the code signature is valid. In our workflow example (Figure 1), the compiled application tamper detection runs at the start of the application and will exit if any modifications in its bytecode are detected.
In the context of anti-reversing, the goal of root detection is to make running the application on a rooted device more difficult. This, in turn, blocks some of the tools and techniques reverse engineers like to use. There are libraries recommended by OWASP Mobile Security that can be used to detect a jailbroken/rooted device and then alert the user. In the example application workflow (Figure 1), the user will not be allowed to continue the use of the application when the device is detected to be rooted/jailbroken.
Controls in this category verify the integrity of the application’s memory space to defend against memory patches applied during runtime. These patches include unwanted changes to binary code, function pointer tables, and important data structures, as well as rogue code loaded into the process memory. In the example application workflow (Figure 1), the application executes the runtime tampering detection throughout its use and will exit if any tampering is detected.
Debugging is a highly effective way to analyze runtime application behavior. It allows the reverse engineer to step through the code, stop application execution at arbitrary points, inspect the state of variables, read and modify memory, and a lot more. Various checks to detect a debug state can be implemented. In addition to not allowing debug states, the device can also be prohibited to run in developer mode. Blocking the developer mode might not always be appropriate, but it can be when the application comes preinstalled on a dedicated device. In the example application workflow (Figure 1), the user will not be allowed to continue the use of the application when any debug configuration or the developer mode is detected.
All detection techniques and ways in which further use of the application is blocked are depicted in Figure 1. The compiled application tamper detection and root detection are run after the application starts, and if any anomalies are detected, the application either closes or shows a blocking alert. Both runtime tamper detection and debug/developer mode detection are run not only at the start, but throughout the use of the application.
It’s important to keep security in mind when developing mobile applications. This is especially true in the medical device space where there is a stronger need for parts of the technology and data to remain confidential. Some key topics to consider were discussed and should serve as a guide to building more secure mobile applications.
OWASP Mobile Application Security Testing Guide (MASTG), 2021, Bernhard Mueller, Sven Schleier, Jeroen Willemsen, Carlos Holguera.
