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?
2

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.

| improve this answer | |
  • 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 at 17:46
  • Edited my answer to clarify. – ximaera Apr 12 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 at 18:09
  • 1
    Because mitm_proxy is not a sniffer. It doesn't capture packets as they go. It only streams data extracted from packets. See: github.com/jrmdev/mitm_relay/blob/master/mitm_relay.py#L285 – ximaera Apr 14 at 4: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 at 4:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.