"CERT-Intexxia" <certat_private> wrote: > ________________________________________________________________________ > TECHNICAL NOTE INTEXXIA(c) > 23 08 2001 > ________________________________________________________________________ > TITLE : CodeRed Snort Rules > CREDITS : Jean-Pierre Mennella / INTEXXIA > ________________________________________________________________________ > > > BACKGROUND > ========== > > Facing the huge amount of CodeRed Trafic, we needed ,here at Intexxia, > to quickly give statistical informations about all the CodeRed attacks > received on the machines we monitor. > > In order to know which CodeRed variant was logged we've written Snort > rules that identify every CodeRed variants. Well, some CodeRed variants... > We have chosen the following CodeRed worms classification : > > - CodeRedI : the one with ' /default.ida?NNN ' There are (were!) two variants (at least) like that -- the original CodeRed and the one with the fixed PRNG seed. (The variant that wishes to be called CodeRedII (what some of us call CodeRed.C) seems to have wiped out those first two variants (CodeRed.A and CodeRed.B) due to its more efficient spreading algorithm.) What I refer to as CodeRed.B others have been known to call "CodeRed v2", which raises confusion over the variants you describe next... > - CodeRedII : the one with ' /default.ida?XXX ' > - CodeRedII - New : the one with ' /default.ida?XXX ' > and ' _________ ' It would be much less confusing if these were referred to as CodeRed.C and CodeRed.D respectively. What you have called CodeRedII is also often called "CodeRed v3" by those aware that there were, in fact, two CodeRed variants before it. As if it is not confusing enough to have the same thing referred to as both "CodeRed two" and "CodeRed three" there are people who are unaware there were *two* CodeRed variants before "CodeRedII" (i.e. CodeRed.C) starting to refer to what you have dubbed "CodeRedII - New" as "CodeRed 3" or "CodeRedIII". There is a certain parsimony in naming these variants as CodeRed.<sub_variant> where <sub_variant> is an "incrementing" letter solely designating order of discovery. It also has the potential benefit of not naming something as its writer desired, thereby stealing some of the "glory" that goes with the "I wrote <name>" claims (I know that is anti-hackish, but that is not necessarily a bad thing!). > As others have noticed, we had CodeRed logs that came from proxies > without the '/default.ida?'. These entries are harmless. Even so we > decided to still make rules to isolate these 'attacks' from the > efficient ones. We have used the following terms : > > - CodeRedII - via proxy - Uneffective : > * with ' XXXXXXXX%u9090%u6858 ' > * and ' X-Forwarded ' I believe the term "unviable" is better than "[iu]neffective" as the latter has something of a connotation that an effect was expected, but the change happens invisibly to the sending agent, between the originator and the recipient, and may not happen to all samples sent out by a given infested host (you'd have to know everything about the network environment of that host to be sure). You are, I believe, talking about CodeRed "samples" that are munged from this: ---------------------------------------------------- | | | | | | GET | <overflow> | /HTTP GET\ | <overflow payload> | | | | \params / | | | | | | | ---------------------------------------------------- to something like this: ---------------------------------------------------- | | | | | | XX... | /HTTP GET\ | /extra \ | <overflow payload> | | | \params / | \params/ | | | | | | | ---------------------------------------------------- Sometimes the overflow payload part is truncated too, making the total "sample" shorter than the length of the original CodeRed variant, but more often the total length of the "sample" is the same as the original (3818 bytes for CodeRed.C and .D). > - CodeRedII - New - via proxy - Uneffective > * with ' XXXXXXXX%u9090%u6858 ' > * and ' _________' > * and ' X-Forwarded ' > > We also noticed in our logs real CodeRed attacks that came thru some > proxies. ... If I understand correctly what you mean by "real CodeRed attacks that came thru some proxies", they are not actually "real attacks" either. If you mean a scenario where a "real" CodeRed sample: ---------------------------------------------------- | | | | | | GET | <overflow> | /HTTP GET\ | <overflow payload> | | | | \params / | | | | | | | ---------------------------------------------------- is transformed into something like this: ------------------------------------------------------------------- | | | | | | | GET | <overflow> | /HTTP GET\ | /extra HTTP\ | <overflow payload> | | | | \param / | \parameters/ | | | | | | | | ------------------------------------------------------------------- by a proxy inserting the "extra HTTP parameters", but not altering any of the CodeRed-supplied "data" around it, then these are also unviable because the overflow offset into the payload is screwed by the existence of the data making up those extra HTTP parameters. > ... If not looked more closely, these logs might lead to false > conclusions, cause it's not the infected machine that appear leading the > attack,the reallity could not match the logs, depending on your logging > facility. Being able to detect such entry might help to find real > infected hosts. This way you don't waste time trying to identify the > origin of the attack if you don't have more logs to dig thru. > We have used the following terms : > > - CodeRedII - via proxy : > * same pattern as CodeRedII > * and ' X-Forwarded ' > > - CodeRedII - New - via proxy : > * same pattern as CodeRedII - NEW > * and ' X-Forwarded ' Indeed, these proxied requests are a problem if you want accurate stats or especially if you wish to contact the admins of the infected hosts so they fix their machines... I don't know anything about snort (leave that to the network experts) but can you get it to log part of what it found? If so you could extract the offending IP from the X-Forwarded-For: headers the proxies insert into the request. -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3529854 ---------------------------------------------------------------------------- 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 30 2001 - 10:32:18 PDT