April 17, 2024
Runtime attack, also referred to as dynamic analysis, is a type of reverse engineering attack done by malicious actors on a running app using debugging and hooking tools. The malicious actors do this to identify and potentially exploit weaknesses such as business logic flaws, weak input validation, and improper input/output encoding. Static analysis can be addressed by layering different code obfuscation techniques and encryption, On the other hand, dynamic analysis - tampering (and repackaging) dynamic analysis attacks require enabling an additional runtime application self-protection (RASP) mechanism that can facilitate actively monitoring and maintaining the integrity of your applications and their environment in real time.
This blog takes a look at the benefits of implementing RASP, how to get started, the different layers of RASP checks DexGuard and iXGuard offer, best practices you can follow, and how real-time threat monitoring solutions like ThreatCast solidify your overall protection strategy against dynamic attacks.
RASP protects your app integrity at runtime
RASP is a protection technology that is embedded in a mobile application to monitor and protect it from attacks at runtime.
While numerous RASP tools exist, it's crucial to opt for a solution that automatically injects RASP checks, sparing developers from manual code integration. Manual injection may seem to offer developers more control, but it often leads to possible attack avenues, such as single points of failure and predictable checkpoints, making it easier for attackers to bypass security measures. Manually adding sufficient checks to secure an application proves challenging compared to automatic injection, which disperses checks throughout the code, making them harder to detect and bypass.
Benefits of implementing RASP
There are a number of key benefits to using RASP for mobile application protection, including:
- API security: RASP can be used to secure mobile application APIs by detecting and blocking unauthorized access to the APIs. This helps to prevent data breaches and other security incidents caused by attacks that target the application's APIs.
- Mobile app and environment security: RASP can also be used to detect and block attacks that target the mobile app itself. For example, RASP can detect jailbreaking.
- Threat visibility: RASP can provide visibility into the threats that are targeting mobile applications. This information can be used to improve the security of the applications. With this insight, you could change the reaction strategy or you could revert the findings to a monitoring dashboard in your backend and take decisions on any hacking attempts by blocking the user, as an example.
- Comprehensive protection: RASP is complementary to static obfuscation. RASP ensures the integrity of the obfuscation, while the obfuscation complicates the identification and bypassing of RASP check locations.
Getting started with RASP
- From a developer’s perspective, the RASP process can start by identifying the key security risks that the mobile application faces. Once these risks have been identified, the developer can select a RASP strategy that can help to mitigate those risks. To cite a few examples: Banking and finance applications are typically concerned with compliance, gaming apps are interested in hooking detection to prevent cheating, and an application with ads would want to protect against those ads being bypassed by repackaging the app without the ads.
- The next step is to integrate the RASP solution into the mobile application.
Different RASP checks protect you from different kinds of threats
DexGuard and iXGuard provide numerous RASP checks that protect your app on different layers: Environment level, Application level, and Code level. Using ThreatCast, you can easily monitor each of the RASP checks triggered in production, allowing you to understand better where in the application the attack happens.
Let’s take a look at the RASP checks in each category, and what they protect your app against.
Environment threats
Environment threats indicate that the runtime environment in which the application is running shows signs of tampering. In such an environment, the security restrictions could have been removed or disabled from the operating system. Let’s take a look at environment-level threats you should consider protecting against:
| RASP check | What does it mean? | Why inject this RASP check? |
| Debug detection | A debugger has been attached to your app, and your application is running in a debug build or from a debugger. | Debugger allows attackers to analyze your code by pausing execution at dedicated points and reading out the memory |
| Emulator detection | Your application is running on an emulator instead of a physical mobile device. These tools create a virtual machine version of a mobile device on the computer. | Although running an app on an emulator may not directly translate to malicious intent in and by itself, emulators are usually used as one of the avenues of attacks (i.e., bot-attack, fraud). |
| Virtual environment detection | Your application is running in a potentially insecure environment where the underlying physical device or used OS version is not clear or different from the one used on a real mobile device. | Similar to emulators, running an application on an emulator may not directly translate to malicious intent in and by itself. However, attackers often use virtual environments to run multiple instances of the app in parallel. Often the intent is to breach security controls. |
| Rooted or jailbroken device detection | This means your application is running, on rooted/jailbroken devices. | Although jailbreaking/rooting does not directly pose any danger to your application, they disable the built-in security features of the operating system, which can lead to privilege escalation-based attacks and result in the malicious actor gaining superuser access. |
| Clock rate tampering detection | This is mainly for gaming apps | It's to prevent people from accelerating or decelerating the system clock |
Application threats
Application-level threat notifications indicate that a user has attempted to tamper with the resources of the application package (IPA or APK.) Let’s take a look at application-level threats you should consider protecting against:
| RASP check | What does it mean? | Why inject this RASP check? |
| Application tampering detection | A user has attempted to patch the binary of your app, substitute, or extend the application code. | Using numerous techniques, attackers can modify the application’s runtime behaviors to perform unauthorized, potentially malicious, actions leading to possible back-end abuse, app cloning, piracy, IP theft, and reverse engineering, to name a few. Such attacks can negatively impact a company’s brand and revenue. |
| Memory scanning detection | A user has attempted to alter data fields in your application's loaded memory | Attackers can modify values and string fields at runtime, e.g. the score of a game |
Code threats
The application code shows signs of tampering which could affect the behavior of the application. Let’s take a look at code-level threats you should consider protecting against:
| RASP check | What does it mean? | Why inject this RASP check? |
| Function hook or code tracing detection | A user attempted to intercept or alter your application’s function calls, events, or messages between software components to alter its behavior. This can be accomplished by modifying the source code or dynamically at runtime. | Hooking can modify your app code and, therefore the integrity of your app, allowing threat actors to alter the app beyond what it’s originally designed for. For instance, by modifying the return value of a function (e.g., changing isAuthenticated() from false to true.) |
| Code signing detection | The application’s executables and/or scripts have been resigned and no longer match the authentic application’s signature. | This alert certainly indicates that the application has been altered or corrupted since it was signed, meaning that the authenticity and integrity of the application have been compromised. Attackers often do this to create a clone/modded version of the original app. Often unaware users end up using the moded versions of the app. |
Automatic RASP implementation over manual RASP
When comparing manual RASP integration with the seamless process of automatic injection that could be facilitated through a guided user interface (UI), it becomes evident that the latter offers a superior user experience (UX) in several key aspects.
Firstly, manual integration of RASP checks demands significant developer effort and meticulous attention to detail. Developers must manually embed calls to the RASP SDK throughout the application's codebase which can be time-consuming and prone to human error. In contrast, automatic injection via the UI streamlines this process, freeing developers from the burdensome task of manual code modifications. Providing an intuitive interface for configuring and deploying RASP checks, can minimize friction in the development workflow, enabling developers to focus on enhancing the application's features and usability.
Furthermore, manual RASP integration often results in a static arrangement of checks within the code, making it easier for attackers to identify and bypass these security measures over time. In contrast, automatic injection dynamically places RASP checks at different locations with each build, rendering traditional reverse engineering techniques ineffective. This dynamic placement not only enhances security but also ensures that the application remains resilient to evolving threats without sacrificing user experience.
Additionally, automatic injection extends beyond the application's core codebase to include dependencies and third-party libraries, where manual intervention may not always be feasible or practical. By seamlessly integrating RASP checks across all components of the application, you ensure comprehensive protection against potential vulnerabilities, thereby instilling confidence in both developers and end-users.
Automatic injection of RASP checks through the UI represents a paradigm shift in mobile application protection, offering developers a more efficient, reliable, and user-friendly approach to enhancing security.
Conclusion
In conclusion, implementing runtime application self-protection (RASP) offers a myriad of benefits, from enhanced security to real-time threat detection and response. By exploring the advantages of RASP, understanding how to initiate its integration, delving into the multifaceted layers of checks provided by tools like DexGuard and iXGuard, and adhering to best practices, organizations can secure their applications against dynamic threats effectively.
Complementing these efforts with real-time threat monitoring tools such as ThreatCast provides a comprehensive defense strategy, ensuring proactive mitigation of evolving threats.
