Odd WebDAV requests
Results 1 to 7 of 7

Thread: Odd WebDAV requests

  1. #1
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401

    Odd WebDAV requests

    Hey ppl,

    In our logs i've seen a couple of odd webdav requests and I'm wondering if it's an exploit or something that i'm not aware off. I did a few searches but came up empty. The only exploits/problems I could find have to do with an extra long SEARCH request. But nothing like this.

    Here's a line from our logs:
    Code:
    xxx.xxx.xxx.xxx %s - [10/Jul/2003:12:07:52 +0200] "SEARCH / HTTP/1.1" 501 304 "-" "-""-"
    What worries me is the %s. This should be the host: header and it smells like a formatstring exploit of some kind. The thing is that this request seems to crash our software. I'd like to verify this so I can inform our supplier of the software about this problem.

    Anybody know of a scanprogram and/or exploit that generates requests like this?
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  2. #2
    Jaded Network Admin nebulus200's Avatar
    Join Date
    Jun 2002
    Posts
    1,356
    I have seen a bunch of these as well, I believe them to be people that are trolling for servers running WebDAV. If I had to guess as to why you have %s, look here:

    http://www.securiteam.com/exploits/5SP0L159FC.html

    What it does in the actual attack is:

    sprintf(search,"SEARCH / HTTP/1.1\r\nHost: %s\r\n\r\n",host);

    Since he feeds it the Host value of %s in the HTTP field, and it is HTTP 1.1, I would guess it either couldn't resolve your host or that someone monkeyed with the code and made a booboo, in which case, if host = \0, then sprintf I think will still print out the %s. Since it is a HTTP1.1 request, your logs would indicate that Host %s was attacked, which is why you see that...

    I would recommend looking at the code a little closer, but I have the strong suspicion that is roughly what is happening...

    /nebulus
    There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.

    (Merovingian - Matrix Reloaded)

  3. #3
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401
    Hmmm. I thought I looked at that code but didn't realise it might be modified. I discarded it because it's only usefull when you do a SEARCH on a name with 49K+ characters and my logs only show a SEARCH / HTTP/1.1.

    [......]

    Damn. I think I know what's going on. I took a closer look at the source ip's in my log. They all seem to be running some old and vulnerable server software. So it's quite feasable for someone to modify the code you mentioned and proxy this through all these 0wn3d servers.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  4. #4
    Senior Member
    Join Date
    Feb 2003
    Posts
    109
    I guess there are some new code snippits out there for probing webDAV, probably incorporated into some kiddie autorouters. Ive seen several of these in my apache logs as well. You would think they would save themselves the time by checking the server header.
    $person!=$kiddie or die(\"Alas, die you hotmail hacker!!\");
    SecureVision

  5. #5
    Jaded Network Admin nebulus200's Avatar
    Join Date
    Jun 2002
    Posts
    1,356
    I did take a closer look at the code and, at least of the version I cited, don't see a way that %s would creap its way into the output...I wrote a little test program:

    Code:
    #include <stdio.h>
    
    int main(int argc, char *argv[])
    {
    char request[80000];
    
    if(!argc) return 1;    // only necessary if no args are there, blank counts as arg, if not, core dump
    memset(request,0,sizeof(request));
    sprintf(request, "testing %s what happens", argv[1]);
    printf("testing again: %s", request);
    return 0;
    }
    Setting the variables roughly the same way that he does in the code and the only way %s showed up is if I specifically passed it...so maybe something that calls the code is foobaring it...but I would expect the error correcting (in test_host, to if it can resolve the host, it also tests later on to resolve) to catch that. Unfortunately, I can't test the code itself, don't have a windows machine with a compiler available at the moment...

    I will keep looking around to see if others have mentioned such a thing...

    /nebulus

    EDIT: There are at least 6 different and independent things floating around that exploit various parts of WebDAV, most of them concentrated on the SEARCH method (not all of them did though). Some target one host at a time, others multiple, some from the command line, some from a neat GUI, or from scanners such as nessus. Given that there are so many things floating around, I have pretty much given up on what exactly is generating the messages, but I would assume that it is probably a script kiddie reading the source code a little to closely or maybe one of the tools doesn't do proper checking for the host value somewhere, either way I wouldn't worry about it too much.

    EDIT2: On a somewhat funny, well, at least to me, note, it has been so long since I coded in C, I can't tell you how hard it was not to stick '$' in front of the vars and that I did a double take after it complained I commented out a line with '#'...doh...time to brush up on my C skills...
    There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.

    (Merovingian - Matrix Reloaded)

  6. #6
    Senior Member Maestr0's Avatar
    Join Date
    May 2003
    Posts
    604
    As Nebulus said I'm aware of at least 2 automated mass scanning webdav exploit tools. I can't say what the particular print is but they're out there, so this is not unlikely. Although I thought most of these were old exploits(of course we all know everyone patches their machines routinely ) there may be new ones used in the wild.

    Packetstorm Webdav exploits:
    http://209.100.212.5/cgi-bin/search/...&type=archives

    -Maestr0
    \"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier

  7. #7
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401
    I already looked through everything packetstorm had but couldn't find anything that would show up the same as in my logs. I also found and looked through everything noted on this page: http://www.lurhq.com/webdav.html

    It could also be possible for someone to have modified the perl code on the page nebulus200 mentioned. The perl code sends a Host: 127.0.0.1. But if you modify the line that says:

    Code:
    $Host_Header = "Host: 127.0.0.1\r\nContent-type: text/xml\r\nContent-Length: 133\r\n";
    to (note the backslash or else %s would be interpreted as a hash):
    Code:
    $Host_Header = "Host: \%s\r\nContent-type: text/xml\r\nContent-Length: 133\r\n";
    and keep $Buffer empty it looks very very much like the stuff I see in my logs.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •