Malicious Forward Proxies
Forward proxies accept incoming connections from HTTP clients and forward them to the client-specified HTTP server via a separate connection, sending the potentially modified server's response to the client. Forward proxies usually issue DNS queries on behalf of the client.
A proxy is a so-called HTTP intermediary. The HTTP 1.1 specification (RFC 7230) distinguishes three types of HTTP intermediaries: proxies, gateways, and tunnels.
- A proxy is sometimes also referred to as a web proxy or HTTP proxy. When communicating with a web proxy, clients provide the absolute-URI of the target in requests that includes the scheme. Web proxies lack support for end-to-end encryption, as the proxy instead of the client manages the connection with the target server.
- A gateway is a reverse proxy that connects clients to an upstream server while behaving like an origin server from the perspective of the client, i.e., clients communicate with gateways as if they were directly connected to the target server.
- Clients typically use the HTTP CONNECT method to initiate the connection with a tunnel. Thereafter, the tunnel blindly relays data between the client and the origin server over TCP, allowing for end-to-end encryption between the client and the origin server using protocols such as TLS. The CONNECT method supports authentication of clients to the proxy via the Proxy-Authorization header whose value allows the server to verify whether or not a client is authorized to establish a tunnel to the destination. As RFC 7231 points out, HTTP tunnels that use the CONNECT method should validate and restrict the targets, possibly via a whitelist of permissible ports and targets. Otherwise, the tunnel may potentially be abused for purposes such as relaying spam (example put forward in RFC 7231) or penetrating internal networks. Tunnels may implement the SOCKS protocol that in contrast to the CONNECT method allows for relaying UDP traffic (with SOCKS5) in addition to TCP traffic. Since the SOCKS tunnel just relays data once the connections are established, the use of an end-to-end encryption protocol between the client and origin server is possible.
Both web proxies and tunnels, but not gateways, can be considered forward proxies.
A common application of forward proxies is to cache content (such as HTTP responses and DNS lookups) for many clients in order to save bandwidth. Moreover, forward proxies can be used to monitor as well as filter HTTP traffic. It may provide anonymity by hiding the client's IP address from the target server or act as a transparent proxy that forwards the client's IP address to the target server via headers such as the X-Forwarded-For header. Transparent proxy often identify themselves to the target server by adding a header such as the Via or X-Via header. Other forward proxy use cases include debugging web applications with proxies such as Burp Suite or mitmproxy. For more details on proxy uses, see Wikipedia.
Squid is a popular open-source forward proxy server implementation for Linux, certain Unix systems, and Windows. It can also act in reverse proxy mode where the proxy behaves like an ordinary HTTP server from the perspective of the client. Another open-source forward proxy server implementation that runs on many platforms is Privoxy. This proxy offers filtering capabilities that promotes the privacy of its users.
A feature of Privoxy is to modify server responses in order to remove tracking cookies and strip out advertisements. While Privoxy modifies server responses for the benefit of its users, there are proxies that modify responses for nefarious purposes such as the malicious Komodia/Superfish proxy that injects advertisements. Unlike HTTPS that uses TLS, HTTP doesn't protect against man-in-the-middle attacks that allow the attacker to read and modify the victim's network traffic. However, as the Komodia/Superfish malware adds its own root CA certificate to the system's certificate trust store, it can even control HTTPS traffic without the user receiving a warning in the browser.
Besides the Komodia/Superfish proxy that was shipped with certain Lenovo devices, numerous forward proxies on the Internet turn out to be malicious as well. In this context, the paper "An Extensive Evaluation of the Internet's Open Proxies" by Mani et al. finds that many open proxies, i.e., proxies that are available free of charge over the Internet, are unresponsive or behave maliciously. The malicious behaviors observed by the paper's authors include injecting cryptocurrency mining scripts into responses and adding malware to binary files downloaded via the proxy. Furthermore, the authors report that certain open proxies mount TLS man-in-the-middle attacks.
It is straightforward to build such malicious forward proxies studied in the paper. For example, the following HTTP proxy written in Node.js injects a script tag after the opening HTML body tag in the response, provided that the original server response of the target server contains an HTML body tag.
Alternative approaches to modify responses to proxied requests using Node.js are discussed in this Stack Overflow thread. An implementation of an HTTP tunnel written in Node.js that supports the HTTP CONNECT method and doesn't rely on the node-http-proxy module is provided in this question on Stack Overflow. The corresponding answer explains how HTTPS tunnels can be implemented where clients connect to the tunnel via TLS. Another HTTP CONNECT method-based tunnel implementation that also leverages Node.js native modules is provided in this Stack Overflow answer. Although that tunnel lacks client-to-tunnel TLS support, it is possible to add TLS support using tools such as stunnel as suggested in the Chromium documentation.
To test the proxies/tunnels, you can use ncat that comes with nmap. Assuming that the proxy or tunnel is listening on port 8080 on localhost, run ncat localhost 8080. If it listens on a TLS socket, connect using the command ncat --ssl localhost:8080.
To proxy a GET request to an HTTP origin server located at http://sub.example.com:80/ over a web proxy, connect using ncat and enter the following lines including the empty line at the end:
GET http://sub.example.com:80/ HTTP/1.1
Assuming that you are running an HTTP tunnel, run ncat to establish a connection and then enter the following lines:
CONNECT sub.example.com:80 HTTP/1.1 Host: sub.example.com:80Provided that the tunnel responds with HTTP/1.1 200 Connection Established after you enter the blank line, you can send a GET request to the target server over the tunnel:
GET / HTTP/1.1 Host: sub.example.com:80
A Virtual Private Network (VPN) can serve as an alternative to a forward proxy. Like third party-hosted proxies, free as well as commercial VPNs put the providers into a man-in-the-middle position that enables them to gather information about the network traffic of their clients. This position in the network allows VPN providers to fully control the communication for protocols such as HTTP. While third-party VPNs and proxies may offer anonymity, a self-hosted VPN doesn't require you to trust a third party service with your traffic. Software such as Algo VPN facilitates spinning up one's own VPN server with a secure configuration. Besides the traditional IPsec protocol, Algo VPN supports the modern, well-designed, and highly performant WireGuard protocol. WireGuard's code was praised by Linus Torvalds and was merged into Linux kernel 5.6.