0

I'm trying to intercept traffic between an Andriod App and a Router interface. I'm using a rooted device.

They communicate on port 6699 which I believe is typical for nginx.

I've tried setting up Burp to capture the traffic but all it sees is the data the App sends/receives remotely (API calls to the cloud) and nothing it sends/receives locally (API calls to nginx on the router).

It seems like the Burp listener port is only capturing traffic from ports 80 and 443 on the Android device.

How can I set up burp to capture traffic from port 6699?

Improve this question
3
  • How did you set up Burp Suite?
    – multithr3at3d
    Jul 17, 2021 at 20:19
  • I've set up the listening port to be 8081. I've installed the burps certificate in the system and client sides on the android device. I'm using the 'ProxyDroid' app to proxy the traffic to the host IP running burps, and I've isolated traffic to the app of interest. I've also tried with the standard proxy settings in the WIFI settings which has the same results (albeit with all device traffic rather than just from the app I want). I've used an app called 'Packet Capture' to see the local traffic that happens between it and the router, I just can't do anything with it in a passive state.
    – Doby
    Jul 17, 2021 at 22:42
  • 1
    Then it sounds like ProxyDroid may not be proxying any ports behind the standard ones.
    – multithr3at3d
    Jul 18, 2021 at 1:09

2 Answers 2

Reset to default
1

First of all, make sure the proxy configuration (on the device) doesn't have exceptions for LAN addresses (192.168.*.*, 10.*.*.*, etc.). Lots of times, LAN addresses are by default excluded from proxying, because it's assumed you only need (or want) to proxy Internet traffic.

There are a few ways, but one I've used before (which doesn't even require rooting the device) is to use your PC as a WiFi access point, and set up forwarding rules on the network interface (look up "iptables forward", or it's probably possible somehow on other platforms) so that any traffic originating from the device is routed to the proxy (which you run in invisible mode, listening on the port(s) that the app tries to connect to or at least that you forward those ports to).

In this case, since you need to let the device communicate with the router (and therefore it probably doesn't work to make yourself an intermediate router, which the above approach usually does), you could instead ARP spoof the device to think your PC's MAC address is the MAC address of the router. Packets addressed from the device to the router will instead be routed to you. You can then set up Burp (in invisible mode) listening on the ports that the app connects to, and relaying the traffic to (and from) the router after interception.

A third option, which probably doesn't work here in particular but does for some other cases where not all traffic is getting proxied, is to use DNS spoofing. Obviously this only works if the device is trying to connect to a host by name, rather than by IP, but it's generally very reliable because you can set a system-wide DNS server when you connect the device to the network, and make that DNS server be your PC. Then on the PC, run a DNS service that allows custom responses (and presumably forwards everything else to the PC's normal DNS resolver, probably an upstream server), and point the names you want to proxy at your PC's address (with Burp running, in invisible mode, listening on the relevant ports). You could also do this by poisoning the DNS cache of an upstream server (such as a router), but why bother when you can directly control the DNS responses the device sees instead? Obviously that's not reliable if the software has its own DNS resolver that doesn't use the system DNS configuration, but that's much rarer than software that doesn't use the system proxy configuration.

Improve this answer
7
  • Thanks all for your comments! I'll be trying some of these suggestions. I've also since found an incredibly helpful blog post on android proxying. Anyone who finds themselves here in the future should check it out. blog.nviso.eu/2020/11/19/…
    – Doby
    Jul 18, 2021 at 10:23
  • So, after the enthusiasm, I've hit a wall. I've tried ARP spoofing using arpspoof.exe (simple windows executable that uses NPcap) which works, and in Wireshark I can see all the traffic from the android device but I cannot get Burp to pick up any of it in invisible mode on port 6699 (or any other port). I've also tried proxying with adb reverse and specifying port 6699 is routed through the listener port on ip tables which also garnered no results. The app of interest lost communication, so it did do something to the port, but I didn't see any evidence of it in Burp.
    – Doby
    Jul 18, 2021 at 22:11
  • Hmm. First of all, make sure your firewall is allowing inbound traffic on that port (6699) and that Burp is bound to all interfaces (or at least to the external one), not only to loopback. Burp will indeed have to be listening on port 6699, in invisible mode. Check Burp's logs to see if it's getting any errors, such as a handshake error due to the client expecting a particular cert (it's possible!) or a protocol or cipher suite that Burp doesn't have enabled.
    – CBHacking
    Jul 18, 2021 at 23:02
  • Burp is showing no errors. I turned off windows firewall just to rule it out but no luck. I don't fully understand how the traffic is supposed to get to Burp. When I was proxying from the device directly to the listener port it made total sense that I would see that traffic in Burp. Now I'm just running Burp on the same machine doing the arp spoof and it's supposed to see that traffic. How? Doesn't the traffic need to be 'sent' to Burp so it can be intercepted? There's very little evidence on the internet of people using Burp with arp spoofing which doesn't fill me with much confidence.
    – Doby
    Jul 19, 2021 at 12:06
  • I'm not saying it can't be done, as I'm sure it can. But i'm nowhere near skilled enough in this area to figure it out without prompts. I've read about forcing Burp to connect to non-proxy-aware clients with an invisible proxy by modifying the DNS for a hostname, but my target doesn't have a hostname as it's the gateway itself.
    – Doby
    Jul 19, 2021 at 12:21
0

Burp intercept the HTTP(S) traffic even if the HTTP(S) server port is different from 80 or 443.

I suggest to use the standard Android proxy settings:

Network & Internet -> Wifi -> Modify Network -> Advanced -> Proxy = "Manual", then secect the necessary options for the host that will intercept the traffic.

You can also try with the global settings using ADB shell:

adb shell settings put global http_proxy IP:PORT
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .