> > Web log entries: > > > > 2002-11-12 13:00:37 210.201.100.253 - x.x.x.17 80 GET > > /scripts/..%5c../..%5c../..%5cwinnt/system32/cmd.exe /c+dir 200 1849 321 > > 31 HTTP/1.1 63.241.137.233 > > Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) - - > > > > That server should not be vulnerable to the Unicode URL encoding > directory traversal trick seen above. It seems you have a "safe" box > and are getting all worried because your IDS saw something that > ... Whoooooooooooaaaaa...there's no question that this server IS vulnerable and WAS successfully "recon"d, Jeremy provided all the evidence you need with the single log entry. IIS logs like this are very rich with information. Take a closer look at the log entry /scripts/..%5c../..%5c../..%5cwinnt/system32/cmd.exe /c+dir 200 1849 321 And break it down into parts: /scripts/..%5c../..%5c../..%5cwinnt/system32/cmd.exe They asked for access to cmd.exe /c+dir They wanted cmd.exe to do a "dir" command and return immediately (no interaction) 200 The server returned an HTTP "200" OK to what they wanted. RED FLAG!! No doubt about it, someone successfully sent arguments to cmd.exe and it returned data. I can't imagine any scenario where you can get a 200 and NOT have control of cmd.exe (unless it's a honeypot cmd.exe). 1849 This is the win32 return code, and a 0 here would indicates success; quite honestly, I'm not sure what the 1849 is from (can anyone help with this one?)...It might be from the "dir" command, or it might represent the typical error "this page did not return a properly formatted header. The headers it did return are..." 321 31 This helps to confirm: you can see that 321 bytes were sent back to the client in response to the 31 byte request. There's some other good info we can get from this log entry: Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) means that whatever they're using for recon is probably using the built-in IE object and not crafting the http stream. Perl and command line tools usually don't include the "User-Agent" in the http header. Assuming they're not using a sophisticated tool that inserts a bogus user agent, it looks like they're running an older version of Windows 2000, possibly unpatched. - - Don't forget the blank entries, they're just as important. The first one is the cookie--if Jeremy's site uses cookies to track user sessions (the typical IIS setup), we know that this is the first time the user has been here recently (again, assuming they're typing the URL into IE). The second blank is for the http referrer--in this case, it's blank, it doesn't give you anything, but when it's not blank for an attack, it might help you find an attacker that's hiding behind a proxy. It's obvious thorugh testing that IIS does a single URL decode of the string before logging it, and it makes perfect sense to do that. But I'm still interested in knowing whether SNORT does--I wouldn't expect it to, and maybe it's not SNORT itself, but one of the actual presentations or storage mechanisms. ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Fri Nov 15 2002 - 14:59:55 PST