Why publishing WebDAV with ISA Server 2006 can be fun

by adrian 24. May 2009 00:53

Sometime ago we’ve discussed in a seven articles series how we can publish WebDav(running on IIS 6.0) with ISA Server 2006(domain member), and provide secure access to files similar to FTPS(FTP over SSL) in a simple, efficient and secure way.

What we gain if we do that:
- since ISA pre-authenticates any client, no packet will reach the IIS server before ISA accepts the user credentials.
- also ISA does SSL bridging meaning that you actually terminate the TLS tunnel on ISA and ISA initiates another TLS connection to the IIS server. In this way ISA is able to do HTTP filtering(normally, encrypted traffic cannot be inspected by the firewall) which is a key security feature these days.
- since you know what HTTP methods are “good” for your WebDav server you can instruct ISA to allow only these methods. Thus if for example ISA is set not to allow the "PUT" method, when the client will use it, this request will be blocked at the firewall and therefore it will never reach the IIS server.
- block various traffic based on signatures(within the Request URL, Request Header, etc.) 
- verify URL normalization or block high bit characters within URLs.
- granular path restrictions, we can allow access only to certain published folders, path restrictions per Active Directory users or group.
- and more.
Related docs:
- HTTP Filtering in ISA Server 2004 (useful info for ISA Server 2006 too), a doc from Microsoft.
- HTTP Policy Filter Options, Forefront TMG (ISA Server) Product Team blog entry.
- ISA Firewall Stateful Application Layer Inspection Filters (Part 2), an article written by Tom Shinder on ISAserver.org.
- Configuring the ISA Server 2006 HTTP Filter, an article written by Marc Grote on ISAserver.org.
- Three common ISA Server Web publishing scenarios, a doc from Microsoft.

 

Looking at Secunia’s web site the other days, I’ve noticed this:
http://secunia.com/advisories/35109/
Status: unpatched.

Related docs to the vulnerability:
- Microsoft Security Research & Defense blog entry about the IIS authentication bypass and blog entry about answers to the IIS WebDAV authentication bypass questions.
- Nazim Lala’s blog entry.
- Microsoft’s advisory 971492.
- Nikolaos Rangos’s (the one who discovered the vulnerability) document, found on the Milw0rm web site.

 

So can ISA protect our published WebDav IIS 6.0 server behind it while currently there is no patch ? (there are some work arounds though, and the vulnerability currently appears to apply only to certain configurations, see the Security Research & Defense blog entry for more details).
Let’s take a look.

Note: Apparently, as per Microsoft’s current description of the problem, see the Microsoft Security Research & Defense blog entry, this may relate to the IUSR_[MachineName] account. If you would have followed my guide for configuring IIS from the WebDav series, the configuration would not have been vulnerable even without ISA, that is, the files within the password protected directory could not be accessed with such a crafted request, due to the way NTFS permissions were set on the password protected directory.
Also, the IIS server was on an ISA DMZ, so even the internal clients(if any) would have to access it through ISA.

I’ve tried to quickly repro that configuration(the directory names are not the same, just the settings) and craft such a request against it(directly to the IIS server), and the request failed:

old_scenario_quick_test

 

Say we have such a vulnerable configuration. Since within the initial tests we are using HTTP, I will use the default Windows telnet client on a XP SP3 machine to “craft” my request. When we will do HTTPS tests I will use WFetch 1.4.(we have other options, but I haven’t used before, so I want to play with it :), as it looks pretty nice).

Directly to the vulnerable web server, normal request for a file requiring authorization which only webdav users suppose to access, the IIS server requires authentication:

normal_request

Crafted request, as described in the document published on Milw0rm, per Nikolaos Rangos(the one who discovered the vulnerability) explanation:

direct_crafted_request1_1

direct_crafted_request1

Variations of the crafted request:

direct_crafted_request2

direct_crafted_request3 

I could not make it “work” like so(either with the default permissions for the subfolders and files within the password protected folder set to inherit or by “adjusting” the permissions of the subfolders and files):

direct_crafted_request4

direct_crafted_request5

direct_crafted_request6

 

Let’s put ISA on the path, and do some tests, starting with very very basic web publishing rules(not that this kind of rules will be used in the real world), just to see various potential settings on ISA that may block such a crafted request.

 

The web server behind ISA, a very very basic web publishing rule on ISA(let’s call it test rule 1), not using SSL, no pre-authentication on ISA, no path restriction, no link translation, clients are allowed to authenticate directly(authentication over HTTP was allowed), the Block high bit characters option was selected for this rule(HTTP Filtering), this option may block some attacks against IIS servers, but it will also block URLs that contain a double-byte character set (DBCS) or Latin 1 characters(if this is enabled, URLs containing characters from languages that require more than 8 bits to represent the characters of the language, and so use 16 bits, will be blocked):

Note: As Jim said in his comment, Allow client authentication over HTTP was enabled just to test and demonstrate this process, and you should not enabled it in production. Microsoft’s KB 924374 acknowledges the dangers you may expose to when you enable that option and strongly advise against enabling that option. Instead you should configure the Web listener to listen for SSL requests.

isa_rule1

isa_rule1_1

isa_rule1_2

isa_rule1_3

isa_rule1_4

isa_rule3_11

isa_rule1_6

isa_rule1_5

Normal anonymous request through ISA, the IIS server requires authentication:

isa_rule1_normal_request

isa_rule1_normal_request_log

Crafted anonymous requests through ISA, requests rejected because the URLs contain high-bit characters:

isa_rule1_crafted_request1

isa_rule1_crafted_request1_log

isa_rule1_crafted_request2

isa_rule1_crafted_request2_log

 

Another test, the web server behind ISA, pretty much the same very very basic web publishing rule on ISA(like test rule 1), the Block High bit characters option was not selected this time, but now we are using path restrictions, at can be seen from bellow we can easily define granular path restrictions with ISA(let’s call it test rule 2):

isa_rule2_1

Normal anonymous request through ISA, the IIS server requires authentication:

isa_rule2_normal_request

isa_rule2_normal_request_log

Crafted anonymous request through ISA, note that actually the default rule denies the request, as it didn't match any rule:

isa_rule2_crafted_request1

isa_rule2_crafted_request1_log

 

Another test, the web server behind ISA, the same very basic web publishing rule on ISA(like test rule 2), but this time we also require authentication on this rule(authentication over HTTP was allowed), let’s call it test rule 3:

isa_rule3_1

isa_rule3_11

isa_rule3_2 

isa_rule3_3

Normal anonymous request through ISA, as can be seen now ISA itself requires authentication:

isa_rule3_normal_request

isa_rule3_normal_request_log

Crafted anonymous request through ISA, note that actually the default rule denies the request, as it didn't match any rule:

isa_rule3_crafted_request1

isa_rule3_crafted_request1_log

 

Another test, the web server behind ISA, now we have a web publishing rule on ISA(like test rule 3), but this time we also use SSL(as we should), ISA doing SSL bridging, more like a real world rule.
And to make things more interesting, I’ve actually created two web publishing rules, one allows access for the normal webdav users to the path /share/public/*, and the other one allows access for the super webdav users to the path /share/private/*(we could have allowed access for them for the share/public/* too if we would have wanted that):

isa_rule4_1

The normal webdav users web publishing rule:

isa_rule4_2

isa_rule4_3

isa_rule4_4

The super webdav users web publishing rule:

isa_rule4_5

isa_rule4_6

isa_rule4_7 

So a normal webdav user can access a document if he “obeys” the allowed /share/public/* path, but he cannot access a document(let’s say he knows the name and location of the document) from the /share/private/* location(note that his request is denied by the default rule, as it did not match any rule):

isa_rule4_normal_request1_log

isa_rule4_normal_request2_log

And a super webdav user can access a document if he “obeys” the allowed /share/private/* path, but he cannot access a document(let’s say he knows the name and location of the document) from the /share/public/* location(note that his request is denied by the default rule, as it did not match any rule):

isa_rule4_normal_request3_log

isa_rule4_normal_request4_log

To test our rules, as the normal Windows telnet client won’t work over SSL, I’m going to use WFetch 1.4.
First to make sure things are fine, a quick test, and they look good:

isa_rule4_normal_request5

A crafted anonymous request through ISA, and ISA denies it, note that the request is denied by the default rule, as it did not match any rule:

isa_rule4_crafted_request1

isa_rule4_crafted_request1_log

If ISA would not have been on the path:

crafted_request

Actually, we can(and we should) configure the HTTP filter even further, for example, the normal webdav users are allowed to use only the specified methods:

isa_rule4_8

So a normal webdav user can do a PROPFIND to list the /share/public/ directory:

isa_rule4_normal_request6

isa_rule4_normal_request6_log

A crafted anonymous request for such a method, note that the request is denied by the default rule, as it did not match any rule:

isa_rule4_crafted_request2 

isa_rule4_crafted_request2_log

But a normal webdav user can’t do a PUT, say to “upload” a file:

isa_rule4_normal_request7

isa_rule4_normal_request7_log

A crafted request for such a method(not that this would work on the IIS server, just to test against ISA), note that the request is denied by the default rule, as it did not match any rule:

isa_rule4_crafted_request3

isa_rule4_crafted_request3_log

Tags: ,

ISA Server

Comments (3) -

Jason Jones United Kingdom
5/26/2009 5:12:19 PM #

Interesting stuff!

Cheers

JJ

Jim Harrison United States
5/26/2009 9:57:19 PM #

Indeed - very creative. This article also demonstrates some of the more useful aspects of a granular firewall policy - that of separating access to various resources according to use group membership (just like NTFS permissions).

One point that may be overlooked amongst the screenshots: although Andrew allowed authentication over HTTP at the Web listener to test and demonstrate this process, you should not use this configuration in production; especially if you have to use Basic authentication (such as with EAS clients). Toss together a test lab on your favorite virtualization platform and test there, but not in production.

Jim

adimcev
5/26/2009 11:33:21 PM #

Thanks, Jim. I've edited this blog entry and added a note about the authentication over SSL thing.

By the way, who's Andrew ? -;)

Thanks,
Adrian

Comments are closed

Home | Hire me

Support this blog

Adds

Book Shelf

 

Month List