Once again, we need to talk about Burp.
At Schellman, we’ve talked about this tool before—on our penetration testing team, we use it a lot and it serves us well, including in our work with mobile applications.
But that doesn’t mean there still aren’t situations where extra effort is required in order to get the job done. Our fellow pen testers all know that things evolve so quickly in our field that sometimes we must improvise a new technique to properly solve to the problems we run into.
Stop me if you’ve heard this one before, but one such issue that we are seeing crop up more and more during mobile penetration tests has to do with intercepting traffic from an application.
Each time we watch some of that traffic escape our data flow, we’ve found each instance difficult and puzzling, because it’s not a static problem—when it comes to intercepting traffic from mobile applications, the issues can range from common to complex.
One of those trickier ones to troubleshoot as a tester is when you can see most of the general web traffic from the mobile device being tested as it goes to Burp, but you also see that none, or very little, of the traffic from the actual mobile app under test follows.
When that happens, you probably also note that there are no TLS errors for the domain in scope in the Event log from the Burp dashboard, and that, at the same time, the app seems to be working well, performing requests and receiving data as expected—there’s no other problem, it’s just that some of that traffic has decided to shoot off to the Great Unknown rather than where you know it should be.
Does that sound familiar?
If you’ve been frustrated by this same problem before, welcome to the club. This article will seek to understand why this even occurs in the first place before laying out a potential solution we worked up to curb any traffic trying to escape your proxy. Read on, and next time said traffic tries to get away from you, you’ll be ready.
Why Does This Happen?
When you do encounter escaping traffic, it’s most likely due to the way the mobile app you’re working with was written or perhaps the problem goes a layer even deeper than that—it might be that something within the framework that was used to write the app is affecting the traffic pattern and is thereby causing you headaches.
We say that because, in our experience pen testing mobile apps, we've seen apps written with the Xamarin framework ignore the Wi-Fi proxy settings. Other, complex apps that are network-heavy seem to handle their traffic with their own logic or with lower-level libraries and bypass the proxy settings as well.
Knowing that now, you may feel a sudden urge to reverse-engineer your application to gain your own deeper understanding of what you’re working with, but you don’t have to—there is actually a lesser known, and yet almost bulletproof way to get those requests/responses into your HTTP proxy tab.
How to Force the Capture of Traffic from an App to a Proxy
Put simply, if you’re testing a mobile device and you want to capture all traffic, use a VPN.
We know—it’s typical to use WiFi settings here, but in fact, a VPN is much more reliable for use in this because they’re literally designed with a hard requirement to direct all traffic through themselves. Think about it: if an app was somehow bypassing the VPN connection for some of its traffic, that could be seen as a privacy issue and a security bug in and of itself, worthy of investigation.
But if the VPN is functioning as it should, setting up a VPN server in the middle between your mobile device and the host running Burp is a sure way to get control over the traffic.
As a disclaimer, it’s possible that, in taking this path, you may still encounter issues with certificate pinning, and you may have to tinker with Frida, but as a baseline solution, running a VPN server forwarding to Burp will let you see all the traffic through either Burp or TLS errors.
How to Set Up an OpenVPN Instance and Forward Traffic to an Instance Running Burp
So how to do that? Next, we’re going to provide a step-by-step process on exactly how to use a VPN to solve your escaping traffic problem when dealing with a mobile application.
(The setup we are going to describe below requires the use of a local Kali VM with Burp. Some of these steps may need to be adapted if you are running your pen test environment differently—like if you’re in the cloud.)
Step 1: Set Up Your Burp Proxy to Receive Network Traffic in an Invisible Way.
Start your new Burp project with the following options.
The two screenshots of the Burp interface below show setting the proxy to a specific internal address, in the same way you would when using the mobile device system proxy setting:
In the edit window of the Proxy Listener, you also want to check the "support invisible proxying" option, which will ensure the traffic seamlessly goes from the mobile device to the VPN, to the proxy, and back.
Step 2: In a Separate VM, Install OpenVPN.
While installing OpenVPN is beyond the scope of this tutorial, there are several well-known and vetted Linux community scripts to automate the process. Please review any script before executing.
Step 3: Generate an ovpn File for Your Client.
We’re talking mobile apps, so in this case, this is the mobile client. You don’t have to do much to this client ovpn file—just make sure the remote value is set to the internal IP of the OpenVPN server. For example:
- remote 192.168.0.108 1194
Step 4: Route Traffic from the VPN Server to the Burp Instance.
You do that with the following commands:
- iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination [BurpIP]:8080
- iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination [BurpIP]:8080
Step 5: Save the Rules.
Because you don’t want to have to repeat these steps every time you reboot the machine, save everything:
- Debian-based distributions:
sudo /sbin/iptables-save > /etc/iptables/rules.v4
- Centos-based distributions:
sudo /sbin/iptables-save > /etc/sysconfig/iptables
Step 6: Restart the VPN.
May seem pretty self-explanatory, but after saving the new forwarding rules, run the following command to restart the OpenVPN service and apply the changes:
- systemctl restart openvpn
Step 7: Copy the File Over Your Mobile Phone.
You can always set up a local web server to fetch the ovpn file from your mobile phone—which should be connected to the same trusted network through Wi-Fi—using python3’s http.server module or a similar temporary local web server. (If you do not fully trust your network, we recommend using a TLS version instead.)
- $ python3 -m http.server
From your mobile phone, browse to http://[VPN-IP]:8000/mobile.ovpn—or the name you gave to the ovpn file.
Step 8: Install the OpenVPN App on Your Mobile Phone.
You can download it from the Apple App Store or Google Play Store. Once that’s done, import the ovpn file. You should be able to see connection stats, as you can see an example here on an Android device.
Step 9: Use the OpenVPN Mobile Interface to Connect to Your VPN.
Traffic—that’s all traffic—should start flowing to your Burp proxy for all mobile applications. The public address for the mobile device will be the one from the host running Burp Suite. Here you can see traffic captured within Burp.
Additional Benefits
Though we’ve been using this setup to help testing with mobile devices, you might be encouraged to hear that the usefulness of this technique actually goes beyond just those.
Here at Schellman, we’ve used this same method to save us many hours during our various engagements—it’s helped us with a number of things, including testing things like:
- Command line tools;
- PowerShell modules;
- Thick clients; and
- A wide range of binaries making requests over the Internet.
Need more convincing? Since the OpenVPN client is ubiquitous on all main operating systems, it also helps save costs over commercial proxy solutions geared at single platforms.
Saving on cost for a tool that also has a broad spectrum of use seems pretty good to us, we can personally attest that the investment—and this method for capturing traffic—has yielded more efficiency for our team and a more thorough test for our clients. If you’re able, see what you think, and hopefully it’ll benefit you too.
If you're also interested in learning more about Burp, check out our article on how to write your own Burp extension and become even better versed in your use of this tool.