Select Monthly Archives
- January 2020
- September 2019
- August 2019
- June 2019
- May 2019
- April 2019
- March 2019
- February 2019
- January 2019
- December 2018
- November 2018
- August 2018
- July 2018
- May 2018
- March 2018
- February 2018
- December 2017
- November 2017
- September 2017
- August 2017
- June 2017
- May 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- March 2016
- October 2015
- September 2015
- July 2015
- May 2015
- March 2015
- February 2015
- January 2015
- December 2014
- September 2014
- August 2014
- July 2014
- June 2014
- December 2013
- September 2012
Written By: Josh Brashars August 12, 2014
Introduction and Goals
So, you want to run a device through Burp Suite Professional (or the free version, we don't judge here), but the device doesn't allow you to change system or browser proxy settings? If you're using OSX, fear not and read on. This isn't very difficult if you're not afraid of the command line.
This example is using OSX version 10.8.5, but should work for any version after Mountain Lion since we'll be using the "pf" command line firewall and routing utility. Prior to Mountain Lion, OSX used ipfw for port forwarding, so these instructions won't work as-is.
What makes a device “Stubborn”?
When I say “stubborn”, I don’t mean this as necessarily a bad thing. In general, I’m referring to a network device that does not have an end-user accessible method of configuring a global, system-wide network proxy. This functionality is important if you’d like to perform a security assessment of applications on that device.
There are a lot of “Man in the Middle” proxies available, and we like to use Burp Suite Professional. Burp Suite Professional allows near-seamless interception and manipulation of HTTP-based protocols, including encrypted HTTPS. Modern “smart phones” running the Android or iOS operating systems make configuring a global proxy relatively straightforward, but some other devices do not allow global proxies. Or if they do, they require the use of Enterprise deployment software. In some cases, it doesn’t make sense to spend your assessment hours working out how to get Enterprise software to push policies to enable proxies, if such an option even exists.
A much better way would be to make a wireless access point that will shovel all HTTP/HTTPS traffic through our proxy, irrespective of endpoint software. And that’s where this blog entry comes into play.
Sharing The Access
In this example, we'll be using a Blackberry Bold 9900, but the advice should apply fairly universally. This phone doesn't have much in the way of host-mode USB or Ethernet, so we're stuck with wireless. That's fine - creating an ad-hoc wireless access point with OSX is easy.
The first thing we'll need to do is share our Internet connection. For set up, we'll need two network interface devices: one for the host computer running OSX to get Internet/network access from, and a separate interface to share with. The setup used for this demonstration has the Ethernet connection providing access to the MacBook, and is sharing network connectivity via the Airport wireless network card. You could just as easily use a second USB Ethernet if the device you are trying to proxy supports it, or a second USB wireless network card, provided that OSX recognizes it natively.
Click the Apple icon in the upper left hand corner of the screen and select "System Preferences…"
Under the "Internet & Wireless" section will be an icon labeled "Sharing", which is what we want to click. Do that now, I'll wait.
You ready? Good.
You should now see a menu that provides several sharing options. The one that we're interested in is "Internet Sharing". Select that option, but don't check the box yet.
You should now see a drop down menu that says, "Share your connection from:" with a variety of interfaces to select from. Since we're using wired network as our Internet access backend, we'll select "Ethernet" from this screen. You may choose a different option, but just be sure that whatever device you chose provides you network/Internet access.
Beneath that dropdown is the yang to the previous state's yin, the device through which you want to allow other hosts to connect. Since your Blackberry device has wireless but not ethernet, we're going to share out via our Wi-Fi. Check the box next to Wi-Fi, and then click the button that says "Wi-Fi Options…" (Apple sure does love their ellipses, don't they?). From here you'll want to configure a unique access point name, encryption method, and a password. Click ok when you're done.
Assuming this all went without a hitch we're ready to check the box next to "Internet Sharing". Read and acknowledge any prompts by clicking ok.
[Troubleshooting Pro Tip: If you can't edit any of these options, you may need to click the padlock icon in the bottom left hand corner of this screen to ensure that it is in the "unlocked" state. But you knew that, right? Right? If you didn't, are you really sure you want to be mucking with system routing options? Don't say I didn't warn you.]
If all goes well, at this point you should be able to connect your silly proxy-less device to your Mac via Wireless, or whichever method you chose for connectivity. To verify that everything is working properly, open a terminal (such as the Terminal app that bundles with OSX in the Utilities folder within the installed Applications Folder) and type:
You should see a new network interface, probably at the bottom of the screen. If you used Wireless, this interface is very likely called "bridge0". By default, the IP address of this interface should be in the 192.168.2.X range.
From this point on in the tutorial, we're going to assume that your bridge0 interface is in that subnet. In my case, and in most cases, this IP address *should* be 192.168.2.1. If for some reason your primary LAN uses 192.168.2.X for normal network addressing, well, you're on you're own here. Change that and get back to me. For everyone else, let's move on.
Now that we're properly sharing our Internet access we need to make it so that HTTP and HTTPS traffic get routed through Burp. By default, Burp proxy listens on the 127.0.0.1loopback interface on port 8080, so that's what we'll be using. If you've made changes to your Burp proxy settings, you'll need to accommodate for those below.
[Note that some devices may well require that Burp be configured in Invisible Proxy mode in order to work properly. This can be configured via the Proxy Tab, and the Options sub-tab. Select the proxy listener and click edit. Select the "Request Handling" tab and ensure "Support invisible proxying (enable only if needed)" and click OK. ]
Configuring Port Forwarding in PF
PF requires that our special rules be contained in a modular rule set called an “Anchor” file, so we'll create that now.
Create an anchor file under /etc/pf.anchors/forwarding with your redirection rules. We'll use vi here, but use the editor of your choice. We won't be going into vi's syntax here, so it's assumed you know how to use vi to edit and save files.
sudo vi /etc/pf.anchors/forwarding
With the contents as follows:
rdr pass on bridge0 inet proto tcp from 192.168.2.0/24 to any port http -> 127.0.0.1 port 8080
rdr pass on bridge0 inet proto tcp from 192.168.2.0/24 to any port https -> 127.0.0.1 port 8080
Your screen should look something like this:
Again, this is assuming that the interface you're using is bridge0, your new wireless network is in the 192.168.2.X subnet, and that Burp is configured to listen via the 127.0.0.1loopback on port 8080.
To break down this admittedly arcane looking bit of text, we’re redirecting all HTTP and HTTPS traffic via the bridge0 interface originating from the 192.168.2.0/24 subnet to the service at port 8080/tcp on the 127.0.0.1 loopback interface.
Next we need to test our anchor. We are going to use the pfctl utility to do this to make sure we don't have any errors:
sudo pfctl -vnf /etc/pf.anchors/forwarding
You’ll need to enter your password at this point to elevate your privileges. If you have errors, you're going to have to stop, roll backwards, and re-check your work. Just like in math class. If, however, you did not get errors, you should see a screen similar to this:
Now that we've created our anchor, we'll need to let pf know about its existence. We do this by creating an entry in the pf configuration file, normally stored at /etc/pf.conf.
sudo vi /etc/pf.conf
Again, you might need to enter your password at this point to elevate your privileges if there have been a few minutes since you last entered the previous sudo command. You should see the something similar to the screen below. I’ve highlighted the areas that will become important in the next step.
Look for the line in the pf.conf file that says:
And immediately after that line, enter the following:
Further down the file, you'll (probably) see another entry that says:
load anchor "com.apple" from "/etc/pf.anchors/com.apple"
Immediately following that line, enter the following:
load anchor "forwarding" from "/etc/pf.anchors/forwarding"
Here comes the important part. Make sure there's an extra line break at the very end of the file, otherwise you'll get syntax errors. Just make sure there's an empty line at the very bottom of the file.
If you've followed the steps exactly, you should see something like the following screen. Our changes have been highlighted in blue, and you may notice that there’s an extra line at the very end of the configuration file. Do not forget that extra line.
The pf firewall is not enabled by default so we'll need to instantiate it. The easiest way to do this is to execute the following command:
sudo pfctl -ef /etc/pf.conf
…Where /etc/pf.conf is the location of your pf configuration file. If you're following this guide to the letter, you shouldn't need to change this. These changes will not persist across a reboot, so you'll need to re-run this command if you have to restart your computer. Similarly, if you screw something up, rebooting should correct the problem.
You can configure this to load automatically if you choose, but I wouldn't recommend that unless you really know what you're doing. And if you really know what you're doing, how come you're reading this? Huh? That's what I thought.
Validating via Burp Suite
At this point, you should be good to go. Connect your device to the new wireless network you created and attempt to access something via that device's web browser. Hopefully you'll now be seeing entries from your mystery device in the "HTTP history" tab of Burp's Proxy element. That is, unless you forgot to disable Burp's Intercept option, in which case the request will be trapped in that tab. And hey, don't forget to stop sharing your Internet connection when you're done, you don't want those pesky hackers poking through your system.
If you're not getting any results then you either missed a step, made a configuration error, or your device isn't happy and is silently failing on the shady Burp Suite Pro PortSwitgger Root CA. Since this certificate authority is not a "Trusted CA" by most browsers, you're going to have to deal with a lot of errors. You may be able to get around this by exporting the root CA certificate manually and importing it into your device and manually adjust its properties as "Always Trusted".
Sure, some of you out there might be saying “this would be way easier to do in Linux with iptables”, and you might be right. We’ll revisit that use case in a future example, but for now I wanted a way to quickly be able to test a mobile application, without requiring an additional laptop or messing around with Virtual Machine pass-through USB shenanigans.
Hopefully at this point you've got traffic going through Burp's HTTP history tab, and now you can do whatever you need to do in order to test the mystery device. If not, you can always hire AppSec Consulting to do it for you.