As web applications continue to proliferate in the attack surface and more people make protecting them a priority, there is also a shift in the definition of a “web application,” and how we understand their potential vulnerabilities. A perfect illustration? OWASP finally incorporating APIs in their Top Ten.
While this is a good start, we as a community need to continue to push the envelope on how we look at web application security: A web application’s vulnerable surface is any part of the web surface—from the back end devices, to the web front end, and everything in between. This includes not just APIs, but also mobile apps. Hackers have been using these “side channels” to go after our web applications for years, but the industry has treated mobile apps and APIs as separate issues, not parts of the complete application attack surface. Our challenge to you? Start seeing mobile applications as not just separate “applications” or attack surfaces, but instead as pieces of the greater whole.
There are two main facets in understanding the attack surface of mobile applications: the side related to the device on which a client is installed, and the side associated with the http traffic through which apps communicate with web services. While both are important, today we will focus on the latter; understanding how your application is interacting with your web services, what security mechanisms you have in place, how effective they are, and the insights gained from the application’s traffic are crucial. Why? Your mobile application is subject to many of the same attack types that your web front is. Problem is, most people don’t even recognize this, let alone secure their apps accordingly. Others make weak attempts at securing their mobile applications by using sweeping—ultimately ineffectual—security practices.
A good example of this is SSL pinning. SSL pinning restricts access to URLs whose SSL certificates have been pre-approved for communication (for a more in-depth understanding of SSL pinning, check out OWASP’s guide). SSL pinning is supposed to keep an attacker from conducting MITM (Man in the Middle) attacks and, as such, protect the web service and mobile application. SSL pinning can also be an obstacle for DAST (dynamic application security testing) tools when scanning a web service. This, however, can easily be overcome by simple apps such as Frida. These apps can be installed on mobile devices, or for more sophisticated implementations, by tearing apart the mobile application and identifying where the “pre-authorized” certs are stored—this allows DAST tools (including our AppSpider product) to add their own certs, thus becoming “authorized.” Once we have done this, we are able to MITM the mobile application, allowing us to test the app with a DAST tool. Keep in mind that this pinning is done on the mobile application side and not the web service side, so once we understand and have evaluated the traffic, we can attack the web service using this information.
This gives us a couple of options to begin the process. As we are testing an application’s web service, we can shortcut much of the work by looking at the web service itself. This can be done manually using a proxy, or in the case of AppSpider, automated if the API is documented using Swagger. This allows us to go straight to the source and test the API itself. If the application is “protected” by SSL pinning, we must first bypass the pinning process before we can MITM the traffic.. If this is an Android app, we may be able to use a tool such as Frida which allows you to bypass SSL pinning. We all need a Plan B: We can also grab the .apk file and open it up. Once opened, we can begin looking for the cert stores being used. Once found, we can add our proxy server’s certificate, repackage the .apk, and install the modified app. The modified app containing the proxy server’s cert allows us to MITM the traffic, as our proxy server is seen as a “pre-authorized” cert. If this is an iOS application, then we need to pull down the application (just as we did with the .apk) and modify it, but we will need to use an internal app store to publish and install on our iOS device. Keep in mind—we do not need an Android or an iOS device to do this, as we can use an emulator.
Once we are able to MITM the traffic, we can inspect the data streams to look for weaknesses in the communication channels as well as test the web service that the mobile app is talking to. This can be done manually, or with an automated tool such as AppSpider. Let’s take a look at how a standard MiTM approach, without SSL pinning circumvention, is accomplished:
First, we’ll configure AppSpider to act as our proxy and traffic capture mechanism.
Find out the IP of the box AppSpider is installed on and record it. You will need it when configuring the mobile OS emulator’s network connection.
Open AppSpider and navigate to Tools > “Traffic Recorder”
Next, from the Traffic Recorder, go to “Proxy Settings.” Stop the traffic recorder and set the IP address as well as a port (we’ll use 8080) in the Traffic Recorder settings, and hit “Run.”
Now let’s configure our emulator. First, we need to decide which emulator to use, since there are many options: paid, free, and/or open-source, etc.. Some are useful and easy to use, some are “OK” but lack features that we need, some are projects that are no longer developed, and some might be thinly veiled pieces of malware (so consider the source). Feel free to use whatever works best for you, but I’d recommend what you’ll see here in the demo—Android Studio. It’s free, it’s developed by the same folks that develop the Android operating system (Google), and there is a wealth of documentation online for configuration.
In Android Studio, we first need to create the emulator itself.
- Open the AVD (Android Virtual Device) Manager (Tools > Android > AVD Manager)
- Click “Create virtual device"
- Now, select the hardware and OS version. This is up to personal preference, but I went with an older phone model, a Nexus 5-running Oreo. If this is your first time building an AVD, you might be prompted to download the Android image.
- Click “Finish,” and your emulator is built!
Now we’ll power on the emulator and configure it to connect to our proxy.
First, verify that you have an internet connection.
Click on Settings > Network & Internet > Mobile network > Access Point Names
Click the plus sign to add a new APN, and fill out the following values:
- Name: AppSpider
- APN: This can be anything, but a value is required
- Proxy: IP of your AppSpider machine
- Port: Port # that you specified in the AS Proxy config (default is 8080)
- The rest of the values can be left blank
* Hit “Save” and select the APN that you just created
- Ensure that your AppSpider proxy is running, then open up Chrome on your Android emulator. Browse to a website (i.e. hackazon.webscantest.com) and the traffic logs should start appearing in the “Traffic Log” area of AppSpider.
- Now that we’ve verified that we are able to capture the traffic from the Android emulator, let’s install a mobile application. For this example, we are going to use the Hackazon mobile app. This can be downloaded from the Rapid7 github, and installing it onto the emulator via Android Studio is as easy as dragging the .apk onto the emulator’s desktop.
- Let’s launch the Hackazon app and start browsing around. Notice that, like in Chrome, the traffic is being recorded in AppSpider.
- Once you are done with whatever operation you are recording, select “Save” from the “Traffic Log” area give your traffic recording a name.
- Next, import that recording into AppSpider via the “Recorded Traffic” section of the scan configuration.
- Optionally, you can restrict the scan to include only the recorded traffic (in this case, the mobile application traffic), which is what we’ll do here. Before you initiate the scan, you are also able to review the individual requests as necessary.
- Start the scan and review the results when complete!
In summary, we have discussed how to use a proxy to test a mobile application, along with the main “security” configuration (SSL pinning) that companies have been relying upon, and how to overcome this security configuration. You are now able to better understand how to test mobile applications, as well as understand how attackers are bypassing SSL Pinning to attack your application (even when you thought it was “secure”).
In the next blog post of this two-part series, we will go further in-depth on the specifics of circumventing SSL pinning to test mobile app web services with MITM attacks, so keep tuned!
In the meantime, try AppSpider for yourself with this free trial!