Kali is chock-full of useful penetration testing tools, though some of them are less practical from a penetration testing perspective, and instead designed for black hat hackers. Nevertheless, the tools are neither inherently good or evil. Their limits are only bound by your creativity, though today we’re going to be looking at a tool that is less practical in a corporate or professional penetration testing environment.
Today we’re going to be looking at mitmproxy, a tool that helps hack traffic from proxy servers. I think it’s pretty rare these days for any legitimate firm to implement their own proxy servers, though I’m sure it does happen on occasion for various reasons. By and large, it’s much more common for a company to implement their own VPN servers as opposed to proxy servers (for reasons we’ll shortly discuss).
But penetration testing isn’t limited to corporate environments alone. Plenty of folks setup their own proxy servers. Some simply want to provide a free resource to help strangers access blocked, censored, and geo-restricted content. Others setup their own personal proxy servers for private use. Whatever the reason for creating a proxy server in the first place, you need to understand the inherent security risks. mitmproxy will help show you how insecure they really are (and why you should always use a VPN tunnel when possible).
Proxy Servers vs VPN Servers
Most of you probably already know what a VPN server is, but many of you may not understand the differences between a VPN and a proxy server. From the average user’s perspective, they’re more or less the same – especially if the user is just trying to get around network or country-wide restrictions to unblock content.
In consumer VPN markets, most users don’t care – they just want access to streaming media. For instance, a user traveling abroad may simply be trying to unlock access to Netflix or Hulu. Or perhaps they are trying to circumvent sports network blackouts to stream a game live on the Internet. At any rate, both VPN servers and proxy servers can help unblock content through the process of IP address masking.
Both the VPN server and proxy server act like a “middle-man.” They do this by making request on behalf of the connected client, and then send the data back to the original host – and the server providing the content is none the wiser. From the web server’s perspective, the original host that made the request is completely invisible.
But there’s one massive difference between proxy servers and VPN servers that makes a proxy service undesirable – encryption! While VPN servers lock down a connection with ultra-strong encryption mechanisms, most proxy servers don’t provide any encryption at all.
Inherent Security Flaws with Proxy Server
If the failure to provide encryption sounded like a big problem, and it is, just wait – things get even worse. Yet another problem with proxy servers is that you don’t always know who is running and operating them. Sometimes you do know because they are hosted by a legitimate business, such as those who offer SmartDNS and other proxy services in addition to their VPN service (like HMA VPN).
You can mostly trust theses types of proxy servers since they are hosted by a credible and reputable firm. But for every reputable proxy server on the Internet, there are thousands more that are pretty darn shady. Just go ahead and Google “free proxy server,” and your going to be inundated with IP addresses of proxy servers from around the world.
And while Google does its best to weed out crummy results, the bottom line is that you don’t always know who is running the show behind the scenes. For all you know, the server you connect to is hosted in some Schmoe’s basement. It’s a careless thing to send all of your Internet traffic through a stranger’s server, because they could easily use tools like a sniffer to capture your traffic. What’s worse is that the server could be insecure, too.
Even if the proxy server provider doesn’t want to take advantage of users’ traffic, hackers may target the server anyway. But the flaws and security issues with proxy servers can be used as an advantage for a hacker. When you run an MITM attack, your computer, server, or network interface essentially becomes a proxy. With exception to some security protocols and encryption, your computer will be able to see all the information flowing through it when it is assuming the role of a proxy server.
How MITM Attacks Work
We’ve talked about MITM attacks quite extensively in other posts, but for those of you who don’t know how they work, we’ll briefly discuss MITM attacks. MITM stands for Man in the Middle. Essentially, the idea is for an attacker to place their computer (or server, interface, etc.) inside the forwarding path of a user’s data.
For instance, if an attacker wanted to monitor data sent to a forum, the attacker would first need to be between the forum’s servers and the end user workstation. On a LAN, as well as a few other environments, it’s possible to place yourself between the target computer and all other devices and servers they are connecting to.
At this point, the attacker’s computer behaves in much the same way as a proxy server, only it doesn’t mask the user’s IP address. Instead, it receives data from the target machine, inspects/captures/copies the data, and then forwards it on to the intended in host. In the reverse direction (that is, for data originating at a server and being forwarded to the end user), the same process applies.
Any data that isn’t sent in an encrypted format is visible to the attacker, including usernames, passwords, online activity data, images – whatever the user is sending. Furthermore, the attacker can even capture data related to the establishment of a tunnel or security algorithm, like SSL.
mitmproxy Syntax
The syntax for this tool is, in a word, intimidating. But note that most of the options don’t need to be used to perform basic functions. The following lists the syntax and optional arguments for mitmproxy:
usage: mitmproxy [options]
optional arguments:
-h, –help show this help message and exit
–version show program’s version number and exit
-b ADDR Address to bind proxy to (defaults to all interfaces)
–anticache Strip out request headers that might cause the server
to return 304-not-modified.
–confdir CONFDIR Configuration directory. (~/.mitmproxy)
-e Show event log.
-n Don’t start a proxy server.
-p PORT Proxy service port.
-P REVERSE_PROXY Reverse proxy to upstream server:
http[s]://host[:port]
-F FORWARD_PROXY Proxy to unconditionally forward to:
http[s]://host[:port]
-q Quiet.
-r RFILE Read flows from file.
-s “script.py –bar” Run a script. Surround with quotes to pass script
arguments. Can be passed multiple times.
-t FILTER Set sticky cookie filter. Matched against requests.
-T Set transparent proxy mode.
-u FILTER Set sticky auth filter. Matched against requests.
-v Increase verbosity. Can be passed multiple times.
-w WFILE Write flows to file.
-z Try to convince servers to send us un-compressed data.
-Z SIZE Byte size limit of HTTP request and response bodies.
Understands k/m/g suffixes, i.e. 3m for 3 megabytes.
–host Use the Host header to construct URLs for display.
–no-upstream-cert Don’t connect to upstream server to look up
certificate details.
–debug
–palette PALETTE Select color palette: dark, light, solarized_dark,
solarized_light
Web App:
-a Disable the mitmproxy web app.
–app-host host Domain to serve the app from. For transparent mode,
use an IP when a DNS entry for the app domain is not
present. Default: mitm.it
–app-port 80 Port to serve the app from.
–app-external Serve the app outside of the proxy.
Client Replay:
-c PATH Replay client requests from a saved file.
Server Replay:
-S PATH Replay server responses from a saved file.
-k Kill extra requests during replay.
–rheader RHEADERS Request headers to be considered during replay. Can be
passed multiple times.
–norefresh Disable response refresh, which updates times in
cookies and headers for replayed responses.
–no-pop Disable response pop from response flow. This makes it
possible to replay same response multiple times.
Replacements:
Replacements are of the form “/pattern/regex/replacement”, where the
separator can be any character. Please see the documentation for more
information.
–replace PATTERN Replacement pattern.
–replace-from-file PATH
Replacement pattern, where the replacement clause is a
path to a file.
Set Headers:
Header specifications are of the form “/pattern/header/value”, where the
separator can be any character. Please see the documentation for more
information.
–setheader PATTERN Header set pattern.
Proxy Authentication:
Specify which users are allowed to access the proxy and the method used
for authenticating them. These options are ignored if the proxy is in
transparent or reverse proxy mode.
–nonanonymous Allow access to any user long as a credentials are
specified.
–singleuser USER Allows access to a a single user, specified in the
form username:password.
–htpasswd PATH Allow access to users specified in an Apache htpasswd
file.
SSL:
–cert CERT User-created SSL certificate file.
–client-certs CLIENTCERTS
Client certificate directory.
Filters:
See help in mitmproxy for filter expression syntax.
-i INTERCEPT, –intercept INTERCEPT
Intercept filter expression.
The Dump Command
Also note that there is an mitmdump command. It is equally contrived and complex, though the following will serve as a reference for the command’s syntax:
usage: mitmdump [options] [filter]
positional arguments:
args
optional arguments:
-h, –help show this help message and exit
–version show program’s version number and exit
-b ADDR Address to bind proxy to (defaults to all interfaces)
–anticache Strip out request headers that might cause the server
to return 304-not-modified.
–confdir CONFDIR Configuration directory. (~/.mitmproxy)
-e Show event log.
-n Don’t start a proxy server.
-p PORT Proxy service port.
-P REVERSE_PROXY Reverse proxy to upstream server:
http[s]://host[:port]
-F FORWARD_PROXY Proxy to unconditionally forward to:
http[s]://host[:port]
-q Quiet.
-r RFILE Read flows from file.
-s “script.py –bar” Run a script. Surround with quotes to pass script
arguments. Can be passed multiple times.
-t FILTER Set sticky cookie filter. Matched against requests.
-T Set transparent proxy mode.
-u FILTER Set sticky auth filter. Matched against requests.
-v Increase verbosity. Can be passed multiple times.
-w WFILE Write flows to file.
-z Try to convince servers to send us un-compressed data.
-Z SIZE Byte size limit of HTTP request and response bodies.
Understands k/m/g suffixes, i.e. 3m for 3 megabytes.
–host Use the Host header to construct URLs for display.
–no-upstream-cert Don’t connect to upstream server to look up
certificate details.
–keepserving Continue serving after client playback or file read.
We exit by default.
Web App:
-a Disable the mitmproxy web app.
–app-host host Domain to serve the app from. For transparent mode,
use an IP when a DNS entry for the app domain is not
present. Default: mitm.it
–app-port 80 Port to serve the app from.
–app-external Serve the app outside of the proxy.
Client Replay:
-c PATH Replay client requests from a saved file.
Server Replay:
-S PATH Replay server responses from a saved file.
-k Kill extra requests during replay.
–rheader RHEADERS Request headers to be considered during replay. Can be
passed multiple times.
–norefresh Disable response refresh, which updates times in
cookies and headers for replayed responses.
–no-pop Disable response pop from response flow. This makes it
possible to replay same response multiple times.
Replacements:
Replacements are of the form “/pattern/regex/replacement”, where the
separator can be any character. Please see the documentation for more
information.
–replace PATTERN Replacement pattern.
–replace-from-file PATH
Replacement pattern, where the replacement clause is a
path to a file.
Set Headers:
Header specifications are of the form “/pattern/header/value”, where the
separator can be any character. Please see the documentation for more
information.
–setheader PATTERN Header set pattern.
Proxy Authentication:
Specify which users are allowed to access the proxy and the method used
for authenticating them. These options are ignored if the proxy is in
transparent or reverse proxy mode.
–nonanonymous Allow access to any user long as a credentials are
specified.
–singleuser USER Allows access to a a single user, specified in the
form username:password.
–htpasswd PATH Allow access to users specified in an Apache htpasswd
file.
SSL:
–cert CERT User-created SSL certificate file.
–client-certs CLIENTCERTS
Client certificate directory.
mitmproxy Usage Example
If you think all of those options look intimidating, you’re not wrong. This tool is rather complex, but let’s go ahead and perform a simple demonstration that shows you how to start a basic capture. The scope of all the options in this command are incredibly complex, and require knowledge of a lot of concepts, protocols, and technologies outside the scope of this documentation.
However, in this small example, we’re going to tell mitmproxy to listen on port 8080 for traffic, and to then write that traffic into a file. Once you have a copy of the data, it can be analyzed and used with other tools as well. So, here’s the basic command syntax:
- mitmproxy -w mycapturefile.log -p 8080
Remember to be logged in as the root user when running this command. All of the captured data from mitmproxy will be saved to the new file named “mycapturefile.log.” And of course, it will listen on port 8080 due to the -p option.
Final Thoughts
This tool is extremely complex, but I wanted to show it to you because it’s such a powerful mechanism. Like Metasploit, I doubt you could learn it in a week or a month, much less a single day, unless you already had a background in IT and an advanced working knowledge of networking protocols. Nevertheless, mitmproxy is still a brilliant piece of software – just make sure you aren’t abusing it for malicious purposes.
