2

I'm trying to capture TCP requests through Burp Suite with this hacky method.

Basically it listens for user selected protocol requests (TCP/UDP) and then forwards them to Burp Suite (or any other tool, if you want to) just like they're HTTP requests. All this by setting a proxy, and Burp Suite will listen to that proxy IP/Port.

However, what I need to do is listening to a website which sends TCP packets, so I should see HTTP/HTTPS requests too. This is what I tried:

sudo python mitm_relay.py -l 0.0.0.0 -p 127.0.0.1:8081 -r tcp:80:example.com:80

where 0.0.0.0 listens to any local interface, proxy listener has been set to 127.0.0.1:8081 and example.com hostname will be converted to his IP address I will send TCP packets to (port set to 80). However, I've set my default Firefox proxy to 127.0.0.1:8081 and when I navigate to example.com I can't see any packet being sniffed under my terminal.

Also this is not an HTTP request, so I've generated my server.pem and server.key just exactly it's been described here:

~/mitm_relay/ $ ls | grep -iE 'ca|ser'
cacert.cer
cacert.pem
cacert.srl
cakey.cer
cakey.pem
server.csr
server.key
server.pem

(those are all generated files through those commands).

  1. How can I intercept TCP requests to example.com on port 80?
  2. How can I intercept any domain TCP request on port 80?
  3. What's an example command of intercepting SSL data (like HTTPS) through that script with those generated certificate files?
  4. Is setting Burp to listen to 127.0.0.1:8081 proxy enough for applying the 3 precedent questions?
Leon
  • 43
  • 1
  • 7

1 Answers1

3

I've set my default Firefox proxy to 127.0.0.1:8081

You shouldn't do that, the -p argument is there to specify where the Burp proxy is running.

when I navigate to example.com

It doesn't matter where in particular you navigate (though google.com probably wouldn't work because of strict transport security). All requests targeting the port 80/tcp would be intercepted with the script and routed to example.com through Burp proxy.

Note that you may be running something on your port 80 already. I suggest changing the port number, e.g. to tcp:81:example.com:80, and try navigating to 127.0.0.1:81 to see if it works this way. If the port 81 works and port 80 doesn't, try using ss or netstat to figure out which program is taking over the port 80.

Also this is not an HTTPS request, so I've generated my server.pem and server.key

You don't need them for HTTP requests.

How can I intercept any domain TCP request on port 80?

I don't think this tool is generally well suitable for this task.

You can do it only by setting up a real proxy (like Squid) somewhere on your machine. The -l argument controls what resource do you intercept. The -r argument only controls:

  • The port
  • Where do you forward traffic.

In order for your requests to be handled by the target domain you need a proxy under the -r argument.

What's an example command of intercepting SSL data (like HTTPS) through that script with those generated certificate files?

sudo python mitm_relay.py -l 0.0.0.0 -p 127.0.0.1:8081 -r tcp:443:example.com:443 -c server.pem -k server.key

Note that your browser would display a warning that the connection is untrusted, and google.com inevitably wouldn't work in Chrome. Firefox would be okay as of 12 April, 2020 — though this particular part of the answer probably won't age well.

ximaera
  • 3,395
  • 8
  • 23
  • Okay, now I can see. Is it really necessary to visit `127.0.0.1:81` in order to get it intercept those requests? I'm asking that because I don't really need it to intercept HTTP requests to `127.0.0.1:81` under terminal. Regarding those SSL certificates, sorry it was a typo. I had to write it was **not** an HTTP request. Also, how would it work through Google domain? – Leon Apr 12 '20 at 17:46
  • Edited my answer to clarify. – ximaera Apr 12 '20 at 17:58
  • thank you, I've understood everything. However, I'm intercepting through WireShark the packets I need to modify through Burp if they get repeated under my browser session, and I've seen that source IP address is set to website IP address and destination is set to my private IP address (192.168.1.2, in my case). When I run that exact command, I think I'm seeing packets I'm **sending** to source IP address. Am I right? What if I want to check what that IP address is sending to me since we already have talked about the viceversa? – Leon Apr 12 '20 at 18:09
  • In wireshark, you must be seeing both traffic directions. Depends on the filter you apply though. – ximaera Apr 12 '20 at 19:43
  • Yes, I definitively will mark your answer as accepted when I'll check it works with Burp. I don't understand why WireShark intercepts me all these packets while still (with TLS enabled command too) `mitm_relay.py` doesn't, it does capture just like 2 packets every 10 seconds). Do you suggest me [something](https://i.imgur.com/UfzNlAV.png)? – Leon Apr 12 '20 at 19:54
  • Yes, like I said you have an `ip.dst==` filter set up. If you remove it you will see both the streams. Also, you use the port **30000** in the filter while your `mitm_proxy.py` command line works against port **80**. – ximaera Apr 13 '20 at 01:02
  • Actually I've set only 81 as local listening port (-r 81:ip:30000). Also if I remove that filter under Wireshark (in order to see source 192.168.1.2 sending to the other IP in the screenshot and viceversa) there are many requests mitm_relay doesn't capture under terminal. I need to get it to listen **all** those TCP requests and to get it capture everything from both sources or something similar. – Leon Apr 13 '20 at 03:44
  • Try changing `ip.dst` to `ip.addr` in your filter. – ximaera Apr 13 '20 at 09:34
  • Sure. [Here](https://i.imgur.com/ciu471j.png) you can see `mitm_relay` doesn't capture all TCP packets WireShark intercepts, even with your filter. I have doubt if I configured everything correctly. I tried with another IP address which has a very similar website. WireShark is continuing to get many packets, while I get two or less packets with the script (its first sniffed request is there because I've browsed just like you said to `127.0.0.1:20802`). – Leon Apr 13 '20 at 15:46
  • Err. Either there's not enough info from your side to figure out, or it's catching everything. See, there's a difference between a packet and an HTTP request. One needs to send 3 TCP *segments* (wrapped into 3 packets) — and to receive one — to produce an HTTP request. See https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment – ximaera Apr 13 '20 at 21:16
  • Also if that was the problem, why doesn't it capture others TCP packets like in the screen? – Leon Apr 13 '20 at 21:43
  • 1
    Because `mitm_proxy` *is not a sniffer*. It doesn't capture packets as they go. It only streams data extracted from packets. See: https://github.com/jrmdev/mitm_relay/blob/master/mitm_relay.py#L285 – ximaera Apr 14 '20 at 04:07
  • 1
    Thanks for clearing my head, I'm accepting your answer. I will make another question in further cases I won't be able to implement it the way that script made for. – Leon Apr 14 '20 at 04:26