Mobile App Penetration Testing Methodology
Mobile App Penetration Testing often has a different flow to web application or network testing. This is because not only do you get the application but you also get the software itself. This runs on a device you control and allows for a much wider attack surface. It also allows decompilation of code and hooking of calls all in service of attacking the application. As such, mobile app pentesting requires an entirely different skill set, knowledge base, and methodology. Most mobile application penetration tests rely on the OWASP-MASVS (Mobile Application Security Verification Standard). Senior application developers and hackers are responsible for developing this to ensure that applications meet minimum security requirements. The content in this blog comes from the OWASP-MSTG which is one of the most complete methodologies available.
Types of Testing
Black-box Testing happens without the tester knowing anything about the program they are evaluating. This method is frequently referred to as “zero-knowledge testing”. The goal of this test is to let the tester act like a genuine attacker. It does this by investigating potential applications for publicly available and discoverable data.
White-box Testing (also known as “full knowledge testing”) is the polar opposite of black-box testing. This is because the tester knows all there is to know about the software. Source code, documentation, and diagrams are all examples of knowledge. Because of its openness, this technique enables faster testing than black-box testing. With the additional knowledge they gain, a tester may create far more complex test cases.
Grey-box Testing encompasses any testing that falls in between the two methods of testing described above. The tester gets some information (typically merely credentials) and must find the rest themselves. This form of testing strikes a good balance between the number of test cases, cost, speed, and breadth of testing. The most prevalent type of testing in the security business is grey-box testing.
Starting a Test
Once the scope of a test is agreed upon, it will fall to a tester. They will usually get an application file, depending on the platform (Android or IOS). This will be an APK or an IPA file respectively. The first thing that will usually happen will be the application loads onto a device. It is simply viewed as though it were a normal user. This teaches the tester about the process flow so they get a ‘feel’ for how the application works.
Once they understand the application in general, it’s time to understand its functionality in more detail.
Disassembly and Static Analysis.
Now we know how it works and what problem it seeks to solve, it is time to look at Mobile Application Testing in depth. The application will be pulled apart using some kind of DE compilation software. The most common ones are :
Just to name a few. Once you have the source code in front of you, you can then start looking for system capabilities that could be open to exploitation. Note that this will only work for APK files on Android. This process is often easier in APK files as they are often in Java, whereas IPA files come with a number of other factors to consider. This process is crucial in finding processes that may need attacking, bypassing, or avoiding during the dynamic testing phase.
Now the tester can look at the code quality and ensure the use of best practices during the development process. Applications can have a number of issues if the actual code has out-of-date libraries, ensure random number generation, hardcoded keys, etc. Checking all of this only happens during this phase when the attacker has access to the actual code of the app.
Once the attacker knows all about how the application functions, he can put it on a device and start attacking it. This is typically in an emulated environment to give the best possible advantage to the attacker. Tools Like Frida and Objection can be used to attack the app as it is running, changing memory, and what certain methods return to bypass protections and manipulate the app. This is the magic of mobile application testing, it allows the attacker to manipulate the actual software of the application to their whim. Because of this, it is generally not the best idea to keep private information on the device but stored on a secure server within the organisation’s control.
Completion of the Test
Once the test is completed, its findings need to be reported and correct remediation included with every issue. At Sencode we offer mobile application penetration testing with comprehensive testing reports, a free retest, and support during the test. A mobile application penetration test is useless without a valid and effective report that identifies security issues.