Slashdot Mirror
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.
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.
Th
I don't know why anyone uses it anymore. I'm switching back to Morse Code. Who's with me?
More like "every day that ends in -day"
If you can't beat them, arrange to have them beaten. -George Carlin
If you listened to the Gartner Group, you stopped using IIS last year.
If you didn't, well, get with the program!
Eventually MSFT will have to deliver your "mission critical" ASP runtime for Apache, and the world will be a better place because of it.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Well, if they are going to have bugs, it is not that bad of a thing as long as they are patched promptly. Then again, many admins do have a tendancy to run unpatched machines.
Comment removed based on user account deletion
I was ready to uninstall IIS when it occured to me that Exchange 2K needs it. I was ready to uninstall Exchange 2K when I realized users would not be able to function. Whew, luckily I came to my senses...
I hope you don't have a static buffer allocated for those messages, because it'll....ummm...overflow.
[b.belong('us') for b in bases if b.owner() == 'you']
>Why is the code that the web server has access to
>change allowed to take over the system?
Because it is "trusted".
Between getting rooted and being automatically subject to license agreements, I'd rather get rooted.
What's this Submit thingy do?
It says near the bottom that IIS systems with URL scan which is part of the lockdown utility are not affected by this.
/.'s don't like microsoft and thats sad because microsoft is the driving company behind many many jobs. The arrival of windows pushed the last boom. No questions about that. Unix had been around for 20 yrs and no boom. Windows and the net and look at how things accelerated..why..because ma/pa people use windows..not *nix. Just the facts.
Why would you run a IIS server without using the lockdown utility??
We (large corporation) have been using IIS servers and without a problem. With Lockdown/urlscan there are no problems at all. The logs show people trying to get in but being rejected.
I think this story is a bit overblown. It appears that most
cheers
John
A-ha! More info posted to NTBugtraq (after my original posting..)
\ Param eters\DisableWebDAV
m eters
a tion:O ut:
x -Depth=250L abel=250
M ax-TimeOut=250a l=250
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
registry key to 1
2. Limit the length of requests (the url and any headers) by setting
the HKLM\SYSTEM\CurrentControlSet\Services\w3svc\para
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:
Destin
If:
Label:
Lock-Token:
Overwrite:
Time
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
Ma
Max-Destination=250
Max-If=250
Max-
Max-Lock-Token=250
Max-Overwrite=250
Max-TimeType=250
Max-DAVTimeOutV
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
Typically GUI config apps don't give you all the options either. They give you the most common ones. The rest are buried (in the case of Windows) in the registry. A pretty GUI just gives the _illusion_ that you're in control.
/etc/ssh/sshd_config). A bad config file will list only options that are different than the defaults or not included in the defaults.
A text file can hide options too, but not in the same way. Generally, applications have many defaults that don't need to be defined in the configuration explicitly. A good config file will list most of these anyway, even if commented out (example
That being said, there is no reason that someone putting a server on the internet should be afraid of editing a text file. Even in Windows! Notepad is just fine...
If you're playing on the public internet, you have to put up or shut up (know your shit, or accept the consequences)...
Obviously though, this issue has nothing to do with the WebDAV exploit. Even the best admin is at the mercy of the quality of his/her software (whether UNIX or Windows or $your_os).
-Ben
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.
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.)
The problem with this patch is that it wasn't found by a white hat and submitted. It was discovered by people getting hacked and calling MS asking WTF. In cases like that, 5 days isn't really that bad. In cases where an exploit, along with vulnerability code, and a description are fed to devs on a platter, open source or not, it makes the task 10x easier. When you have to figure out what is going on while under fire, and in a hurry, things get messy. That said, you can hack a lot of systems in 5 days with the right script.
-Charlie
It is a concrete fact that that no MacOS based webserver has ever been hacked into in the history of the internet.
The MacOS running WebStar and other webservers as has never been exploited or defaced, and are are unbreakable based on historical evidence.
Okay, this is ludicrous. I ran Webster and other macintosh web servers in the 94-96 time range for a significant test prep company in NYC. They are just as insecure as any other web servers. The insecurity comes from the CGIs, not the static content. But who cares...programmer level or system level insecurity has the same result.
The claim is false - i've done this myself to prove a point.
Why is is hack proof? These reasons :
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT. Apple uses an object model for process to process communication that is heavily typed and "pipe-less"
Sure, Pre-OSX Macs have no CLI really, but does it make a difference if you can disable, DoS or take control of the system, even? Sure, they are configuration mistakes. You can make those with Apache/*nix or IIS/win32 too. I've seen Timbuktu installed with no firewalling and simple plaintext password protection of the most trivial kind. I've seen CGIs that allow system control of various sorts, put in place by the same type of people who love the ease of use of macintoshes. Security?
2> No Root user. All Mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stuff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.
Sure, all Macintosh programming is done carefully as a result.
By your estimation, access controls are a complete waste. I'm sorry, this doesn't hold much water. I could use the same argument to state that Wintel boxes are better web servers. We all know how that pans out.
If all Macintosh programming was so excellent, those Type 1 errors where you have no choice but to restart would be a thing of the past, right? I still see them. Though I have to admit the car crash sound is better than a blue screen.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The Mac avoids C strings historically in most of all of its OS. In fact even its ROMs originally used Pascal strings. As you know Pascal strings (length prefixed) are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits. Individual 3rd party products may use C stings and bind to ANSI libraries, but many do not. In case you are not aware of what a "pascal string" is, it usually has no null byte terminator.
Pascal strings have a single length byte and can't handle anything longer than 255 characters. Many http requests are going to be longer than that. Obviously, Webster and other Mac web servers aren't using those for everything, though admittedly the system calls require them in many cases. Your argument about this preventing buffer overflows is not very convincing as a result.
#4 must be a new feature because you could do just about anything cgi-wise with a macintosh in my days of futzing with them. Swiss cheese.
#5 - Applescript. Many CGIs used to use those as a control interface and obviously resource protections don't apply. They probably still do...
#6 - I fail to see how the Mac's zoned memory structure is any more protective than the hardware segmented memory protection of Intel (see Type 1 errors above), stack return addresses be damned. I'd be interested in any proof of this.
That is why the US Army gave up on MS IIS and got a Mac for a web server.
Not at this bas
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
Incompetent sysadmins still are the weakest link.
I don't agree with that. Microsoft itself can't keep up with the patch schedules; its servers regularly get hacked. Who has more resources than Microsoft? Nobody.
The fact is that if you are running a mission critical server you must test before deploying a patch. That takes time and money that the IT group has in short supply these days.
Then there is the issue of Microsoft's marketting - they sell IIS as the easy to use 'zero maintenance' lowest TCO choice. False advertising in this case.
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
-- "So, what's the deal with Auntie Gerschwitz et all?"