Intro
http://www.kb.cert.org/vuls/id/435052
The above vulnerability note refers to “Proxy servers running in interception mode ("transparent" proxies) that make connection decisions based on HTTP header values may be used by an attacker to relay connection”.
More information about this issue can be found in Robert Auger’s paper called Socket Capable Browser Plugins Result In Transparent Proxy Abuse.
The vulnerability note contains a big list of vendors. As currently writing, there are many vendors with the “unkown status”. Interesting, a big player like Blue Coat is listed as “vulnerable” on this list, see Secunia’s advisory for the Blue Coat ProxySG. Microsoft is mentioned with “unknown status” as currently writing.
Speaking about ISA Server, this Microsoft doc briefly describes Proxy Scenarios for ISA Server 2004, please search through it for the topic with this name. We are interested in the “transparent proxy” scenario.
In this test lab, we are going to use an ISA Server 2006 SP1 SE installed on Windows Server 2003 R2 SP2 deployed as a firewall with two NICs. The web proxy on ISA is enabled, caching is disabled, no web chaining rules defined.
A client behind ISA is configured as a SecureNAT client(the DG of this clients is the IP address of ISA’s internal NIC). The client’s web browser is unaware of the web proxy’s presence.
ISA Server 2006 SE SP1 machine:
Internal NIC: IP:192.168.10.1/24, DNS:192.168.10.2, DG:None
External NIC: IP:192.168.22.234/24, DNS:None, DG:192.168.22.1
Client machine behind ISA:
IP:192.168.10.150/24, DNS:192.168.10.2, DG:192.168.10.1
What are we looking for ?
The client will connect to a web site web1.carbonwind.net, which name resolves to 192.168.22.156, the client is able to resolve DNS names as was configured with a DNS server. The client “thinks” it speaks directly to this web site, being unaware of the web proxy between it and this web server. While the client is connected to this web site, we will issue a “crafted” GET request containing the HOST header test.carbonwind.net. A vulnerable transparent proxy will resolve this name, keep the connection open from the client to 192.168.22.156, resolve the test.carbonwind.net name to 192.168.22.11, establish a connection to this address and route the GET request to 192.168.22.11. Then it will forward the reply from test.carbonwind.net to the client as coming from 192.168.22.156.
The below figure describes the test scenario.
If you have read Robert Auger’s paper, you will see that it contains a Reproductions Instructions topic. This is very useful, as it contains simple instructions using telnet, and one can easy test his environment.
I will start three Wireshark captures, one on the client, one on ISA’s external interface and one on the 192.168.22.156 web server. Additionally I could start a capture on the test.carbonwind.net web server. As you will see from bellow, this was not necessary for this ISA Server 2006 SP1 machine.
A Quick Test
Let’s proceed following Robert’s instructions.
As said the web1.carbonwind.net name resolves to 192.168.22.156. We will telnet to this IP address on port 80 from our client(a Windows XP machine):
And paste our GET request(if you want to see what you type you may set the localecho, as described here):
And hit “enter” twice:
As can be seen an answer was received. Actually, as it says there, during this test, the ISA Server 2006 SE SP1 “did not buy on this one”, being not vulnerable to the “crafted” GET request.
This picture shows the Wireshark capture on the client:
The client initiates the three-way handshake actually with ISA, then issues the “crafted” GET request.
The bellow screen shows the Wireshark capture taken on ISA’s external interface:
ISA does not make a routing decision based on the HOST header and forwards the GET request to the 192.168.22.156 web server. And a response is received from this web server. If ISA would have been “vulnerable”, it would have attempted to forward this request to the test.carbonwind.net web server.
The Wireshark capture on the 192.168.22.156 web server confirms the path of the traffic, look at the web server’s IP address:
The log on ISA:
For example, if we were to test a vulnerable proxy, like Squid, see Secunia’s advisory, we would have get a response from the test.carbonwind.net web site, which Squid resolved to IP address 192.168.22.11.
As can be seen from the bellow Wireshark capture taken on the client, the client looks like it talks with the 192.168.22.156 web server when it issues the GET request and receives a response for it:
The Wireshark capture taken on the test.carbonwind.net web server shows that instead the GET request was routed to the 192.168.22.11 web server:
As we saw, it may be easy to perform a quick test on your own environment, if you are not sure if your proxy is vulnerable or not.