Certain features of Mobile Application Shielding require deeper integration inside the application, or changes to the build.
Phases of an application to be enabled:
- Callbacks
- Activity Guard
Root detection
Rooting is the process of circumventing security measures of the operating system. This is usually performed by the device user to customize the device beyond of what the manufacturer allows.
Attackers can 'root' a device to bypass the Android application sandbox. This can grant attackers access to data that is stored on the device, which would otherwise be restricted. Similarly, malware can exploit known weaknesses within Android to gain elevated permissions on a device while it is running.
Since a rooted device has a higher risk of being compromised, it is important to know about this. Even if the application can be configured to allow execution on rooted devices, detecting whether the device is rooted or not is essential for further security measures.
Root detection can be performed in several ways, such as checking for well-known indicators of root files, processes, and other anomalies. Root detection is inherently a "cat-and-mouse" game between new rooting techniques and rooting detection methods.
App Shielding implements several layers and levels of root detection mechanisms to handle most well-known approaches as well as more heuristics type indicators that are looking for symptoms of a rooted device rather than conclusive evidence. Newer versions of Android restrict the ability to detect certain types of rooting due to a stricter app security sandbox being enforced on the detection mechanism itself.
Repackaging detection
Repackaging has become a common practice on Android in recent years and means that an attacker can obtain a copy of the application, add malicious functionality, and then offer it to users who presume that they are using the original application.
This type of attack is made possible since there are many alternative distribution platforms in addition to the official Google Play Store. The act of repackaging the application can also be used when attempting to reverse-engineer an application.
App Shielding offers the possibility to detect and react when an application has been repackaged. Furthermore, App Shielding creates a strong binding between the app and App Shielding. With this, the security features provided by App Shielding cannot be bypassed easily.
Code injection protection
To gain control of an application, attackers may inject code into the application to control it from within its own process. This can, for example, be used to read encrypted SSL communication or intercept user input such as passwords.
This type of threat is more common on rooted devices since injecting code into another application would otherwise have been prevented by the operating system sandbox.
App Shielding can detect the presence of code hooks, as well as typical code injection frameworks such as Xposed or Cydia Substrate. In most cases it can also block injection of code into the process.
Debugger protection
During application runtime, debuggers can be used to extract sensitive information, perform code injection, alter the program flow, and help attackers to reverse-engineer the application. By actively blocking debuggers, App Shielding can prevent them from attaching themselves to the application.
This is implemented by launching a trusted guard process that will act as the App Shielding-specific debugger. App Shielding supports advanced debugger protection by executing a security handshake with the guard process. If the guard component has been circumvented by an attacker, this feature can block further usage of third-party debuggers.
Emulator detection
Emulators can be used to analyze an application to determine how it works and to extract sensitive information that is available while the application is being executed. App Shielding can detect that the application is being executed in an emulator or typical virtual environment.
With the Exit on Emulator option, you can configure App Shielding to terminate app when an emulator is detected.
With the Exit on Emulator URL option, you can also enable App Shielding to terminate the shielded app when it is launched on an emulator, and open a browser with the configured URL to display a web page with an explanation.
Block emulated input
Non-physical inputs (motion events) are known as emulated input. Emulated input might originate from the Android Debug Bridge (ADB), autoclick applications, screen-mirroring applications, screen reader applications, etc.
You can also define an emulated input threshold. App Shielding assigns a score value for each input to determine if the input might be emulated. Input scores above this threshold will be considered as emulated inputs.
For information how to configure this feature, see OneSpan Customer Portal.
Keylogger protection
Android offers its users the possibility to install custom software keyboards. These keyboards naturally track every input information the user makes, thus allowing an attacker to obtain this information and using these keyboards as keyloggers.
Due to the limitations with some virtual spaces, such as Samsung Secure Folder, or Xiaomi Dual Apps, the keyboard cannot be queried when the protected application is running in a virtual space. Therefore, the keyboard will be untrusted by default while it is running in virtual space apps.
Thus, if you want to allow running the protected app in virtual space, then you need to disable the Exit on untrusted keyboard configuration option. If you have enabled the Check trusted keyboard option and have an App Shielding observer implementation (see Configure callbacks on Android), you need to expect KeyboardData callbacks (see KeyboardData) with untrusted keyboards.
App Shielding allows to configure a list of trusted software keyboards to determine if the used software keyboard is trustworthy or not.
Screenshot protection
Applications often display sensitive information that should not be easy to exfiltrate from the application. One easy way to extract information from an application is in the form of a screenshot. App Shielding can block screenshots, making them appear only as black rectangles.
Screen mirroring protection
Another way to export screen data from the application is through screen mirroring, which may be used in different ways, such as casting the screen to ChromeCast, MiraCast or a similar type of vendor-specific mechanism.
App Shielding can detect and block such screen mirroring by displaying a customized screen or a black screen on the mirrored display.
A customized screen can be used to inform users regarding your security objectives. Such layouts can and should be implemented as a layout by the application developer.
Screen reader protection
Screen readers use Android Accessibility APIs to interact with the application. These APIs were created to provide accessibility aids, such as text-to-speech and other types of accessibility tools,
Malware can also be installed and activated as a screen reader, meaning that it can potentially interactively and remotely control the device and application.
App Shielding can detect if any untrusted screen reader is active, and actively block it from receiving app data. Trusted screen readers may be allowlisted, ensuring the accessibility functionality is retained for specific screen readers.
Due to the limitations with some virtual spaces, such as Samsung Secure Folder, or Xiaomi Dual Apps, the screen reader cannot be queried when the protected application is running in a virtual space. Therefore, the screen reader will be untrusted by default while it is running in virtual space apps.
If you have enabled the Check trusted screenreaders option and have an App Shielding observer implementation (see Configure callbacks on Android), you need to expect ScreenreaderData callbacks (see ScreenreaderData) with untrusted screen readers.
Since version 3.3.7, App Shielding protects applications from a malware called eventBot. This malware asks for several permissions that allow it to access the user's messages or read screen content. Shielded applications are protected from malware reading the screen content, however the malware can still read the user's messages, collect device specification data and information about installed applications, or read external storage. For this reason, OneSpan recommends not using external storage (such as a memory card) to keep application-sensitive data directly on the application.
Android Developer Bridge status
Certain apps require that the Android Developer Bridge (ADB) is not active. App Shielding can detect the if ADB is active on the device.
Developer Mode status detection
Although it is not a security risk from an application perspective, app publishers may need/want to know whether a device has Developer Mode enabled. App Shielding can detect if a device has Developer Mode enabled.
Detecting apps from untrusted sources
Although it is not a security risk from an application perspective, app publishers may need/want to know whether a device has apps installed from third-party app stores, or sources other than the device's main app store.
Binding
The main purpose of binding is to intrinsically bind together the app and App Shielding, so that the app will depend on App Shielding being present to function normally.
This approach makes it extremely difficult for an attacker to attempt to remove App Shielding from the app, because without it, the app will be missing key pieces of information.
All extracted values are encrypted and stored in the application’s APK in the assets/file_name.dat file, where file_name is a random name.
The variables used in a class initializer are excluded from binding.
Two types of binding mechanisms are used:
-
Push binding. Values are extracted and removed from the app. After App Shielding has been initialized, these values will be injected (pushed) into the relevant static class variables (fields). The app code is rewritten to fetch this value from the static class field.
-
Pull binding. Values are also extracted and removed from the app, but the app code has been modified to fetch the values by calling a native method provided by App Shielding. The SDK will only return this value if the security policy is met. All extracted values are encrypted and stored in the application’s APK file.
Push binding can impact the performance of the application at startup. You can switch on Disable push binding to optimize the app's startup performance.
Special considerations
There are several considerations that need to be taken into account when extracting the constants that will be used for binding.
- Performance. The number of bindings that have been extracted affects both startup and runtime performance. Adding push bindings increases the startup time to load the application, while adding pull bindings increases the runtime of algorithms that need to call a method to retrieve a value rather than using a local variable.
- Distribution. Constants should be distributed evenly in the application, so that pull bindings are called regularly during code execution. This enables App Shielding to perform runtime checks during the lifetime of the application execution, rather than only performing checks at startup.
Task hijacking protection
An essential element of Android is multitasking between applications.
A task is essentially the back-stack of activities, and it is closely related to the Recents screen (also known as the Overview screen or recent apps).
On Android, activities from different apps are allowed to reside in the same task, such as opening a link from your email app, which will open a browser in the same task. When pressing the back button, the user will return back to their email application view.
These tasks have an internal ID that is referred to as taskAffinity. This is a string value which is by default set to the same as the app package name.
Malware can set the taskAffinity of an activity to the package name of a target app and, by doing so, can hijack tasks belonging to the target app. In practice, this means that the user may click the target app icon in the launcher, but instead of seeing the target app’s activity, malware activity is shown. Apps can define several distinct activities with distinct taskAffinity values which allows malware to target a wide suite of applications.
App Shielding can detect and block such hijacking attempts.
Obfuscation
Attackers will commonly try to reverse-engineer an application to identify weaknesses, secrets, or other sensitive information. App Shielding can obfuscate an application's Java code, either in part or in whole, making it much more difficult for an attacker to analyze the code. By default, only the App Shielding namespace will be obfuscated, but it can be enabled for the entire application.
Obfuscation is not the primary function of App Shielding, but an effective complementary feature to make it more difficult for an attacker to analyze the application. From an efficacy point of view, App Shielding will perform comparably to other commercially available obfuscation tools, and better than ProGuard (which is included with the official Android SDK).
For more information, see App obfuscation.
Jailbreak detection
Jailbreaking is the process of circumventing security measures of the operating system. This is usually performed by the users of a device to customize the device beyond what the manufacturer allows.
However, attackers can also jailbreak a stolen device by bypassing the device's protection mechanisms to gain access to the data stored on the device. Similarly, some of the available jailbreak techniques can be used by malware to gain extended permissions on a device.
Since a jailbroken device has a higher risk of being compromised, it is important to know about it. Even if the vendor of an application chooses to allow execution on jailbroken devices, detecting whether the device is jailbroken or not is essential for further security measures to determine the threats to which an application may be exposed.
Jailbreak detection can be performed in several ways. Simplistic approaches only test for the existence of files in the file-system that are associated with a jailbroken device. However, the existence of several 'jailbreak hider' tools that are available on iOS shows how easy it is to bypass these detection tools. Jailbreak detection is inherently a "cat-and-mouse" game between new jailbreak techniques and jailbreak detection methods.
App Shielding, while also implementing these simplistic detection mechanisms performs detection on multiple levels ranging from these well-known approaches to cutting edge low-level mechanisms that are targeted more towards detecting the essence of a jailbreak.
Emulator detection
Emulators can be used to analyze an application to determine how it works and to extract sensitive information that is available while the application is being executed. App Shielding can detect that the application is being executed in an emulator or typical virtual environment.With the Exit on Emulator option, you can configure App Shielding to terminate app when an emulator is detected.With the Exit on Emulator URL option, you can also enable App Shielding to terminate the shielded app when it is launched on an emulator, and open a browser with the configured URL to display a web page with an explanation.
Repackaging detection
Repackaging means that an attacker can obtain a copy of an application, add malicious functionality such as a keylogger, and then offer it to users who believe that they are using the original application.
This type of attack is made possible since Apple has an alternative distribution mechanism apart from the App Store called enterprise distribution.
The act of repackaging the application can also be used when attempting to reverse-engineer an application.
App Shielding offers the possibility to detect and react when an application has been repackaged. Furthermore, App Shielding creates a strong binding between the app and App Shielding. With this, the security features provided by App Shielding cannot be disabled by simply removing App Shielding from the app.
Code injection protection
To gain control of an application, attackers may inject code into the application to control it from within its own process. This can, for example, be used to read encrypted SSL communication or intercept user input such as passwords.
This type of threat is more common on jailbroken devices, as injecting code into another application would otherwise have been prevented by the operating system sandbox.
On iOS, there are two known ways to inject code into an application: either during load time (which is done by tools like MobileSubstrate) or during runtime (which is done by tools like Cycript).
Load-time injection is only prevented if the app is being shielded. This is because the feature will otherwise cause problems when running the app during development.
Hooking framework detection
In the rare case that the code injection protection can be bypassed by an attacker, App Shielding is also able to detect actions that the attacker performs inside the process (usually in form of a hooking framework).
Debugger protection
During application runtime, debuggers can be used to extract sensitive information, perform code injection, alter the program flow, and help attackers to reverse-engineer the application. By actively blocking debuggers, App Shielding can prevent them from attaching themselves to the application.
This is implemented by launching a trusted guard process that will act as the App Shielding-specific debugger. App Shielding supports advanced debugger protection by executing a security handshake with the guard process. If the guard component has been circumvented by an attacker, this feature can block further usage of third-party debuggers.
Keylogger protection
Most keyloggers on iOS are implemented using code injection. App Shielding protects against these with its code injection prevention feature.
Screenshot protection
Applications often display sensitive information that should not be easy to exfiltrate from the application. One easy way to extract information from an application is in the form of a screenshot.
Screenshots are taken in different ways: They can be initiated by the user, they can be taken by the system for various reasons (e.g. the task manager when changing between running apps) and they can be taken by screen mirroring.
App Shielding is able to detect when the user takes a screenshot of the application, is able to block screenshots taken by the system and is able to block screen mirroring.
Shielding
Shielding an application with App Shielding renders the application useless if App Shielding is prevented from running. App Shielding provides an application that offers protection from various forms of attacks. Much of this protection is dependent on App Shielding itself running. For example, an attacker could try to circumvent some of the App Shielding protections by running the application without invoking App Shielding. Shielding the application will protect against such an attack.
App Shielding does not currently support shielding on x86 architectures. When building for x86, shielding is automatically disabled. This is typically only used when building for a simulator, so normally it is not important, but it does mean that simulator builds are much easier to attack. We strongly recommend not to ship simulator builds to potential attackers.
Static security features
In addition to the security functions that result in a callback, App Shielding can be configured to provide the following supplementary security features:
- Prevent user input made to the application from being recorded in the iOS keyboard cache.
- Prevent iOS from saving a screenshot of the application when the application is no longer in foreground.
- Prevent attachment of debuggers to the application. This feature will also prevent debugging using Xcode, so it should be deactivated during development/testing.
- Prevent libraries from being injected when the application is loaded. This is the only feature which cannot be configured and is hardcoded into the static App Shielding library. Since this feature also hampers testing and debugging, it is deactivated in the Debug version of App Shielding.
- Prevent external screens (connected through an adapter or AirPlay) from mirroring the application window.