Message-ID: <C0E32101.55B3%thor@hammerofgod.com>
Date: Tue, 18 Jul 2006 23:36:33 -0700
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: <medozero@...oo.com>, Bugtraq <bugtraq@...urityfocus.com>
Subject: Re: Bybass HTTP ( extension files ) in ISA 2004


Hi Mohamed:

I don't think it's a matter of "did not get it," but rather, one of "can't
reproduce it."  I know we've had a couple of emails off-line, but I wanted
to respond to your last posts on BT publicly (since you responded publicly).

I, and others, have not been able to reproduce this.  As I did off-list, I'm
requesting that you send logs of the behavior that you have witnessed so
that everyone can have an opportunity to review "real" data rather than just
statements of "this is broken." Just a few captures would be great, along
with some details on what client you used to produce your results.

In the simplest form of testing (using a browser) the inclusion of a "#" in
the "bad" request of ".zip#" fails, as does the "good" request of just
".zip"

Trying it both ways, testing with IE on Windows and Safari on Mac OSX both
set up as Web Proxy Clients, you get the same HTTP response from ISA:

Technical Information (for support personnel)
Error Code: 502 Proxy Error. The request was rejected by the HTTP filter.
Contact your ISA Server administrator. (12217)
IP Address: 192.168.1.129
Date: 7/19/2006 12:30:10 AM
Server: yeti 
Source: web filter 

On the server itself, here are the logs of both requests:
[.zip request]
The request was rejected by the HTTP filter. Contact your ISA Server
administrator.
Denied Connection    Web Access    192.168.1.20    anonymous
Internal    External    GET    http://www.isatools.org/createshare.zip
Blocked by the HTTP Security filter: URL contains an extension which is
disallowed

[.zip# request]
The request was rejected by the HTTP filter. Contact your ISA Server
administrator.
Denied Connection    Web Access    192.168.1.20    anonymous
Internal    External    GET    http://www.isatools.org/createshare.zip
Blocked by the HTTP Security filter: URL contains an extension which is
disallowed

The first request was denied as expected. On the second ".zip#" request, the
filter dropped the "#" when sending the GET, and filtered the request.

That was for "Web Proxy Clients."  Removing the Proxy settings and using the
Firewall Client yields the same results.

Configuring the client as SNAT was a bit different.  The filter worked as
expected in both cases, except the server returned a " Error Code: 500
Internal Server Error. The request was rejected by the HTTP filter. Contact
your ISA Server administrator. (12217)" So, a 500 rather than a 502.
Regardless, it still worked as expected.  One should note that the filter
also dropped the "#" on the server side when the request was made from an
SNAT client.

Alternate client objects also failed to produce your results.  Instantiating
a winHTTP object gives a 502 when trying ".zip" and a 404 when trying
".zip#"  What *is* interesting is that the winHTTP object's WinHttpRequest
method interprets the "#" as a literal and converts it to "%23" when sending
to the proxy.  This is the closest thing to your claims that I could find.
ISA, when processing "http://host.domain.com/file.zip%23" does indeed yield
an "Allow Connection" result, but alas, since the host file is ".zip" and
not ".zip%23" you get a 404 "Not found." I guess that if you used winHTTP
objects and requested a .zip# file that was already on the server named as
".zip%23" that might work.  The only problem there is that IIS6 won't parse
that, so even if you did have a server operator rename the file to ".zip%23"
you still couldn't' download it from an IIS box, with or without a filter in
place.  Don't know about other servers.  And regardless (part II) it still
isn't a "bypass" of the filter.  The client requested ".zip%23"

So, even if you use an "alternate" HTTP object to make the request, the
filename won't be the same so you couldn't download it anyway.

Out of curiosity, I then loaded up Achilles (hey, it's old but it works) so
that I could intercept the client request, replace the GET request, and post
the ".zip#" directly to the server so that there would not be any question
about the client.  

As expected, the web filter cleared the "#" and denied the file with a 500.

Please provide some logs or other captures to substantiate your claims
regarding this resumed vulnerability.

Thanks!
T
---
New Blackhat Vegas 2006 Training Offered!
ISA Ninjitsu: 
Designing, Building, and Maintaining Enterprise Firewall
and DMZ Topologies with Microsoft ISA Server 2004
http://www.blackhat.com/html/bh-usa-06/train-bh-us-06-tm-isa.html










On 7/16/06 3:50 AM, "medozero@...oo.com" <medozero@...oo.com> spoketh to
all:

> well for those who didnot get it it is like this
> 
> make a rule in ISA and in the role make the source is internal network and the
> destination is external now configure the HTTP policy to block specific
> extension like zip ok now test it try to download any file.zip y0 will have
> that ISA will prevent y0 from downloading it > now try to add # to the end of
> the file like file.zip# and see what will happen . If y0 have any comment on
> this plz reply . and for some ppl who think this is a scripkeddies thing it is
> not as it is a bug as i see it .
> 
> 

Powered by blists - more mailing lists