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! Learn more here.
Before we go any further, here are some things to keep in mind:
- For the sake of this post, I’ll assume that you have an Android phone. It does NOT need to be rooted. You can also use an emulator, such as Genymotion or the one included in Android Studio. Setup is relatively straightforward, and these guidelines should still apply.
- I will also assume that you have some general security testing or bug hunting knowledge. I’m not going to cover tactical bug hunting techniques in this post–just the setup. Stay tuned for posts on how to actually perform a mobile pen test in the coming weeks and months.
- We’re going to configure Burp Suite in this post, but if you’re partial towards another proxy, the details will differ, but this information will still apply, as the concepts are the same.
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.
Anatomy of a Mobile Pentest
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.
Traffic/Network and Server-Side Vulnerabilities
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.
Setting up your Android Device
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:
- Setting up Burp Suite to communicate with your device
- Configuring the settings on the device
- Installing the certificate
Setting up Burp Suite
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.
- All you have to do is ‘Add a Listener’ which you can find under Proxy -> Options.
- Select Specific Address and select the IP address of your computer, and enter 8080 as the port (or whatever port number you’d like to bind to).
Configuring the Settings on the Device
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.
- Navigate to your WiFi settings, located in Settings.
- Long press the WiFi network that you’re connected to
- Click on Manage Network Settings
- Click on Show Advanced Options
- Under Proxy, select Manual
- The Proxy Port should say 8080, which is the default listening port for Burp. Heads up: Just because the field says 8080 in it, doesn’t mean it’s actually set to port 8080 (very annoying). You actually have to enter 8080 into the field. If you’ve configured Burp to listen on another port, configure it to that port instead.
- Under Proxy Host Name, enter the IP address of the wireless interface. For Mac and Linux, you can run ‘ifconfig’ in Terminal to obtain the IP address. If it’s unclear which IP address you need, look for the IP address of the router on the network you’re connected to via WiFi. It will be associated with that same interface.
Installing the Certificate
Now that the settings on your device have been configured, you’re ready to install the certificate.
- First check to make sure settings have been correctly configured by navigating to
http://burpon the proxied device. It should direct you to the website where you can download the certificate.
- Click on CA Certificate. In most cases, it should automatically download the certificate.
- After it downloads, click on the certificate to open it. Click on it and choose “Use for VPN and apps”.
- Once you’ve installed the Burp Suite certificate on your mobile device, Burp Suite is now trusted, and encrypted communication can now be decrypted when being proxied.
- Now navigate to an HTTPS site, such as http://bugcrowd.com. If Intercept is off, you should be able to see the traffic in HTTP History, including the content within the requests that would otherwise be encrypted due to SSL/TLS.
If so, you’re ready to start hacking mobile apps! Additional details about our current mobile contest:
- From July 1st through September 30th, 2016, every valid and non-duplicate mobile vulnerability submitted will be entered into a raffle to win one of two cash prizes, $1000 each.
- Each valid submission equals an additional entry into the contest, so if you’ve submitted five valid bugs you will have five entries to win $1000! (By submitting valid mobile vulnerabilities, you may also qualify to receive invitations to private mobile testing programs. Read more about how we measure researcher performance.)
- To get started, email email@example.com or learn more here.
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.