On Mon, 13 Aug 2001, Lindley, Patrick@HHSDC wrote: I've been working with Patrick on this for a couple of days, and got special permission to send first a simulation of Code Red, and later an actual copy of CodeRed II, to replicate the problem. I want to thank Patrick and the HHSDC for allowing me to perform the test. The short answer is that it is a false alarm. The long answer is that it had to do with IDS state, and I think the answer will be of interest to the readers of this list. > For the past 13 days we have been experiencing an unusual occurrence. Every > time a particular patched NT 4.0 server of ours running IIS 4 is probed by a > Code Red infected system, our server immediately responds back to the prober > by attempting to exploit the vulnerability on that system. > > Example: 158.42.25.98 sends the "/default.ida?" string followed by the "X" > or "N" string (depending on the Code Red version) and our system immediately > sends back the corresponding hack such as the HTML used in Code Red (Hacked > By Chinese!) or attempts to execute or drop D:EXPLORER.EXE on the attacking > system. What is happening is that the IDS is becomming confused about who the attacker is, and has it backwards at one point. Therefore, it reports a packet containing the "Hacked By Chinese!" message (CRv2) or a packet containing "d:\explorer.exe" (CodeRed II). These are the remainder of each worm that is still on its way from the attacker. > > Our IDS logs and HTTP logs confirm these events. Our system in question does > not react as if it is infected with Code Red (i.e. continuously probing > other IP addresses) and as a matter of fact we have confirmed the MS patch > installation, run Trend Micro Systems anti-virus software on it, rebooted > it, and manually scanned for the tell-tale signs of Code Red infection. It > only sends out this Code Red-like activity when it is probed. It is in fact not infected. It is NT4.0, and it is patched (as evidenced by the HTTP response, see below.) > I've included a copy of one entry from our IDS below. Inbound port was 80 > and outbound port was 2913. Context incoming is the data that was sent to us > (for instance from 158.42.25.98) and context outgoing is what our server > sent back. Therein lies the confusion. The incoming and outgoing contexts becomed reversed. Some log entries are missing. Before the following log entry, there was one that indicated an incoming Code Red attack from port 2913 to port 80. This would be an actual copy of the worm trying to find a victim. Background: The web server in question has been "decommissioned", and all it does is serve up a web page that redirects to another site. As part of this redirect process, it ends up quoting the entire URL back to the client. The IDS spots the Code Red "URL", and detects it as another attack. However, now the HHSDC web server is the "attacker". > Ports: 80 -> 2913 > Context Match: [/]default[.]ida[?][a-zA-Z0-9]+%u > Context Incoming: > ://***.***.***.***/default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXX%u So "Incoming" means towards the attacking Code Red infected host that wants to infect the HHSDC web server. The HHSDC IDS is trying to "protect" a host outside of it's network. (Note that this is not that uncommon... many large organizations need to spot attacks going out from their inside.) Here is the header that sets it off: HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Cache-Control: no-cache,no-transform Expires: Wed, 15 Aug 2001 19:16:39 GMT Content-Location: http://x.x.x.x/default.htm?403;http://x.x.x.x/default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a Vary: * Date: Wed, 15 Aug 2001 19:16:39 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: xxxx IP addresses and content-length have been anonymized. You can see how the Code Red rule gets triggered. Limiting it to a destination port of 80 would solve this, and would not leave any significant exposure I can think of, at least not from Code Red itself which only goes after port 80. Someone could manually install Code Red x on port 81 if they found a webserver there, I suppose. However, the rule is hard-coded to current versions of Code Red, and not the exploit in general, so I assume there are other rules to catch general .ida/.idq exploit attempts. Now, the interesting thing about the patched servers is that they start responding as soon as they get the HTTP/1.0<CR><CR>. meanwhile, the attacker is still sending the rest of the worm. Since the attacker is now the victim as far as the IDS is concerned, here is the response of the "victim": > Context Outgoing: > \FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\ > FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\F > C\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC > \FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\FC\00\00\00\ > 00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00^\BF\B9\05\00\00j\07\E8 > \10\00\00\00d: > > explorer.exe\00\8B\04 > $\88\18\FFU\CC\83\F8\FFtM\89\85L\FE\FF\FF\AC\8A\F88>u'j > \E8#\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00 > \00\00\00\00\00\00\00\00\00\00\00j\01V\FF\B5L\FE\FF\FF\FFU\C8FOu\C5\FF\B5L\F > E\FF\FF\FFU\C4\FE\C3\80\FBd\0F\86L\F9\FF\FF\C3a\C9\C2\04\00\0 This is context "outgoing", and this IDS is obviously designed to catch the responses of victims (which is useful... helps you decide if the attack worked or not.) So, if you believe that the outgoing response was from the HHSDC web server, then it would appear to be trying to do some sort of strikeback. However, this end up simply being the rest of the worm on its way from the original attacker. So, that's the long version of the story. It took me being able to see the full IDS logs for an incident, my sending a real copy of Code Red II, my sniffing my outgoing connection (and HHSDC server response), and my examining the response from the web server (used netcat to send and receive) before I had all the pieces to figure it out. I found it entertaining, and I figured the list might enjoy an interesting IDS war story. Ryan ---------------------------------------------------------------------------- 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 Aug 16 2001 - 07:39:44 PDT