> Side Channel Analysis
Ready-to-use side channel tools to assess cryptography algorithms.
> Laser & EM Fault Injection
Make sure your chip withstands different techniques of physical fault injections.
> Firmware Security Analysis
Qualify embedded code binaries without physical devices and benches.
> Security Failure Analysis
Photoemission analysis to explore internal information in a chip.
> Vulnerability Research
Dynamic analyses at a system level for investigating potential vulnerabilities.
> Data Science Platform
esDynamic is a complete data focused platform to leverage the know-how of your team for complex analyses.
> esFirmware Engine
Assess the security of the firmware of IoT devices against logical and physical attacks.
> esReven Engine
Record and replay vulnerability researches within reverse engineering processes and tools.
> Cybersecurity Training
Grow your expertise with training modules driven by a coach.
> Hardware Evaluation Lab
High-end laboratory capabilities specialized in hardware security evaluations.
> Mobile App Security
Know the threats and risks of your Mobile App.
Integrate the security protections verification in your CI/CD pipeline.
> Mobile App Security Testing (MAST)
esChecker SaaS: automating the security testing of your mobile app binary.
> Mobile App Penetration Testing
Testing the resiliency of your Mobile App, SDK or RASP tool.
> Backend Penetration Testing
Testing the resiliency of your Web App, API or Backend Systems.
> Coaching for Mobile App Developers
Providing insights into the mobile app threats and how attackers work by a learning-by-doing approach.
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:
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:
All the solutions we have seen protect against the same minimal set of threats:
Some go beyond and additionally include other protections such as:
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.
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.
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.
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:
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.
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!