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:
Microsoft Internet Information Services WebDAV Security Bypass Vulnerabilities - Secunia Advisories - Vulnerability Information - Secunia.com
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: