WebDAV Buffer Overflow Attack Compromises IIS 5.0

rf0 writes "Well CERT is reporting a new overflow attack for IIS 5.0. Microsoft has released a bulletin. Better download those patches and fix another security hole." According to this CNET story, Microsoft says that this is already being exploited, at the very least since last Wednesday.

Comments

Ugh

[wizarddc]

WebDAV has been a headache for for a long time, until I decided to just disable it altogther. I realized I never had a purpose for it, personally, so I added the disabling registry key too all my servers. If you know any good that WebDAV does, I'd like to know about it.

Re:Ugh

[questionlp]

According to the Microsoft bulletin (here):

What's wrong with the way IIS 5.0 handles WebDAV requests?

WebDAV uses IIS to pass requests to and from Windows 2000. When IIS receives a WebDAV request, it typically processes the request and then acts on it. However, if the request is formed in a particular way, a buffer overrun can result because one of the Windows components called by WebDAV does not correctly check parameters.

It sounds like WebDAV sends a malformed request back to the ntdll.dll for additional processing and possibly authentication (?) that is the problem. My guess is that the root of the problem is in ntdll.dll, but it could be mitigated by filtering WebDAV requests using the URLScan utility. More information can be had about 2/3 the way down in the same bulletin linked above.

HTH

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:What aspects of URLScan provide protection

[mattsouthworth]

A-ha! More info posted to NTBugtraq (after my original posting..)

Quote:
Just to clarify, Microsoft's bulletin states that this vulnerability
could have been prevented using URLScan and/or IISLockdown, but it
isn't really specific on how to do this. Several people have asked me
how this can be done.

The following steps can be used to block the attack:

1. Completely disable WebDAV by setting the
HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\ Param eters\DisableWebDAV
registry key to 1

2. Limit the length of requests (the url and any headers) by setting
the HKLM\SYSTEM\CurrentControlSet\Services\w3svc\param eters
MaxClientRequestBuffer to something like 16k

3. Block the following WebDAV HTTP verbs using URLScan (either by
specifically blocking them or by not listing them as allowed):
OPTIONS, PROPFIND, PROPPATCH, MKCOL, DELETE, PUT, COPY, MOVE, LOCK,
UNLOCK, OPTIONS, and SEARCH. Note that FrontPage does require the
OPTIONS method to work properly.

4. Block the following WebDAV-related headers using the [DenyHeaders]
section of URLScan.ini:
[DenyHeaders]
DAV:
Depth:
Destina tion:
If:
Label:
Lock-Token:
Overwrite:
TimeO ut:
TimeType:
DAVTimeOutVal:
Other:

5. If you require WebDAV, you can limit the
length of each individual header with these entries in the
[RequestLimits] section (The exact values are obviously pretty
generic and may need to be increased or decreased based on your
particular configuration):
[RequestLimits]
Max-DAV=250
Max -Depth=250
Max-Destination=250
Max-If=250
Max-L abel=250
Max-Lock-Token=250
Max-Overwrite=250
M ax-TimeOut=250
Max-TimeType=250
Max-DAVTimeOutVa l=250
Max-Other=250

Microsoft does not specifically state which HTTP Verb and/or header
is affected, but it does say that it is related to WebDAV. I would
therefore assume that setting ACLs on httpext.dll would still be
effective in blocking the attack. The PUT and DELETE methods are
still available in IIS, but only as part of the original HTTP spec,
not part of WebDAV.

Mark Burnett
www.iissecurity.info

Imagine an equivalent

[Anonymous Coward]

The best way to evaluate this bug is to consider an equivalent attack against competitors. In this case, the main competitor is Apache.

Cracking Apache in this way would not give you root. While you might be able to get root by using some other local exploit, it's not the slam-dunk that it is on Windows.

Furthermore, careful admins can run Apache in a sandbox called a "chroot". Properly set up, this means that the attacker can't get to the rest of the system; all they can play with is the Web site.

So, in summary:

Its all Microsoft's fault. Its crap software.

That's a pretty good assessment. The bug itself is a mistake lots of other people have made, but the severity of the mistake isn't.

Re:Q: WebDAV is Real?

[greed]

I've mounted WebDAV filesystems with my iBook, served by a Solaris machine with Apache and subversion. Even mounts under /Volumes, so programs don't even need to be aware of it; the XP "redirector" would fill this same role. (UNIX people can think "virtual filesystem switch" when you hear "redirector".)

If you just want a DAV filesystem, see mod_dav_fs in any recent Apache. (Which DOES run on Windows, for everyone who wants to toss the OS out with the webserver. Not that I'm a fan of Windows for anything, but you can run non-MS servers on the thing.)

Re:It's clear that you don't understand security..

[mike_sucks]

Sure, I can't wait to hear it...

- WebDAV is *nothing* like a VPN.

A VPN provides secure access to a remote network via one or more untrusted networks, typically the Internet. Once a VPN is established, the local endpoint has access to the remote networks's resources including, but not limited to, file, mail, directory, print and web servers. Existing protocols such as IMAP, POP, HTTP, LDAP, NFS and SMB can be used over the VPN in a mostly secure and transaprent manner.

WebDAV is an extension to HTTP - The Hypertext Transport Protocol. HTTP is deisgned to transport hypertext (hence it's name) and other media over via TCP. WebDAV provides distributed authoring and publishing extensions to HTTP to allow, amongst other things, remote collaboration. Using WebDAV for a network file system is akin to using FTP for the same. It is a bad idea.

=> WebDAV is nothing like a VPN.

- "using any number of authentication schemes" does not "lock down" anything at all.
- It doesn't matter if you are running it over HTTP or HTTPS. Both are the wrong protocol to use for filesharing. Just like using SOAP over HTTP(S).

Doing everything via HTTP, whether running plain text over port 80, encrypted over port 443 or any other combination is bad practice. One of SOAP's (and WebDAV's) "features" is that it allows you to do stuff over HTTP that would usually otherwise be blocked by a firewall. Want to do RPC? Sure! Just tunnel it through port 80! Want to do file sharing? Sure! Just tunnel it through port 80! This is seriously screwed up. It defeats a primary purpose for which firewalls were invented in the first place; to limit access to dangerous services. Not to mention that using HTTP for everything is a serious architectural design flaw as well.

Putting authentication in front of HTTP and/or tunneling it over SSL does not fix these problems. This IIS exploit du-jour is a perfect example of such.

- Web applications are irrevalent to network security.

A web application should be well designed and implemented, with security in mind. It should be deployed on a network which is properly secured. It should be running on systems which are properly securied. Making a web application secure does not make a network secure (and vice versa). "Irrelevant" is probably a too strong a word, but the security of a network should never be dependent on the security of a web application.

/mike