ISA Server vs US-CERT VU#435052 – A Quick Test


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:, DNS:, DG:None
External NIC: IP:, DNS:None, DG:

Client machine behind ISA:
IP:, DNS:, DG:

What are we looking for ?

The client will connect to a web site, which name resolves to, 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 A vulnerable transparent proxy will resolve this name, keep the connection open from the client to, resolve the name to, establish a connection to this address and route the GET request to Then it will forward the reply from to the client as coming from

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 web server. Additionally I could start a capture on the 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 name resolves to 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 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 web server.

The Wireshark capture on the 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 web site, which Squid resolved to IP address


As can be seen from the bellow Wireshark capture taken on the client, the client looks like it talks with the web server when it issues the GET request and receives a response for it:


The Wireshark capture taken on the web server shows that instead the GET request was routed to the 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.

Comments (5) -

  • Great post Adrian.
    • Thanks Robert!

      You've really put some great work within your paper!

  • Great to know ISA is not vulnerable! Nice post Adrian as always. ;)

    Paulo Oliveira.
    • Until Microsoft will pronounce(if ever), it's a good idea to test your own environment Paulo.
      And maybe some third-party filtering add-ons on ISA may interfere.

  • bob
    great blog posts

Pingbacks and trackbacks (1)+

Comments are closed