In this post, I will provide a brief overview of the anatomy of a mobile penetration test, and cover the first step in getting started with mobile testing on an Android device. My goal is to help folks that are new to mobile testing break the barrier of getting started, and debunk the assumption that mobile application testing is too difficult.
Hopefully, by the time you’re done reading this post, you’ll have the resources you need to set up an Android device for testing, and will be ready to start hacking on some mobile bug bounties. After all, mobile testing isn’t particularly difficult, especially if you know how to test web applications. Much of the web related vulnerabilities are more or less the same, and yet there is less competition in mobile bug bounties, and there is good money. Now is the time to get started! We’re running a raffle all valid and non-duplicate mobile vulnerability submitted through September 30th, 2016!
Before we go any further, here are some things to keep in mind:
For the purpose of this tutorial, we’ll be covering how to proxy the traffic, which is useful in executing attacks such as SQL injection, CSRF, IDOR, and other common web app vulnerabilities. Those of you who are accustomed to performing web application pen tests, simply proxying mobile traffic is more than enough to get started testing mobile apps. The most impactful mobile vulnerabilities are related to the traffic and backend servers, similar to what you’d find during a web application pen test. To elaborate more on this point, let’s take a quick look at the anatomy of a mobile pen test.
Mobile testing can be broken down into three different components: client-side, traffic/network, and server-side. Although they’re not mutually exclusive, viewing the mobile landscape this way helps to better understand the testing environment and the associated vulnerabilities. In a future post, we’ll discuss the benefit of testing all of these components cohesively, and explore both Static Application Security Testing (SAST) and Dynamic Application Secuirty Testing (DAST) solutions and how they complement one another.
The good news for web application testers is that the network and server-side vulnerabilities are largely the same in mobile testing. The main difference is the use of APIs in mobile apps. Understanding vulnerabilities associated with APIs will prove useful, but ultimately you’re still looking at HTTP requests and responses, just like you see when looking at web traffic. One notable difference, given the use of APIs, is that you’re not looking at vulnerabilities related to JavaScript, such as Cross-site Scripting or Content Spoofing. Those vulnerabilities can still be found if the app utilizes web views, but they’re certainly not as prevalent in mobile apps. The other good news is that the network and server related vulnerabilities are where the higher impact vulnerabilities are found such as IDOR, insufficient authentication and authorization, SSL attacks, file inclusion, XXE, SQL injection (against the server), among others.
Client-side vulnerabilities on the other hand, typically require the attacker to have access to the physical device, which automatically lowers the likelihood of an attack. Also, security controls exist for both Android and Apple that help protect against attacks associated with the loss of theft of physical devices, such as remote wipe, lock screens, and device encryption. Additionally, testing for network and server-side vulnerabilities doesn’t require a rooted device while testing for client-side vulnerabilities typically does.
Common client-side vulnerabilities include insecure storage of sensitive information (passwords, credit card numbers, and other PII), hardcoded sensitive information (API keys, admin credentials, staging credentials and URLs), broken client-side cryptography, not hardening against reverse-engineering, etc. Testing for these vulnerabilities will be covered in later posts.
Now that we have a better idea of the anatomy of a mobile pen test looks like let’s look at how to set up your Android device so that the traffic can be passed through Burp Suite. The process can be broken up into:
We’ll only briefly touch on this since it is essentially the same as when you’re testing web applications. For additional resources on setting up Burp Suite in general, watch our tutorial by Jason Haddix.
Now that Burp Suite is ready to go, you can now set up the mobile device so that it’s traffic gets proxied through your computer. The first requirement is that your mobile device and your laptop are on the same Wi-Fi network so that they can communicate.
Warning: If a WiFi network has AP isolation enabled, which is quite common on a corporate network, your computer and mobile device will not be able to communicate. If you follow these steps carefully, and you’re still unable to proxy the traffic, try another network, such as your home network.
The goal here is to get the traffic that’s being sent from your Android device routed to your laptop, through Burp, and then sent to the backend web services which exist out in the internets. Similarly, any traffic sent from the web services will first pass through your computer, including Burp Suite, and will then be sent to your device. The next step is to configure the device’s proxy settings.
Now that the settings on your device have been configured, you’re ready to install the certificate.
http://burp
If so, you’re ready to start hacking mobile apps! Additional details about our current mobile contest:
Stay tuned for upcoming posts, in which we’ll set up our environment so that we can look for client-side vulnerabilities, and take a look at some actual vulnerabilities.