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:
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:
Crafted request, as described in the document published on Milw0rm, per Nikolaos Rangos(the one who discovered the vulnerability) explanation:
Variations of the crafted request:
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):
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.
Normal anonymous request through ISA, the IIS server requires authentication:
Crafted anonymous requests through ISA, requests rejected because the URLs contain high-bit characters:
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):
Normal anonymous request through ISA, the IIS server requires authentication:
Crafted anonymous request through ISA, note that actually the default rule denies the request, as it didn't match any rule:
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:
Normal anonymous request through ISA, as can be seen now ISA itself requires authentication:
Crafted anonymous request through ISA, note that actually the default rule denies the request, as it didn't match any rule:
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):
The normal webdav users web publishing rule:
The super webdav users web publishing rule:
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):
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):
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:
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:
If ISA would not have been on the path:
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:
So a normal webdav user can do a PROPFIND to list the /share/public/ directory:
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:
But a normal webdav user can’t do a PUT, say to “upload” a file:
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:
