Intercepting Android app traffic with Burp

Question

I am trying to understand what do Burp and Android apps do when the traffic is https. I did not install the Burp CA to the phone.

1. Some apps completely refuse to work. They display an error message or think the phone is not online. Is this because of SSL Pinning?

2. Some apps work normally but Burp does not capture any packets. How is this happening? Without burps CA how can the phone and server communicate? Is Burp just relaying the traffic?

3. Some apps work normal but Burp only intercepts packets for a few operations. Intercepted operations are probably using empty trust managers or something like that but still how is the rest of the code communicating with the server?

Answer 1

First thing to remember is that Burp is a HTTP(S) proxy. It doesn't do anything about any data which isn't HTTP(S) (OK, except websockets). Android apps, on the other hand, can use any protocol they want. Lots do use HTTP(S), just because it suits the type of data they're sending, but it's not actually required.

Where an app isn't using HTTP(S), that traffic won't appear in Burp. The most obvious example of this is DNS traffic - you won't see any DNS lookup requests showing up even if you're using a browser via Burp.

So:

1. Apps which completely refuse to work. They could be using certificate pinning - two options here, though. First type, they're looking for a valid certificate for the target site to be installed on the device. In this case, installing the Burp CA cert would make them work again. Second type, they're using some custom pinning, which requires either a specific certificate to be provided by the server, or a certificate signed by a specific entry in the trust chain. These ones won't be fooled by the Burp CA cert.
2. Apps which work without any packets being captured. They're probably not using HTTP(S). This could be things like SSH clients, messaging services like Whatsapp, or games, where the loss of a packet is less important than most packets arriving fast, which would better suit a UDP based network connection than a TCP based one like HTTP. They might also be ignoring any proxy settings which are in place, especially if you're just intercepting using a HTTP proxy app. To view this data, you'll need a tool like Wireshark, which can handle other types of data, and a wifi card which supports monitor mode.
3. Apps which only show some traffic. If the traffic you're seeing is stats packages or adverts, they probably fall into class 2 above - most stats systems appear to use HTTP(S) because it's relatively easy to implement in anything, and you generally have to have some kind of HTTP connection open to download adverts anyway.
4. Apps which don't actually connect out. There are some applications which look like they should be connecting to the internet, but actually don't, or only do so on an irregular basis. These can include timetable apps, some games (where the high scores are updated daily, for example) or anything where it's possible to store data locally for the most part (mapping apps may store the "usual" area locally, and make calls out for reviews of attractions or more distant places). In this case, you might not have seen them try to connect whilst you were watching.

I'd suggest looking at the traffic with Wireshark, if you can, and see what protocols are being used, then dig into interesting ones using appropriate software, bearing in mind that some are intentionally difficult to inspect - encrypted packets from Whatsapp should be unreadable, else they've got something badly wrong!

Answer 2

I have encountered a similar issue when pentesting an iPhone application. The application did not use the native libraries, and did not support http proxy. To "fix" this, I forwarded all traffic transparently to the Burp proxy. See How do you capture ALL the traffic from an Android app? for description of this setup.

Some applications use certificate pinning. Some applications will pin the first certificate it sees, other application have it hardcoded in the application. In the first case, you just have to make sure that the traffic will go through your proxy when you first run it.

I believe you will see a warning in Burps alert-tab if the client disconnects prematurely (rejects the certificate).

In the latter, it is a bit harder as you will have to modify the binary itself.

I have not tried to subvert certificate pinning from an android application myself, but this links looks like a good approach.