search
Linkedin

Proxying Tools

An important aspect of using web proxies is enabling the interception of web requests made by command-line tools and thick client applications. This gives us transparency into the web requests made by these applications and allows us to utilize all of the different proxy features we have used with web applications.

To route all web requests made by a specific tool through our web proxy tools, we have to set them up as the tool's proxy (i.e. http://127.0.0.1:8080), similarly to what we did with our browsers. Each tool may have a different method for setting its proxy, so we may have to investigate how to do so for each one.

This section will cover a few examples of how to use web proxies to intercept web requests made by such tools. You may use either Burp or ZAP, as the setup process is the same.

circle-info

Note: Proxying tools usually slows them down, therefore, only proxy tools when you need to investigate their requests, and not for normal usage.

hashtag
Proxychains

One very useful tool in Linux is proxychainsarrow-up-right, which routes all traffic coming from any command-line tool to any proxy we specify. Proxychains adds a proxy to any command-line tool and is hence the simplest and easiest method to route web traffic of command-line tools through our web proxies.

To use proxychains, we first have to edit /etc/proxychains.conf, comment out the final line and add the following line at the end of it:

#socks4         127.0.0.1 9050
http 127.0.0.1 8080

We should also make use of the -q option, which makes proxychains operate in "quiet" mode, suppressing the output of connection information to the console. This can be useful for reducing clutter in the terminal and focusing on the output of the application being proxied. For example, let's try using cURL on one of our previous exercises:

0xH4shDumb@htb[/htb]$ proxychains -q curl http://SERVER_IP:PORT

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <title>Ping IP</title>
    <link rel="stylesheet" href="./style.css">
</head>
...SNIP...
</html>

If we go back to our web proxy (Burp in this case), we will see that the request has indeed gone through it:

Proxy tab showing HTTP GET request details with buttons: Forward, Drop, Intercept is on, Action, Open Browser.

hashtag
Metasploit

Finally, let's try to proxy web traffic made by Metasploit modules to better investigate and debug them. We should begin by starting Metasploit with msfconsole. Then, to set a proxy for any exploit within Metasploit, we can use the set PROXIES flag. Let's try the robots_txt scanner as an example and run it against one of our previous exercises:

Proxying Tools

Once again, we can go back to our web proxy tool of choice and examine the proxy history to view all sent requests:

Proxy HTTP history showing GET request to /robots.txt with 404 status, request and response details displayed.

We see that the request has indeed gone through our web proxy. The same method can be used with other scanners, exploits, and other features in Metasploit.

We can similarly use our web proxies with other tools and applications, including scripts and thick clients. All we have to do is set the proxy of each tool to use our web proxy. This allows us to examine exactly what these tools are sending and receiving, and potentially repeat and modify their requests while performing web application penetration testing.

Try running 'auxiliary/scanner/http/http_put' in Metasploit on any website, while routing the traffic through Burp. Once you view the requests sent, what is the last line in the request?

PreviousEncoding/DecodingNextBurp Intruder

Last updated