Re: Appeal for Help. NOT Code Red But Is It?

[Ryan Russell <ryan () securityfocus com>]

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