"Jeremy Junginger" <jjungingerat_private> wrote: > It's time again to ask the group for some assistance with interpretation > of web logs and snort alerts. There was some funny activity on the web > farm. I noticed a couple "ATTACK RESPONSES-http dir listing" attacks on > some of our web servers, queueing me in to the fact that the servers in > question were not patched against a Unicode-type vulnerability. ... Huh? Your Snort logs will include everything "odd" (as defined by the Snort ruleset) that goes past your Snort sensors. Nothing seen in such incoming traffic means anything about your machines being vulnerable (well, nothing of the sort you report here means your machines are vulnerable). An "attack" as you call it ("probe" might be a little less emotive and thus help sort things out) does not mean you have anything attackable. The same requests directed to an Apache clearly would not be "an attack", as it is not if directed to a patched IIS box. Snort (or any other IDS) with the same detection rules monitoring such traffic though will flag it regardless that the target is an IIS or Apache box. > ... I found > the offending IP, and tracked it back to a broadband home connection. I > think with reasonable certainty that the attack was not spoofed (because > of the nature of TCP and the fact that he received a response from the > web server); however, I cannot rule out the possibility of the host > being compromised. ... Indeed. The odds are quite high that it will be, and even if it's not you'd be lucky to find the ISP particularly inclined to help... > ... Knowing this, I reported it to our ISP and blocked > access immediately, ... Blocked the whole net-block or just the IP? If the former, you _may_ be unduly penalizing all those other subscribers to that ISP (it's a political call, and a business case one of the server in question is "commercial"). If the latter, are you sure it is on a static IP? > ... and began to analyze the logs more closely. The web > logs are continuous, so I am assuming that they are intact, though they > may be suspect. There are no lapses in time, and the logs appear to be > fairly contiguous. I also noticed that the attack was scripted, as > there were many WEB-IIS SAM RETRIEVAL attempts interspersed with the > Unicode strings, all happening in less than 10 seconds. The log entries > of the first server are below. > > 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) - - > > 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) - - > > This is an IIS 5.0/Win2k Server with SP2 and Latest Hotfixes per > HFNETCHECK, which I thought would preclude this server from being > vulnerable to a Unicode-type attack. The only thing that has not been > done is running URLSCAN and IISLOCKDOWN. Obviously, these will be my > steps for patching the servers, but I would like to ask for some > assistance with replicating the attack. 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 happens all the time -- random scanning for unpatched IIS servers. I'm on a dynamically assigned dial-up in New Zealand and typically get 1 - 4 such probes per day (when I have my packet catcher running, which reminds me I should restart it...). > INTERESTING NOTE: The web logs indicate that the URL Requested was > (correct me if I'm wrong) > http://x.x.x.17/scripts/..%5c..%5c..%5cwinnt/system32.cmd.exe?/c+dir > (possibly with a c:\ at the end). The "%5c" strings decode to "\", so the server was really considering "[...]/scripts/..\..\..\winnt/system32.cmd.exe?/c+dir" > When running this URL against the server, it produces a 404 error on the > server rather than listing the drive contents. ... As it should because you do not have a version of IIS vulnerable to the Unicode decoding directory traversalflaw. > ... The snort logs > (Snort/MySQL/PHP/ACID/Apache) indicate that the URL was > http://x.x.x.17/scripts/..%5c..%5c..%5cwinnt/system32.cmd.exe?/c+dir . Which is what we'd expect given the above. > I guess my question is three-fold: > > 1) Does the IIS server "decode" the string before logging it to the web > logs? Well, none of your snippets reputedly from the logs suggests it decodes the Unicode, as it is still there in the log entries... > 2) Does the Snort IDS "decode" the string before logging it to MySQL? Also, apparently not. > 3) Since there are few (if any) thorough Unicode scanners, is it > possible to write a perl script that could check for all possible > Unicode variants on a given web server to test the effectiveness of the > URLSCAN and IISLOCKDOWN utilities (pre-change/post-change pen-test)? I > have some "shell" programs like uni.pl, but am a little confused about > how to generate all of the possible combinations. This question does not really make sense. There are only a few Unicode vulnerability variants, but what is really meant by that and what a number of people produce when writing a "scanner" for them are two quite different things... The thing you have to realize is that there are a few different basic forms of Unicode encoding and each (?) of them has been shown to be exploitable in some or other version or patch-level of IIS. To test your version of IIS, you should only need to know each of those Unicode forms and the location on your servers of a "useful" program to produce some test output that will be sent back to the requesting machine if the decode bypasses the security checks and thus the test app is executed. Armed with that information you can write a trivial script with one test of each Unicode encoding method. However, what many of the "Unicode vulnerability scanners" provide is a long list of URLs to various programs commonly available in readily guessable locations and using one or more of the Unicode encodings. These can incorrectly clear a (somewhat unusually configured) IIS box simply because they fail to include a suitable path to a suitable "test" application. (The lists of URLs in such scanners are often compiled from web server logs and exploit scanners known to be used by script kiddies and others.) Regards, Nick FitzGerald ---------------------------------------------------------------------------- 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 : Thu Nov 14 2002 - 08:44:27 PST