HTTP Proxies and Loopback Addresses

article by Ben Lincoln

While I was testing some of the changes in the Motorola Is Listening article, I noticed that even with the Blur hosts set to 127.0.0.1, my phone was making the request through the proxy server I'd configured for the wireless connection (OWASP ZAP). I modified the proxy settings to not proxy connections to 127.0.0.1, but I wouldn't have expected to have to explicitly add that. A quick web search implies that it's not just Android that behaves this way - apparently most (all?) web browsers will do the same thing.

This has some interesting implications for people who use 127.0.0.1 (the loopback address) in this way. If their system is configured to use a proxy, and they haven't explicitly excluded 127.0.0.1, then their device is still going to communicate over the network for each of those requests. For a phone, this means more battery use. In addition, it means that if the person controlling that proxy server wants to, they can feed content to the device, even though the person using that device believes that the request is never being attempted over the network.

In addition, maybe I'm the last person to realize this and it's common knowledge among proxy administrators, but it also means that - depending on the rulebase the proxy is using, of course - clients can actually connect to services on the proxy server itself. For example, if I set up a multipurpose server which is an HTTP proxy but also has a locally-accessible webserver component (maybe a development environment for a web application) listening on 127.0.0.1:8080, and the proxy is configured to allow any connection where the destination is port 8080, then a client that connects via the proxy can request http://127.0.0.1:8080/ and access the web application which is only listening on the loopback address on the server!

Accessing loopback-listening webservers running on proxy servers

ZAP help page

Test version of my site, hosted on my desktop

The Squid Proxy configuration file actually explicitly mentions this type of issue, although as the file itself describes, the protective rule is disabled by default.

# We strongly recommend the following be uncommented to protect innocent

# web applications running on the proxy server who think the only

# one who can access services on "localhost" is a local user

#http_access deny to_localhost

This doesn't just apply to HTTP or HTTPS connectivity. Depending on the specific proxy server software and its configuration, other types of TCP connection may be possible via CONNECT requests.

The current version of Squid, for example, defaults to only allowing proper SSL connections to be made using CONNECT, but if an administrator turned this off in order to make something else work (a finnicky old application, for example), then it's possible to connect to e.g. a local SMTP service running on the proxy server.

Microsoft ISA Server 2006, on the other hand, will allow CONNECT requests to any destination port that's in its internal list of HTTPS ports, and will not perform packet-inspection to verify that the traffic really is HTTPS. If an administrator has e.g. modified that list to include any port (maybe they use a lot of HTTPS applications on nonstandard ports, and got tired of adding to the list every week), then it should be possible to misuse ISA in the same way.

OWASP ZAP does not appear to allow connectivity to any non-HTTP/HTTPS services, but it does allow connectivity to any port number (as long as the listening service is HTTP or HTTPS).

Sending email through a loopback-listening SMTP component on an HTTP proxy server

Sending email via the proxy

Message received!

You can even use proxychains to have nmap run a port scan of what is unintentionally made accessible on the proxy server's loopback interface (although only for TCP, of course).

First, set up your proxychains.conf file with a line like this (where 10.19.37.66 is the IP address of the HTTP proxy server you want to perform a loopback port scan against, and 3128 is the port it's listening on):

http 10.19.37.66 3128

Then call nmap using proxychains. Note that not all nmap connection types will work through proxychains, which is why I've used -sT here instead of -sV.

proxychains nmap -sT -O -p 0-65535 127.0.0.1

You should see some output similar to this, indicating that proxychains is intercepting the connection requests and sending them through the proxy, which is then making the connection attempt against its own loopback address:

ProxyChains-3.1 (http://proxychains.sf.net)

[ snip ]

Starting Nmap 5.21 ( http://nmap.org ) at 2013-07-28 19:30 PDT

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:3389-<--denied

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:1025-<--denied

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:5900-<--denied

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:1723-<--denied

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:53-<><>-OK

[ snip ]

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:25-<><>-OK

[ snip ]

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:3128-<><>-OK

[ snip ]

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:62674-<><>-OK

[ snip ]

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:47806-<><>-OK

[ snip ]

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:631-<><>-OK

[ snip ]

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:55058-<><>-OK

[ snip ]

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:51125-<--denied

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:64064-<--denied

|S-chain|-<>-192.168.0.47:3128-<><>-127.0.0.1:27672-<--denied

[ snip ]

WARNING: RST from 127.0.0.1 port 25 -- is this port really open?

Nmap scan report for localhost (127.0.0.1)

Host is up (0.0029s latency).

Not shown: 65529 closed ports

PORT STATE SERVICE

25/tcp open smtp

53/tcp open domain

631/tcp open ipp

3128/tcp open squid-http

47806/tcp open unknown

55058/tcp open unknown

62674/tcp open unknown

Device type: general purpose

Running: Linux 2.4.X

OS details: Linux 2.4.21 (Red Hat Enterprise Linux 3)

Network Distance: 0 hops

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 2834.11 seconds

In this case, I was running a port scan of one Linux VM hosted on my Windows desktop from another Linux VM hosted on my laptop. Only the desktop-hosted VM has SMTP running (in addition to Squid), providing validation that the scan is of the loopback address on the proxy server itself, not the actual local system.

Proxied scanning is much slower - expect a scan of all 65535 ports to take at least an hour.