Performing a penetration test against your mobile application is becoming an important task for higher security. Unfortunately, performing a penetration test without following a well-defined methodology could waste time without giving an optimum result for you. Therefore, here are the different steps for the mobile application penetration testing methodology:
If you are reading this blog post, then you are either a penetration tester looking for a methodology to follow or you are a mobile application owner that wants to get an idea about the mobile application pentest process. Either way, in this blog post I will explain in detail how a mobile application penetration test can be performed with some realistic examples for technical people?
Before you start any penetration testing mission, the first thing that should be performed either by the application owner and the penetration tester is defining the scope and correctly understanding it. You should know that it is very easy for a penetration tester to lose track during a penetration test if he didn’t get a well-defined scope.
For example, it is very common for a penetration tester to discover hidden subdomains while performing his tests. Some of those subdomains might be under development and not yet secured or even not owned by the client itself. Therefore, performing penetration tests against those subdomains would be a waste of time. In addition, those test might be subject to law pursuit for both client and the penetration tester if the subdomain is not owned by the app owner.
The scope of the mobile application penetration test can include not only the domain names that the penetration tester is allowed to test but even the type of attacks that can or can’t be executed against the app.
Moreover, the time frame when those tests can or can’t be executed to avoid disruption of the production environment if those test would have an impact.
Once the scope is well defined, communicated, and understood by both parties, the penetration tester starts the job by performing a reconnaissance process. In this process, the penetration tester tries to collect as much information as possible about the application itself.
A lot of information can be discovered using information-gathering tools. This step is not that important compared to a penetration test performed against a network, API, or even a website. The reason behind this is that when performing a static analysis against the app (more details in the next section) more important information would be collected to better understand the app. So even if the reconnaissance step was not well performed the static analysis will cover it.
The process of application reconnaissance is still the same as for an API penetration test methodology or even a cloud penetration test methodology.
The first analysis that gets performed against a mobile application is the static analysis. In this step, the penetration tester tries to check the application without running it.
The mobile application is decompiled to retrieve the source code and to get some important files that may contain critical information about the app like androidmanifest.xml or strings.xml and more.
The idea is to try to both complete the reconnaissance step by trying to understand the application source code and to find quick wins. The quick wins could be as easy as finding some hard-coded passwords or some other critical information.
In some cases, complex applications could use C compiled codes to hide some algorithms from attacks. In this situation, the penetration tester tries to perform a reverse engineer against those custom libraries to reveal that information.
Another scenario that you can find a penetration tester is to deal with an app developed with iconic or any other hybrid mobile application development technology. In this situation, most of the time, once you decompile the app you find a nice html/js source code that can easily be reversed.
However, when the app is well secured, the developer performs an obfuscation process against the source code to make it difficult to understand. Therefore, a deobfuscation process needs to be performed to successfully perform static analysis.
While performing this analysis the penetration tester can take notes of possible attack scenarios that can be performed in a dynamic analysis.
Once the static analysis is completed, the application gets installed in a controlled environment to perform a dynamic analysis. In the dynamic analysis, the penetration tester tries to run the application to both understand the application logic that cannot be well understood using static analysis and to perform the attack scenario that was defined in the static analysis.
The dynamic analysis can cover multiple aspects of the app, like web traffic if the app communicates with an HTTP server or even the internal algorithms. In most cases, a big part of this dynamic analysis resides in testing the backend of the application. This means looking for API vulnerabilities like SQL injection, unrestricted file upload, and more.
Moreover, business logic vulnerabilities cannot usually be detected using static analysis. Therefore, testing the business logic vulnerabilities is also performed by the penetration tester in this step.
The dynamic and static analysis are complementary and can be performed in a spiral way to collect, design the test scenario and execute it in a dynamic way.
The post-exploitation step is similar to all the penetration testing methodologies. The penetration tester tries to get more privileges once he gets the first access to the app. However, depending on the scope defined by the app owner, system privileges escalation can or cannot be performed.
Once the penetration test is done, a detailed professional report should be written by the penetration tester. The report must contain two parts, the executive summary where statics about the number of critical, medium, or low vulnerabilities in the app. The second section should contain the technical details about how to reproduce the vulnerabilities in the development environment.
A proof of concept also should be presented in the report to prove the existence of the discovered vulnerabilities.
I am a Cyber Security Expert, I have worked with many companies around the globe to secure their applications and their networks. I am certified OSCP and OSCE which are the most recognized and hard technical certifications in the industry of cybersecurity. I am also a Certifed Ethical hacker (CEH). I hope you enjoy my articles :).
Fixing the discovered vulnerabilities after receiving the penetration test report is the most important process and the most time-consuming process. Therefore, one of the most common questions I get from ...
Undoubtedly, ChatGPT stands out as one of the most remarkable inventions of 2021. Its wide-ranging capabilities and applications have opened up endless possibilities for human interaction and problem-solving. Furthermore, certain [...]
Post comments (0)