-
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?
-
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
-
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.
-
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.
-
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...
-
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
-
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.
