Assuming that you’re familiar with the penetration testing of mobile applications, we’d like to share some additional insight into the requirements that most security companies have. In this article, we’d like to draw attention to a specific aspect, which is why it is effective for a client to allow for the testing of an application on a build without the use of some of their security features, while these features can still be tested on a separate, production-type build. Although these features are important to use when the application is available to the public, they may cause unnecessary complications and delays during security testing. Ultimately, security companies or pentesters will be able to provide a more thorough penetration test with your assistance in this regard. Perhaps more importantly, this will also reduce the time required for professional safety testing, which in the end, reduces your total costs.
Before we start, let’s make sure that we are familiar with the reasons for some important concepts:
These are mechanisms and techniques that are designed to increase the security of the mobile application itself. While it’s running, the application detects unusual features and behavior of the mobile device in order to detect an attacker. When it detects a threat, the application either prevents further use, informs the user, or sends information in the background for further analysis. Likewise, the goal of RASP is to both limit the attacker’s capabilities and complicate their work as much as possible, though, in the end, all of them can be bypassed.
This is a common way of significantly complicating the readability of code. This prolongs the time needed to understand the application’s code - for so-called “reverse engineering.”
SSL pinning is a technique, on top of standard HTTPS (SSL/TLS), that prevents Man in the Middle (MitM) attacks - in which an attacker is able to eavesdrop and modify communication. Using SSL pinning, the application always only connects to a trusted, specific (pinned) server, and the communication remains encrypted and unreadable by third parties.
Root/jailbreak detection is the way an application tries to detect if the device that it’s running on has privileged (full) access to the operating system, which could be a sign of a compromised device.
Of course, there are many other mechanisms that fall under the RASP package, but these are the most relevant for the purposes of this article.
As we’ve been providing penetration testing for some time, we’ve found that clients or application suppliers repeatedly ask the same questions about our requirements. To help us illustrate our position a bit better, we’d like to share some of the common questions we receive:
These are of course valid arguments, and we do not dispute the requirements to test these as well. However, we just suggest a more effective way to do so. Although it may seem a bit unorthodox, or perhaps make them nervous, we can assure you that the process that we propose is in the best interest of the client. A common method we recommend in this situation is to use a “test” version of the app. This “test” version can be studied and manipulated by a pentester so that they can safely identify areas of concern without affecting the production version of the application. The so-called “prod” version is not affected during the tests, but it can later be changed and updated based on the findings in the “test” version. Among the many benefits, it is more economical and meaningful to test a modified version of the application. This approach benefits both the pentester and the client in the long run, but to make this concept more approachable, further explanation is given below.
To begin with, let’s take a look at the requirements for penetration testing a mobile application. For the testing we need to be supplied with two versions of the application:
PROD)TEST)The PROD version is an application that is distributed to end clients using the available channels such as Google Play (Android) and the App Store (iOS). The PROD version of the application is not used during the entire penetration test process. We only use it to verify the protections that have been disabled for the TEST version.
The TEST version is an application that will be used for penetration testing. The application connects to the test environment where we are not restricted in performing tests.
TEST version we require the following:There are other protections similar to RASP - Runtime Application Self-Protection, which could limit the course of testing, but in most cases, they are not implemented (and to keep things simple, won’t focus on them at this time).
There are several reasons for this. All of the aforementioned protections fall under the term RASP - Runtime Application Self-Protection. This means that they are a kind of add-on that increases the application’s protection against an attacker. However, these protections alone do not remove vulnerabilities in server applications or API services. RASP-type protections only reduce the likelihood of vulnerability identification and exploitation or mitigate several of the possible vectors for exploiting a given vulnerability. However, they do not eliminate the security flaw itself, they only make it more complicated to identify them - like locks on doors.
Due to the fact that these protections are implemented directly in the application (therefore SELF-Protection), they can be removed by modifying the application. Once the user has installed the application on the phone, they can obtain, edit and reinstall the application. Therefore, they can remove SSL pinning, root/jailbreak detection, or any other application protection. In the case of an obfuscated application, it’s more time-consuming to analyze the application, but it is still possible.
From the point of view of common penetration tests, where the goal is to identify vulnerabilities in the application and the services used, it’s not important whether it’s possible for us to bypass SSL pinning, identify and reverse the signature scheme, or install the application on a compromised device. We can save you some time and tell you this in advance - YES, it is possible. Only for some applications, this process can take 3 hours, for others it can take 3 weeks.
It is important to realize that an attacker is not limited by time and can therefore study the functionality of the application for several months, or even years. However, we as penetration testers are limited by the time that the client is willing to finance for the purpose of application security testing. For example, with an obfuscated application, we can identify X vulnerabilities within 10 days, but with an obfuscated version with RASP protection, it may take us up to 21 days, or worse, even go unnoticed. So, in addition, those 11 days will not be devoted to testing the security of the application, but to overcoming RASP protection and deobfuscating code in the analysis of the application. As a result, it is more efficient for us, and more economical for the client, to test an application that does not have RASP protection implemented. This allows us to start testing the application right away, and test the protection mechanisms later or in parallel to application and API testing. This does not only make the testing more effective in general and time-wise, but it also eliminates possible delays due to time spent on troubleshooting during the early stages.
For effective and consistent testing of mobile applications, it is important to simulate a situation in which an attacker has already managed to break all of the RASP protections. Then, we can focus on the real vulnerabilities of the application, understand its functionality in detail, and identify and exploit the security flaws.
Vulnerabilities in mobile applications can be classified into two basic areas:
RASP protections complicate the testing of both vulnerability areas, thus extending the time required for testing. Our recommendation is to use a test version of an application during pentesting while testing the RASP protections on a separate application (production-like) build. In addition to allowing us to provide the full potential of our services, this mainly reduces the time and budget that’s needed to make a proper evaluation.
