cyberark/mitm_interceptA little bit less hackish way to intercept and modify non-HTTP protocols through Burp & others.
A little bit less hackish way to intercept and modify non-HTTP protocols through Burp and others with SSL and TLS interception support. This tool is for researchers and applicative penetration testers that perform thick clients security assesments.
An improved version of the fantastic mitm_relay project.
As part of our work in the research department of CyberArk Labs, we needed a way to inspect SSL and TLS communication over TCP and have the option to modify the content of packets on the fly. There are many ways to do so (for example, the known Burp Suite extension NoPE), but none of them worked for us in some cases. In the end we stumbled upon mitm_relay.
mitm_relay is a quick and easy way to perform MITM of any TCP-based protocol through existing HTTP interception software like Burp Suite’s proxy. It is particularly useful for thick clients security assessments. But it didn’t completely work for us, so we needed to customize it. After a lot of customizations, every new change required a lot of work, and we ended up rewriting everything in a more modular way.
We hope that others will find this script helpful, and we hope that adding functionality will be easy.
For a start, listeners’ addresses and ports need to be configured. For each listener, there also needs to be a target configured (address and port). Every data received from the listener will be wrapped into a body of an HTTP POST request with the URL containing “CLIENT_REQUEST”. Every data received from the target will be wrapped into a body of an HTTP POST request with the URL containing “SERVER_RESPONSE”. Those requests are sent to a local HTTP interception server.
There is the option to configure an HTTP proxy and use a tool like burp suite as an HTTP interception tool and view the messages there. This way, it is easy to modify the messages by using Burp’s “Match and Replace”, extensions or even manually (Remember, the timeout mechanism of the intercepted protocol can be very short).
Another way to modify the messages is by using a python script that the HTTP interception server will run when it receives messages.
The body of the messages sent to the HTTP interception server will be printed to the shell. The messages will be printed after the changes if the modification script is given. After all the modifications, the interception server will also echo back as an HTTP response body.
To decrypt the SSL/TLS communication, mitm_intercept need to be provided a certificate and a key that the client will accept when starting a handshake with the listener. If the target server requires a specific certificate for a handshake, there is an option to give a certificate and a key.
A small chart to show the typical traffic flow:
mitm_intercept is compatible with newer versions of python 3 (python 3.9) and is also compatible with windows (socket.MSG_DONTWAIT does not exist in windows, for example). We kept the option of using “STARTTLS,” and we called it “Mixed” mode. Using the SSL key log file is updated (the built-in option to use it is new from python 3.8), and we added the option to change the sni header. Now, managing incoming and outgoing communication is done by socketserver, and all the data is sent to a subclass of ThreadingHTTPServer that handle the data representation and modification. This way, it is possible to see the changes applied by the modification script in the response (convenient for using Burp). Also, we can now change the available ciphers that the script uses using the OpenSSL cipher list format
$ python -m pip install requestsusage: mitm_intercept.py [-h] [-m] -l [u|t:]<interface>:<port> [[u|t:]<interface>:<port> ...] -t
[u|t:]<addr>:<port> [[u|t:]<addr>:<port> ...] [-lc <cert_path>]
[-lk <key_path>] [-tc <cert_path>] [-tk <key_path>] [-w <interface>:<port>]
[-p <addr>:<port>] [-s <script_path>] [--sni <server_name>]
[-tv <defualt|tls12|tls11|ssl3|tls1|ssl2>] [-ci <ciphers>]
mitm_intercept version 1.6