[Q] Using BURP to intercept Windows 8 Phone Traffic

Search This thread

shadowD1026

Member
Feb 3, 2014
30
0
Seattle
Hello - Does anyone have a step by step on how to intercept SSL App Store traffic using BURP and a Windows 8 phone? I know that installed the BURP cert onto the phone is required. So steps on how to do this on the Windows 8 Phone would be great appreciated.
 

DaviUnic

Senior Member
May 12, 2011
122
25
Hello - Does anyone have a step by step on how to intercept SSL App Store traffic using BURP and a Windows 8 phone? I know that installed the BURP cert onto the phone is required. So steps on how to do this on the Windows 8 Phone would be great appreciated.

Whatever you're trying to do, it probably won't work due to certificate-pinning.
 

DaviUnic

Senior Member
May 12, 2011
122
25
The store does. This basically eliminates any possibilities of MITM attacks without having the root MS certificate.
 

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
*SIGH* stop assuming things, people. Burp Suite is a *very* standard pen-testing tool. "The App does not use cert pinning" was a dead giveaway that the OP was talking about pen-testing a mobile app.

In theory, the process is really simple. Export the Burp public CA (Proxy -> Options -> Proxy Listeners -> CA certificate; make sure to rename it as a .CER file) and send it to the phone (Bluetooth, email, etc.; you should get a prompt to import the cert). Unfortunately, Burp is kind of lazy about how it generates its root certificates, so by default, the phone doesn't treat them as CA root certs. You can generate a custom cert manually and install it on the phone + have burp use it, but that's only going to work for one domain at a time and is a total pain. The other approach that I've found to work (which is silly, but hey, it *does* work) is to do the following:

1) Install Fiddler along with Burp (if you're not on Windows, you can probably use Fiddler via Mono).
2) Run Fiddler, enable SSL interception, disable automatic platform proxy configuration, set the proxy to listen on external connections, and install its root CA cert to the phone (similar to the way you do it from Burp).
3) Set the phone's WiFi proxy options to connect to the Fiddler IP and port.
OK... so far, you're now in a position to intercept traffic. If all you need is basic proxying, this is actually sufficient all by itself, and Fiddler does have a few cool features of its own. However, if you need real pentesting tools, like Burp Suite provides, there's a way to get that anyhow:
4) Run Burp, and set it to listen on a different port than Fiddler is using.
5) In Fiddler's options, configure it to use Burp as the upstream proxy.
6) Disable interception in Fiddler (so you don't have to manually forward traffic all the time) and proceed to use Burp as normal.

Yes, this is silly. It's the easiest solution I've found thus far, though, and I've used it myself.
Heh... I probably just gave technical advice to a competitor. Ah well. Good luck breaking stuff!
 
Last edited:

shadowD1026

Member
Feb 3, 2014
30
0
Seattle
*SIGH* stop assuming things, people. Burp Suite is a *very* standard pen-testing tool. "The App does not use cert pinning" was a dead giveaway that the OP was talking about pen-testing a mobile app.

In theory, the process is really simple. Export the Burp public CA (Proxy -> Options -> Proxy Listeners -> CA certificate; make sure to rename it as a .CER file) and send it to the phone (Bluetooth, email, etc.; you should get a prompt to import the cert). Unfortunately, Burp is kind of lazy about how it generates its root certificates, so by default, the phone doesn't treat them as CA root certs. You can generate a custom cert manually and install it on the phone + have burp use it, but that's only going to work for one domain at a time and is a total pain. The other approach that I've found to work (which is silly, but hey, it *does* work) is to do the following:

1) Install Fiddler along with Burp (if you're not on Windows, you can probably use Fiddler via Mono).
2) Run Fiddler, enable SSL interception, disable automatic platform proxy configuration, set the proxy to listen on external connections, and install its root CA cert to the phone (similar to the way you do it from Burp).
3) Set the phone's WiFi proxy options to connect to the Fiddler IP and port.
OK... so far, you're now in a position to intercept traffic. If all you need is basic proxying, this is actually sufficient all by itself, and Fiddler does have a few cool features of its own. However, if you need real pentesting tools, like Burp Suite provides, there's a way to get that anyhow:
4) Run Burp, and set it to listen on a different port than Fiddler is using.
5) In Fiddler's options, configure it to use Burp as the upstream proxy.
6) Disable interception in Fiddler (so you don't have to manually forward traffic all the time) and proceed to use Burp as normal.

Yes, this is silly. It's the easiest solution I've found thus far, though, and I've used it myself.
Heh... I probably just gave technical advice to a competitor. Ah well. Good luck breaking stuff!


You are always such a a help on these boards. It's great. Would the same be true if using the emulator? Or would that differ?
 

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
The emulator is a full virtual machine, so it almost certainly has its own cert store (instead of using the host system's store) and therefore you'd have the same problems. I'm not even sure how practical it would be to install the cert to the emulator; I've never tried. If you have the source, you could temporarily disable cert checking in the app I guess... but then, that's one of the most common findings I have with mobile apps, so don't do that unless you've tested the default SSL configuration very closely.

Also, I'm not actually sure how to set the proxy in the emulator. I've never tried before. Probably just easier all around to use a real phone.
 
  • Like
Reactions: shadowD1026

shadowD1026

Member
Feb 3, 2014
30
0
Seattle
Burp isn't showing traffic

The emulator is a full virtual machine, so it almost certainly has its own cert store (instead of using the host system's store) and therefore you'd have the same problems. I'm not even sure how practical it would be to install the cert to the emulator; I've never tried. If you have the source, you could temporarily disable cert checking in the app I guess... but then, that's one of the most common findings I have with mobile apps, so don't do that unless you've tested the default SSL configuration very closely.

Also, I'm not actually sure how to set the proxy in the emulator. I've never tried before. Probably just easier all around to use a real phone.

Ok...stupid question regarding:

5) In Fiddler's options, configure it to use Burp as the upstream proxy.

I went into Fiddler and selected WinINET options to set Burp as the upstream proxy. So, in Burp, I have it listening on port 8080, All Interfaces, and Generate CA-Signed per host cert. Now in the WinINET (IE Settings), I have port 8080 but I'm not sure what to to put in for the Address field. Do I put my machine name or a specific ip? Burp is listening on all interfaces, so I obv don't want to put in localhost or 127.0.0.1. I also have the WP8 wifi settings to point to my machine name and fiddlers port 8888. I can see the traffic in Fiddler but not burp.

Please help. Thank you
 

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
First of all, I said in Fiddler's settings, not in WinINET ("Internet Options"). Tools -> Fiddler Options... -> Gateway -> Manual proxy configuration -> localhost:<PORT>.

With that said, you can just use the system proxy settings too (that's the default behavior in Fiddler); I don't recommend it though because then everything on your box will route through Burp which has unfortunate impacts on network performance and RAM usage.
Internet Properties -> Connections -> LAN settings -> "Use a proxy server for your LAN" -> Address: localhost, Port: <PORT>

In both cases, "<PORT>" means whatever port Burp is listening on (8080). I have no idea what you mean by "Burp is listening on all interfaces, so I obv don't want to put in localhost or 127.0.0.1" given that
A) that is exactly what you want to do
B) there is nothing I can think of that would even remotely lead to believe otherwise.
Granted, loopback is not an explicit network interface on Windows the way it is on Linux, but it is still treated as one in the kernel. Listening on "all interfaces" just means the socket was bound to 0.0.0.0 (or IPAddress.Any in .NET; there's an equivalent option in Java). Listening on 0.0.0.0 will get messages routed both through external interfaces and through localhost (127.0.0.1), or localhost wouldn't be nearly as much use...
 
  • Like
Reactions: shadowD1026

shadowD1026

Member
Feb 3, 2014
30
0
Seattle
First of all, I said in Fiddler's settings, not in WinINET ("Internet Options"). Tools -> Fiddler Options... -> Gateway -> Manual proxy configuration -> localhost:<PORT>.

With that said, you can just use the system proxy settings too (that's the default behavior in Fiddler); I don't recommend it though because then everything on your box will route through Burp which has unfortunate impacts on network performance and RAM usage.
Internet Properties -> Connections -> LAN settings -> "Use a proxy server for your LAN" -> Address: localhost, Port: <PORT>

In both cases, "<PORT>" means whatever port Burp is listening on (8080). I have no idea what you mean by "Burp is listening on all interfaces, so I obv don't want to put in localhost or 127.0.0.1" given that
A) that is exactly what you want to do
B) there is nothing I can think of that would even remotely lead to believe otherwise.
Granted, loopback is not an explicit network interface on Windows the way it is on Linux, but it is still treated as one in the kernel. Listening on "all interfaces" just means the socket was bound to 0.0.0.0 (or IPAddress.Any in .NET; there's an equivalent option in Java). Listening on 0.0.0.0 will get messages routed both through external interfaces and through localhost (127.0.0.1), or localhost wouldn't be nearly as much use...

Fiddler gateway manual setting worked. Appreciate your time and help. Sorry if my last post was confusing or stated wrong.
 

5h1vang

New member
Jan 6, 2014
2
0
Hello - Does anyone have a step by step on how to intercept SSL App Store traffic using BURP and a Windows 8 phone? I know that installed the BURP cert onto the phone is required. So steps on how to do this on the Windows 8 Phone would be great appreciated.


I know your question is related to "Burp" but then too felt like sharing a simple and elegant way to intercept SSL traffic for windows phone 8.
This blog contains step-by-step tutorial to set up traffic interception (both HTTP and HTTPs).
rikk(dot)it/blog/capture-windows-phone-8-network-traffic-with-fiddler/
:good:
 

Saharkhiz.Ahmad

New member
Aug 9, 2015
1
0
Best way to do it...

Hello - Does anyone have a step by step on how to intercept SSL App Store traffic using BURP and a Windows 8 phone? I know that installed the BURP cert onto the phone is required. So steps on how to do this on the Windows 8 Phone would be great appreciated.

You can do it very easy. Default cert file' type of burp is "cacert.der", which is not recognized by windows phone. therefore, you can open 127.0.0.1 8080 which is the burp listener on your PC, then you will see the burp page, click on the "CA Certificate". then you will see the cacert.der is downloading. TIP: You must rename it. YES, you must rename it to "cacert.cer". then push it to your windows phone (e.g. by sending email to your inbox in you WP).
It is the time to open that file in your windows phone, then press install button. Finish.
"I decided to write things that I learned by experience. We always use the other's experiences by searching the web, but how much we pay time to write our experiences?"
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    *SIGH* stop assuming things, people. Burp Suite is a *very* standard pen-testing tool. "The App does not use cert pinning" was a dead giveaway that the OP was talking about pen-testing a mobile app.

    In theory, the process is really simple. Export the Burp public CA (Proxy -> Options -> Proxy Listeners -> CA certificate; make sure to rename it as a .CER file) and send it to the phone (Bluetooth, email, etc.; you should get a prompt to import the cert). Unfortunately, Burp is kind of lazy about how it generates its root certificates, so by default, the phone doesn't treat them as CA root certs. You can generate a custom cert manually and install it on the phone + have burp use it, but that's only going to work for one domain at a time and is a total pain. The other approach that I've found to work (which is silly, but hey, it *does* work) is to do the following:

    1) Install Fiddler along with Burp (if you're not on Windows, you can probably use Fiddler via Mono).
    2) Run Fiddler, enable SSL interception, disable automatic platform proxy configuration, set the proxy to listen on external connections, and install its root CA cert to the phone (similar to the way you do it from Burp).
    3) Set the phone's WiFi proxy options to connect to the Fiddler IP and port.
    OK... so far, you're now in a position to intercept traffic. If all you need is basic proxying, this is actually sufficient all by itself, and Fiddler does have a few cool features of its own. However, if you need real pentesting tools, like Burp Suite provides, there's a way to get that anyhow:
    4) Run Burp, and set it to listen on a different port than Fiddler is using.
    5) In Fiddler's options, configure it to use Burp as the upstream proxy.
    6) Disable interception in Fiddler (so you don't have to manually forward traffic all the time) and proceed to use Burp as normal.

    Yes, this is silly. It's the easiest solution I've found thus far, though, and I've used it myself.
    Heh... I probably just gave technical advice to a competitor. Ah well. Good luck breaking stuff!
    1
    The emulator is a full virtual machine, so it almost certainly has its own cert store (instead of using the host system's store) and therefore you'd have the same problems. I'm not even sure how practical it would be to install the cert to the emulator; I've never tried. If you have the source, you could temporarily disable cert checking in the app I guess... but then, that's one of the most common findings I have with mobile apps, so don't do that unless you've tested the default SSL configuration very closely.

    Also, I'm not actually sure how to set the proxy in the emulator. I've never tried before. Probably just easier all around to use a real phone.
    1
    First of all, I said in Fiddler's settings, not in WinINET ("Internet Options"). Tools -> Fiddler Options... -> Gateway -> Manual proxy configuration -> localhost:<PORT>.

    With that said, you can just use the system proxy settings too (that's the default behavior in Fiddler); I don't recommend it though because then everything on your box will route through Burp which has unfortunate impacts on network performance and RAM usage.
    Internet Properties -> Connections -> LAN settings -> "Use a proxy server for your LAN" -> Address: localhost, Port: <PORT>

    In both cases, "<PORT>" means whatever port Burp is listening on (8080). I have no idea what you mean by "Burp is listening on all interfaces, so I obv don't want to put in localhost or 127.0.0.1" given that
    A) that is exactly what you want to do
    B) there is nothing I can think of that would even remotely lead to believe otherwise.
    Granted, loopback is not an explicit network interface on Windows the way it is on Linux, but it is still treated as one in the kernel. Listening on "all interfaces" just means the socket was bound to 0.0.0.0 (or IPAddress.Any in .NET; there's an equivalent option in Java). Listening on 0.0.0.0 will get messages routed both through external interfaces and through localhost (127.0.0.1), or localhost wouldn't be nearly as much use...