I know this an old topic, but I saw some people still wonder about it.
A client’s web browser, for example a client located on ISA’s default Internal Network, ISA deployed as a firewall with two NICs, is configured to use ISA’s web proxy. When attempt to access a secure web site using HTTPS on a “non-standard” HTTPS port-say not destined to TCP port 443- tunneling this connection through the web proxy, the request will fail.
As usually, the US-CERT web site is a resource not to be ignored. A quick search there, and found Vulnerability Note VU#150227 named HTTP proxy default configurations allow arbitrary TCP connections, which provides a detailed explanation about the consequences when a misconfigured web proxy may allow an attacker to make arbitrary TCP connections through it with the “help” of the HTTP CONNECT method:
http://www.kb.cert.org/vuls/id/150227
Typically HTTP CONNECT method though ISA for a HTTPS web site:
CONNECT www.carbonwind.net:443 HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)
Host: www.carbonwind.net
Content-Length: 0
Proxy-Connection: Keep-Alive
Pragma: no-cache
HTTP/1.1 200 Connection established
Via: 1.1 LAB4ISA
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
And after the web proxy returns the 200 Connection established message, the SSL handshake occurs:
Attempt to tunnel an arbitrary TCP connection trough ISA’s web proxy:
CONNECT www.carbonwind.net:80 HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)
Host: www.carbonwind.net
Content-Length: 0
Proxy-Connection: Keep-Alive
Pragma: no-cache
HTTP/1.1 502 Proxy Error ( The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests. )
Via: 1.1 LAB4ISA
Connection: close
Proxy-Connection: close
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 779
Also the search returned a related document Vulnerability Note VU#868219 called Multiple vendors' HTTP content/virus scanners do not check data tunneled via HTTP CONNECT method:
http://www.kb.cert.org/vuls/id/868219
As said there, when web proxies are by default misconfigured and allow arbitrary TCP connections through, one may escape content and antivirus policies, using the HTTP CONNECT method, for example by connecting to a HTTP normal port-TCP port 80- on an external web server.
As we saw above, by default this is not possible with ISA, as only TCP port 443 is accepted within the HTTP CONNECT method(and possibly 563 for the NNTPS, but let’s focus on TCP 443 for the moment).
ISA’s web proxy by default allows HTTP requests from web proxy clients regardless of the destination port, as it is able to recognize HTTP traffic on a “non-standard” HTTP destination port, a simple antivirus test(a third-party antivirus add-on was installed on ISA, Kaspersky Anti-Virus for Microsoft ISA Server version 5.6.1281.0), and as you see no problems:
GET http://www.bad.carbonwind.net:443/original.html HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)
Host: www.bad.carbonwind.net
Proxy-Connection: Keep-Alive
HTTP/1.1 200 OK
Content-Type: text/html
Connection: close
<html><head><title>Kaspersky Anti-Virus for Microsoft ISA Server</title></head><body><h1>Kaspersky Anti-Virus for Microsoft ISA Server</h1><p>The requested URL "http://www.bad.carbonwind.net:443/original.html" is infected with Exploit.HTML.IESlice.d virus</p></body></html>
Now, an “opaqueness” test, antivirus evasion, access HTTP over TCP port 443 through the CONNECT method-the remote web server was configured to listen on TCP port 443 for normal HTTP requests-. Please note that the HTTP CONNECT method by itself does not specify by default which type of TCP traffic to be tunneled with it, in fact that may be the thing, the web proxy might not need to know anything about the content of the tunneled connection, so it’s up to the web proxy’s implementation to apply any inspection or not.
The lazy-easy way test, fire up cmd on my test Windows machine behind an ISA Server 2006 deployed as a firewall with two NICs, machine located on ISA’s default Internal Network and attempt to establish a connection to TCP port 443 to an external web server called www.bad.carbonwind.net which name’s resolves to the IP address 192.168.22.11:
“Abuse” the HTTP CONNECT method with a DNS name as the destination of the tunneled connection:
- type:
telnet 192.168.10.1 8080
- hit enter
- paste(to view what you paste on the Windows default telnet client, you may set the localecho, as described here):
CONNECT www.bad.carbonwind.net:443 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)
Host: www.bad.carbonwind.net
Content-Length: 0
Proxy-Connection: Keep-Alive
Pragma: no-cache
- hit enter twice
HTTP/1.1 200 Connection established
Via: 1.1 LAB4ISA
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
- paste:
GET /original.html
- hit enter twice
HTTP/1.1 200 Ok
Content-Length: 1766
Last-modified: Tue, 12 May 2009 13:09:33 GMT
Content-Type: text/html
Connection: Keep-Alive
Server: SHS
-----Output Omitted-----
“Abuse” the HTTP CONNECT method with an IP address as the destination of the tunneled connection:
- type:
telnet 192.168.10.1 8080
- hit enter
- paste:
CONNECT 192.168.22.11:443 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)
Host: 192.168.22.11
Content-Length: 0
Proxy-Connection: Keep-Alive
Pragma: no-cache
- hit enter twice
HTTP/1.1 200 Connection established
Via: 1.1 LAB4ISA
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
- paste:
GET /original.html
- hit enter twice
HTTP/1.1 200 Ok
Content-Length: 1766
Last-modified: Tue, 12 May 2009 13:09:33 GMT
Content-Type: text/html
Connection: Keep-Alive
Server: SHS
-----Output Omitted-----
The logs on ISA for such a test:
One may suggest to implement on the web proxy a method to inspect application layer data in the HTTP CONNECT method tunneled connection that would “identify” the SSL handshake, and thus allow “only” SSL traffic to be tunneled.
But, one problem is that the web proxy is not truly able to identify SSL traffic, just looks like SSL traffic to a certain extent based on the inspection implementation, thus this is a pseudo inspection method and should be treated accordingly.
Coming back to our above little test, actually, one of the “sources” of the successful of this “opaqueness” test, was a misconfiguration from the administrator, in this case me :), just look at the access rule 8 configured on the tested ISA, it allows “HTTPS” connections to anywhere(and these are not necessarily connections tunneled through the web proxy-connections from the web proxy clients), what would an attacker ask more:
ISA Server 2006 has actually the ability of truly inspecting HTTPS connections with the help of an add-on provided by Collective Software called ClearTunnel that “that empowers ISA to see inside SSL tunnels” and thus to filter HTTP traffic inside SSL:
http://www.collectivesoftware.com/Products/ClearTunnel
http://isaserver.org/tutorials/Product-Review-Collective-Software-ClearTunnel.html
Note: One may argue that this type of inspection may violate the end-to-end security model used by TLS/SSL. This is not entirely correct, as the SSL tunnels at the corporate level may be misused, and the machines used by the users do not belong to the users, they are the property of the company and should be used accordingly to the company’s security policies. “Truly” SSL sensitive “legitimate” traffic can be excluded from the inspection. From a certain security point of view when dealing with encrypted traffic, there are only two major possibilities unless explicitly needed to allow or deny it: either inspect it or just deny it.
Unfortunately I do not have ClearTunnel available right now in my lab and so I cannot complete the picture of this blog entry with some tests you may want to see. I’m most sorry about that, maybe in a future blog entry.
Extra Note: Whitelisting DNS names for tunneled “HTTPS” connections or for ClearTunnel exclusions may only function accordingly in the context of DNSSEC and a “legitimate” both client and server connection. Also, when “HTTPS” connections to some destinations(IP addresses), say are allowed directly(not tunneled through the web proxy, no ClearTunnel), an “evasion” test result may be “as expected” in case of “legitimate” both client and server connection.
Related docs:
- Managing Tunnel Port Ranges
http://technet.microsoft.com/en-us/library/cc302450.aspx
- Network Concepts in ISA Server 2006
http://technet.microsoft.com/en-us/library/bb794774.aspx
- Best Practices for Configuring Networks in ISA Server 2004
http://technet.microsoft.com/en-us/library/cc302676.aspx
- Troubleshooting Web Proxy Traffic in ISA Server 2004
http://technet.microsoft.com/en-us/library/cc302564.aspx
- KB891241, How to create a policy that enables only Web proxy clients in Internet Security and Acceleration (ISA) Server 2006, in ISA Server 2004, in Forefront Threat Management Gateway, Medium Business Edition, or in Windows Essential Business Server 2008
http://support.microsoft.com/kb/891241
- KB838708, How to bypass the Web Proxy service in ISA Server 2004, in ISA Server 2006, or in Forefront Threat Management Gateway, Medium Business Editor
http://support.microsoft.com/kb/838708
- Blog entry from the Forefront TMG (ISA Server) Product Team Blog
Why do I need a deny rule to make an allow rule for a custom protocol work correctly?
- HTTP Filtering in ISA Server 2004
http://technet.microsoft.com/en-us/library/cc302627.aspx
- MIME Types in ISA Server 2004
http://technet.microsoft.com/en-us/library/cc302528.aspx
- Using URL and Domain Name Sets in ISA Server 2004
http://technet.microsoft.com/en-us/library/cc302531.aspx
- Processing domain name sets and URL sets
http://technet.microsoft.com/en-us/library/cc441706.aspx