Why We Automated RASP Check Injection in DexGuard

According to recent app security research conducted by Guardsquare, fewer than half of the top 3,000 financial services Android apps on the market use code obfuscation. Taking a deeper look, the same research reveals that less than 10% of them use additional code protection techniques. Given the fact that application reverse engineering and tampering risks are included in the OWASP mobile top 10, the application protection rate is very low.

One of the major reasons for the state of mobile application protection, despite serious security concerns such as the exposure of sensitive data and IP, is that without proper tools, it takes significant time and effort to develop and maintain a strong, diverse multi-layered security implementation. With the release of DexGuard 8.7, we made it easy to implement and maintain a diverse runtime application self-protection (RASP) check base.

What is RASP and why is it important

RASP stands for runtime application self-protection. This technology is used to detect and prevent attacks on your mobile application when it is running.

If your mobile app is effectively obfuscated, it is already protected against static analysis and reverse engineering. However, at runtime there are many methods that attackers can use to tamper with your application.

Here are a few examples of what runtime attacks can achieve:

• Attackers can use repackaged applications to capture sent and received data, including stealing passwords, credit card numbers, patient health data, and other sensitive information.
• Secret strings, such as encryption keys, are obfuscated in your application code but are later decrypted and can be lifted from the running application. Using a secret key, an attacker could later impersonate a legitimate app user, for example, to mass-book and resell hotel rooms, restaurant tables, or event tickets.
• Attackers can gain access to end-user devices and patch URLs to redirect application users to malicious web sites to steal their information or trick them into performing financial transactions.
• Application checks, such as license checks, can be bypassed so that the attacker can pirate and redistribute your app or cheat in an online game.

RASP makes your application resilient against such attack scenarios by preventing  attackers from using debuggers, code tracing tools, or hooking frameworks.

Why automated RASP is a better RASP

Many mobile application protection tools on the market provide RASP functionality in the form of an SDK. The development team has to manually add calls to the RASP SDK throughout the application code to detect and prevent various runtime attacks. This approach gives a developer a lot of control; however, it leaves two important opportunities for improvement:

• Maintaining a large number of RASP checks is not always easy. Yet, centralizing the checks creates a point of vulnerability in the application, making it easier for an attacker to locate and disable all checks at the same time.
• Once the checks are implemented in the code, they typically remain in the same location. A good obfuscation strategy changes the exact signature of the checks; however, once all the checks are known to an attacker, it is very easy for an attacker to find the checks in the next application version.

Alternatively, injecting RASP checks in the code automatically allows developers to easily maintain a large number of checks because it is the configuration and not source code that is impacted. In a real-world application, tens of thousands of RASP checks can be injected in the application and even in dependencies for which no source code is available. The checks are injected at different places automatically in every new build, effectively invalidating any prior analysis and reverse engineering effort.

Practical tips on where to inject RASP checks

When injecting RASP checks with DexGuard, you will need to consider both security sensitivity and performance sensitivity of the code.

• Cover as much of your code as possible as a candidate for RASP check injection. Definitely include classes which perform security-sensitive operations and consider as many other classes in the code as possible. The wider the area you define for RASP check injection, the more difficult it will be for an adversary to find and disable all of the checks.

  By default, DexGuard uses a filter that will include the widest possible range of candidate classes. You can override this filter to provide exclusions, such as:

  • Performance-sensitive code in your app. For better guidance, the DexGuard documentation includes a runtime checks performance table so that your team can better understand any possible impact.
  • Third-party code that you do not want to target. For example, exclude third-party security libraries, which check their own integrity. 

Using this approach, your RASP checks will be injected in an effective way. At the same time, your team will not have to write code to invoke every single check manually. 

Conclusion

DexGuard has an option to automatically inject RASP checks into your application to protect them against runtime attacks. Automatic RASP injection makes application shielding more diverse and easier to maintain. Development teams simply switch injection on and configure the filter to define in which classes to inject RASP checks. DexGuard will take care of the rest, injecting  multiple checks - and at a different location in every new build.