[prev in list] [next in list] [prev in thread] [next in thread]
List: incidents
Subject: Re: CodeRed Snort Rules
From: "Nick FitzGerald" <nick () virus-l ! demon ! co ! uk>
Date: 2001-08-29 23:19:16
[Download RAW message or body]
"CERT-Intexxia" <cert@intexxia.com> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic