[Snort-sigs] Worm Signatures
kmx at ...2383...
Wed Apr 7 11:57:09 EDT 2004
It really depends on what kind of depth you want to have with the rules
your implement. If you want to catch specific known virus's you can
write a number of rules to look at the (normally) MIME encoded file
payloads. In most cases there is a string or two of bytes that are
pretty unique to an individual worm or virus. (mileage may vary)
<Mail Header of incoming virus>
Content-Disposition: attachment; filename="some-virus.pif"
AUekjdfaijlkjdi....blah base64 encoded MIME file here
alert tcp $SMTP_SERVERS any -> $EXTERNAL_NET 25 \
(msg:"Some virus attachment"; flow:to_server,established;\
content:"filename=|22|"; distance:0; within:30; \
content:"AUekjdfaijlkjdi....blah base64 encoded MIME file here"; \
classtype:possible-virus; sid:x; rev:x;)
The above is a good way to catch known virii/worms if you have good MIME
content strings to match on. The biggest problem with this is that each
new variant will probably have totally different base64/MIME encoded
content. So you might catch NetSky.A but you won't catch
Another way to approach it is by looking for suspicious filenames or
filename extensions. IE look for .pif .scr .exe .dll, check out the
latest revision of SID 721, the super filename extension rule from Brian
for a good example. These things don't normally get attached to valid
email floating around real networks. This also has draw backs, please
highlight the word normally in the previous sentence. But, it might
catch unknown virii or at least a metric ton of spam, you'll quickly
find out how many different products will enlarge your member.
Hopefully that will get you started.
> On Apr 6, 2004, at 6:38 PM, Jason Haar wrote:
>> On Wed, 2004-04-07 at 08:30, Matt Kettler wrote:
>>> With free tools like clamav available it's cheap and easy to get virus
>>> scanning right and do it at the MTA layer. Once the message is
>>> spooled onto
>>> a mailserver an AV scanner can take it's time and unpack zipfiles,
>>> against thousands of signatures, look across wide spans of the data,
>>> This kind of analysis is not realistically possible within snort.
>>> Snort is
>>> a real-time analysis system, snort can't stop and spend hundreds of
>>> milliseconds decompressing data to do analysis, as it will miss other
>>> packets going by while it does so. A MTA is a queued system, and small
>>> delays don't cause loss of protection, just slower delivery, and a few
>>> hundred milliseconds won't be significant compared to the overall time a
>>> typical end-to-end mail transfer takes.
>> Great description there Matt, but there's one key feature that Snort has
>> over most SMTP AV systems: it reports the client IP address...
>> Very few commercial AVs report the IP address the virus came from, so
>> you are left with quite a manual job to hunt it down (Qmail-Scanner is
>> an exception! ;-). Snort obviously hands that out, so when it sees a
>> virus on the network, you immediately know where it came from.
>> End of the day, it's always the same: defense in depth
>> Jason Haar
>> Information Security Manager, Trimble Navigation Ltd.
>> Phone: +64 3 9635 377 Fax: +64 3 9635 417
>> PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
> I have tried to make a similar point earlier (as far as asking the same
> question, but for a different purpose), but to no avail. My point was
> that I see a setup like the one I will describe below very, very useful
> (whether production or research environment):
> MX-record-server --> filter smtp server (RHBL, RBL, content, DSPAM,
> etc.) --> antivirus server (the order here is obvious - I do not want to
> scan junk) --> HONEYPOT smtp server --> internal servers
> The reason of interposing a honeypot here is:
> 1. I want something to catch what is left after the levels before;
> 2. I want a holder for honeytokens (email accounts "ALMOST" like
> internal accounts - but nonexistent)
> 3. I can afford to remove the honeypot any time I like, w/out any impact
> to the functionality of the whole (I am not better or worse with or
> without it, as far as the email flow is concerned), allowing study of
> NEW forms of: UCE/UBE/SPAM or WORMS or VIRII. Think - for example - of
> having tons of users whose email addresses are: XYZ at ...2379..., and
> one YXZ at ...2379... honeytoken (non existing account, but similar to
> real email addresses). With a honeypot I can afford to receive a
> virus/worm, then simply take off-line the whole honeypot and "practice"
> with the payload of attachments, emails, etc. Try to do that with a
> production system!
> It is at point 3 that I am interested in snort signatures SPECIFICALLY
> for the reasons above. And my original question was the same as I have
> seen so far in the last couple of weeks: HOW does one start to approach
> such things?
> I hope some would see now the benefit of knowing how to write snort
> virus/worms/spam "signatures"! At least under my scenario the purpose is
> not to replace anything - it is to add another security tool to the
> arsenal I have.
> P.S. I have actually come up with a functional system capable of doing
> the above, except for the refinement of the Snort signatures (I am still
> writing them on "how-I-feel-about-things:), as part of the tools I will
> produce for a paper I am writing. If anybody is interested, I could
> share that info, once done.
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
More information about the Snort-sigs