RASP Tools: silver bullets for mobile app protection?

With this blogpost, we would like to share some of our recent experiences with various RASP tools.

Before we start, we would like to provide a description and answer the question:

What are RASP tools?

Gartner defines Runtime Application Self-Protection (RASP) as a security technology that is built or linked into an application or application runtime environment, and is capable of controlling application execution and detecting and preventing real-time attacks.

In the mobile landscape, this means RASP tools protect an application against different sets of threats and attacks, like rooted or jailbroken phones, tampering attempts etc.

RASP tools come in different shapes, such as:

• An SDK that includes the protection function and needs to be integrated into the mobile app,
• A RASP client application that will analyse the source code of the mobile application and decide where to apply a protection, and
• A SaaS solution into which the compiled mobile app is uploaded, modified (and re-packaged) to include the RASP.

All the solutions we have seen protect against the same minimal set of threats:

• Execution of mobile app on a rooted devices
• Debugging the mobile app
• Executing mobile app in an emulator
• Tampering the mobile app at rest or at runtime

Some go beyond and additionally include other protections such as:

• Code obfuscation
• Threat (malware) monitoring
• Anti screenshot/recording
• Backend monitoring

However, the real differences come from how those protections are applied and how advanced they are.

Let us have a closer look into each type of RASP tool and their characteristics:

• RASP SDK: an SDK is probably the most challenging to use but also the one allowing the most control. Usually, the RASP SDK vendor provides a library with a public API as a compiled binary file. This allows the mobile application developer to really integrate the RASP functions in their application and control which protection is executed when and where. However, in order for the developer to understand what to do and what to protect, the SDK provider has to give a thorough documentation of how the solution works and what assets should be protected.

• RASP client application: in this approach, the RASP tool vendor provides a binary application to the mobile app developer. The client application is typically fairly easy to use and takes away some complexities from the developer: he only selects the desired level of protection and provides the path to the source code of his mobile application. Then, the client analyses the source code and decides on its own where the protections will be applied and which ones, depending on the level configured.

• RASP SaaS solution: this is almost the same as with the client application but there is one major difference: this solution works on the compiled application. This means that the possibilities for code modification are very limited as it is impossible to semantically know what a specific piece of code does.

What are the challenges with RASP tools?

Whatever the solution chosen by the developer is, a major issue is that all RASP solutions work as black boxes. The mobile application developer does not know what is contained inside and how it works. This results in a serious issue: how can a developer trust the solution then?

Trust in the RASP tool vendor is good and necessary, but this shall not be all. One solution is a clear and thorough documentation provided by the vendor. Another one is the use of automated tools to test the responsiveness of the RASP tool against a certain set of attacks.

However, this still does not give the developer an idea of how good and complete a solution is actually.

Our insights

In the last months, we had the opportunity to have a deeper look into various RASP tools which allowed us to familiarise with and compare a few different approaches. This allowed us to give actionable information to our clients by explaining in detail how good each tool was and how they worked internally.

These missions gave us insights about another important issue: a single point of failure. A concrete example of that is the case of a SaaS solution working on a compiled application. As explained earlier, it is very hard to semantically analyse the code and therefore really intertwine the protections with the application. Therefore, an easy solution is to do all the checks at the start of the application and react in case of detection. However, if an attacker is able to simply hook or replace the function responsible for the checks, then the application will work as if nothing has happened. Another good example of this is when using an SDK with only one callback method in case of detection. Then, as before, the attacker only has to replace that specific single method in order to bypass the whole solution, hence a clear documentation and guidance to the mobile app developer is key.

The last important thing to understand is that Android and iOS are very different platforms. They allow (and disallow) different features and work very differently internally. Therefore it is very challenging for RASP solution vendors to create equally good solutions on both platforms because of very different experts and skill sets required. During our work, we often see discrepancies between the same application protected on iOS or on Android using the same solution.

Moreover, because of the communication by Apple, many people (developers included) think that it is not possible to perform the same attacks on iOS and on Android. For example, a recurring question is whether it is possible or not to hook an application on iOS. And the answer is obviously: yes it is. Another common misconception is thinking that Apple does not allow code obfuscation and that it is not needed as the AppStore protects against an attacker trying to obtain your application. This is actually not true: Apple allows obfuscation and it is needed on iOS as much as on any other platform.

Recommendations

We understand that this all sounds and seems scary. But there is no reason to fear!

RASP developers are making tools increasingly easy to use with clear documentations about what to protect and how. They are also making their solutions more and more transparent, explaining what they do (not in detail, obviously) so that developers can make informed decisions.

Generally speaking, if a tool is just a set of tick boxes and sliders with no explanation at all about what moving a slider really does, then it is a bad tool. This does not mean that it is a bad protection, just that it will not really help the developer to have faith in it.

However, a (and possibly the only) solution to gain assurance is penetration testing. Once an application is developed and protected using a RASP tool, a penetration test shall be performed on it in order to shed light into multiple issues:

• It will analyse the conception and uncover architectural issues (which does not really depend on the RASP tool)
• It will detect insufficient protection (assets not protected, no detection of some attack vectors) that may be attributable to configuration issues with the RASP tool
• It will identify easy bypass of the protections, as a result of a misconfiguration or weaknesses in the RASP tool.

The penetration test can be completed by adding automated mobile app security testing into CI/CD development pipeline in order to have immediate feedback on any changes made and the effectiveness of protections.

And last but not least, if a mobile app developer is not sure about the strength and weaknesses of the solutions available on the market (and there are many available), a benchmark performed by experts can give valuable and actionable information about how to choose the right solution for an application.

Conclusion

RASP tools are and can not be the silver bullet (also known as “snake oil”) when it comes to protecting mobile apps. It is always the responsibility of the developer to take care of the protections which is a challenging task for the mobile app, with or without using a RASP solution. However, RASP tools can greatly facilitate the implementation of protection and remove the complexities of implementation. But using them properly still requires some good security expertise from the developer.

Developers integrating RASP tools must integrate in their process a way to verify RASP is working. This is not that simple because it requires to set up specific testing conditions, such as modified mobile devices. One solution could be to leverage a Mobile Application Security Testing (MAST) solution working on the binary. eShard provides one with esChecker.

It is also important to note that no protection is perfect hence layering is key to slow down the attacker as much as possible.

Let’s conclude with a proverb: trust is good, control is better!