How to Build Your Own Mobile Application Testing Lab

How to Build Your Own Mobile Application Testing Lab

Figure 1. Example /etc/config/wireless with WiFi enabled.

Next, modify the subnet mask in “/etc/config/network” so it does not overlap with any other subnets in use on the local network. In this example, the 192.168.3.0/24 network is selected. This modification is highlighted below in a copy of the router’s modified “/etc/config/network” file.

Figure 2. Example /etc/config/network file with modified IP address.

Next, reboot the router to ensure all changes are working correctly and are persistent. At this point, the router should broadcast the “MobileSecTest” SSID using the password specified. The Ethernet cable can now be disconnected, and the proxy machine can connect to the wireless network. Connect both the test device and the system that will act as a proxy to the test access point’s wireless network. Now, use an Ethernet cable in the test router’s WAN port to connect to a network with access to the internet, such as a cable modem or another router.

Step 3: Configure Proxy

On the proxy system, start the proxy application you plan to use. In this example, we’ll be using Burp from Portswigger. The only changes we need to make from the proxy system are to disable (or create appropriate permit rules in) any host-based firewall, configure the proxy to listen on the external interface, and to enable “Invisible” mode in the proxy. The host-based firewall settings are going to be operating system-dependent. The last two settings are controlled under the Proxy and Options tabs. Edit the default listener generated by Burp. The screen capture below shows these tabs:

Figure 3. Burp default proxy listener configuration.

Either set the listener to run on all interfaces, or just the interface connected to the testing network. This address will be needed again, so make sure to remember it.

Figure 4. Setting the appropriate proxy listener interface in Burp.

Since the intent is to eventually relay traffic to the proxy system without manual configuration on the test mobile device, invisible proxy support must be enabled on the “Request handling” tab as shown below:

Figure 5. Configuring invisible proxy mode for Burp.

Step 4: SSL/TLS Interception

With the proxy correctly configured, it is time to set the mobile device’s manual proxy. The manual proxy setting is only used temporarily to ensure the proxy system is working and to load the certificate onto the mobile device for SSL/TLS interception. Portswigger has provided walkthroughs for several mobile operating systems here:

Android Devices
IOS Devices
Windows Mobile Devices

Once the proxy system has been determined to be working properly, and the certificate has been successfully loaded onto the mobile device, the mobile device’s manual proxy settings can be removed.

Step 5: Configure IPTables

The last step in establishing your mobile application testing lab configure the firewall on the testing router to pass all traffic to the proxy system. Before modifying the firewall configuration, it’s important to back up the current configuration. Even though this method does not permanently write the iptables changes to the router, it’s often convenient to stop proxying traffic by reverting to the original iptables configuration without rebooting.

The iptables-save command writes the configuration to a file that can be read back with iptables-restore if needed:

Figure 6. Command line for backing up the current iptables configuration.

Now the firewall configuration can be modified without fear of losing the ability to route traffic normally. The goal here is to route all mobile device traffic that is pertinent to the application through our proxy system at 192.168.3.249.

The script does not use command line arguments since it proved to be extremely difficult to implement effective input sanitization with the default version of OpenWRT. The following shell script performs traffic routing and ensures that the router logs all other traffic from the mobile device. In doing so, no pertinent network traffic will be missed during testing.

Figure 7. intercept.sh script for configuring iptables traffic routing rules.

The first part of the script is dependent on the individual mobile application testing network. Bold elements in the following section of the script should be modified to apply to individual testing environments:

Figure 8. Variable definition section of the intercept script.

The next section configures iptables logging in case the device uses communication on a port other than TCP 80 (HTTP), TCP 443 (HTTPS), and UDP 53 (DNS):

Figure 9. Script segment to log unintercepted traffic.

Next, the script routes all network traffic coming from our wireless testing environment on ports 80 and 443 to our proxy system on the appropriate port. If you are testing an application or device that uses another port, you may have to add that port to this section as well.

Figure 10. Script segment to route network traffic to the proxy system.

Finally, the script changes routing rules to allow the proxy to send traffic to the internet.

Figure 11. Script segment to allow outbound traffic from the proxy.

At this point, running the interception script should route all traffic from the mobile device on ports 80 and 443 through Burp on the proxy. This traffic should be visible on Burp’s “Proxy” tab. After using the application to populate Burp, it is prudent to check the router’s logs to see if there is any traffic that is operating a port other than 80 and 443. In our OpenWRT instance, these can be found using the “logread” and looking for any kern.warn messages. The logs that follow were generated using the command:

Figure 12. Command line to find iptables “kern.warn” level events.

The DPT field shows which port should be added to the script. The following screenshot depicts communication between the testing host and port 8081 on a remote system. There are also logs for some UDP communication that was not pertinent to the application being testing.

If the application uses non-HTTP traffic (much more common with IOT and thick client apps as opposed to mobile), then a different proxy application that is either specific to the protocol or uses a protocol-agnostic proxy must be used in place of Burp.

At this point, the test environment should be ready to begin running dynamic tests against the application and the associated server-side components. The following is a screenshot of Burp successfully proxying traffic generated by the Gmail Android application.

Figure 14. Burp successfully intercepting GMail for Android network traffic.

After following this five step process, you should have a wireless access point that is configured to intercept network traffic from any device connected to the access point. Any time a new mobile or smart that uses WiFi for its internet connection needs to be tested, simply run the intercept script to begin traffic interception. This setup allows testers to intercept, view, and modify network traffic to find vulnerabilities as they would when testing other web-dependent systems. Before you know it, you’ll have your own mobile application testing lab.

Written by: Stephen Deck

Stephen Deck is a Senior Security Consultant with over 15 years of experience in the information technology field. He currently focuses on performing software security assessments, but has also spent several years in incident response, security engineering, and software development.

Before joining DirectDefense, Stephen worked for Synovus Financial Corporation doing application security testing of in-house developed applications, embedded systems, and COTS software. Prior to Synovus, Stephen worked for Aflac Incorporated and focused on testing software as well as handling security incidents and engineered security solutions. Stephen also spent eight years developing software as a federal government contractor and four years as an infantry officer in the US Army.

   By: Rebecca Deck   01.19.18