[Snort-sigs] Signatures for .ida attempt
rfleck at ...265...
Thu Jan 17 15:14:08 EST 2002
> -----Original Message-----
> From: Chris Green [mailto:cmg at ...26...]
> Sent: January 16, 2002 5:24 PM
> To: rroot at ...254...
> Cc: snort-sigs at lists.sourceforge.net
> Subject: Re: [Snort-sigs] Signatures for .ida attempt
> I'm not sure what causes that split, perhaps there is some equipment
> along the way doing this. I saw on some forum asking if this was a
> new variant but I think the consensus was no.
Over on incidents (securityfocus) there was a discussion about this.
Ryan Russell had this to say about it (on 1/11/02):
> So, I went and looked at the eEye disassembly for CodeRed (.a, I believe)
> and found this:
> seg000:00000A87 8B F4 mov esi, esp ; Send a "GET "
> seg000:00000A89 6A 00 push 0
> seg000:00000A8B 6A 04 push 4
> seg000:00000A8D 8B 8D 68 FE FF FF mov ecx, [ebp-198h] ; points to GET
> seg000:00000A93 51 push ecx
> seg000:00000A94 8B 95 78 FE FF FF mov edx, [ebp-188h] ; points to socket
> seg000:00000A9A 52 push edx
> seg000:00000A9B FF 95 C0 FE FF FF call dword ptr [ebp-140h] ; send a GET
> In other words, CodeRed sends the "GET " in it's own send() call, it
> allways has. The operating system has the option to put multiple send
> calls together into one packet, at least for stream connections. Most of
> the time, it will do so. Whether it will depends on things like load, MTU
> (though that shouldn't come into play in this instance), etc...
> So, I think this has been going on on occasion for some time, and has gone
> largely unnoticed. I don't think this was intended to bypass IDSes or
> filtering mechanisms, I think it's just a side-effect of the way it was
> written. (Though worms could certainly do this sort of thing on purpose
> if the author wanted.)
> Another reader pointed out to me off-list that this has been going on for
> some time:
More information about the Snort-sigs