Chris-Linfoot.net

When Mailer contains AnonMail_Version do not accept message

How do I know this?

Picture this:

1. User acquires a Sober.Whatever infection and sends a copy of itself to some third party with a spoofed sender which is a role account here.
   
   That role account is a group with ten local members.
   
   
2. The victim's system correctly identifies the virus (well done), and contrary to the usual practice does not send a warning to the "sender" (well done again).
   
   No. It sends the original worm email, sans the malware attachment but now bearing a plain text warning that a virus was removed, to the intended local victim (commence sinking feeling).
   
   
3. Trouble is, local victim does not exist. Message bounces. The MIME of that bounce is broken but the bounce does observe one requirement of bounces in that it uses a null sender envelope.
   
   Bounce is now sent MAIL FROM:<>, to our role account (remember, a Notes group).
   
   
4. Every member of that group (all 10 of them) receives this odd looking broken MIME.
   
   
5. 48 times.
   
   That's c. 480 bogus virus warnings in the space of about 4 minutes.
   
   Nice.

When life hands you a lemon... Let's look at that MIME source. It is broken because although it has been sent with a null sender envelope, it is not an RFC2822 delivery status report. It is just a full copy of the worm email sans the malware payload and all MIME headers are intact.

The X-Mailer header of all samples is "AnonMail_Version 3.20".

No real email uses that header - I checked. It is only found so far in this variant of Sober. I predict that it or a similar header may well turn up in future Sobers.

So there you have it. This rule will also deny broken backscatter bounces like those 480 or so here earlier today.

Category: Domino: Administration
Technorati: Domino: Administration

1. Steve Dionne04/05/2005 15:15:43
Homepage: http://www.canamgroup.ca

Hi Chris,

We already got more than two hundreds of the current variant of Sober.
I can tell you that most of these messages has been sent without any X-Mailer field.

Sometime it use an X-Mailer Field.
Here are some example I found:
AnonMail_Version 8.85
AnonMail_Version 9.27
AnonMail_Version 1.97
AnonMail_Version 6.46
AnonMail_Version 4.70
AnonMail_Version 7.6

Unfortunately, The rule you wrote above: "When Mailer contains AnonMail_Version do not accept message"
will block some of them, but not all!

Thank you to have share this with us, I didn't remark it before I read your blog.

2. Mike Wissinger04/05/2005 21:12:43

We're blocking based on attachment name. there are only 5 variants in the english versions (and 5 more in the german text):
# our_secret.zip
# mail_info.zip
# error-mail_info.zip
# account_info.zip
# account_info-text.zip
# LOL.zip
# autoemail-text.zip
# _PassWort-Info.zip
# Fifa_Info-Text.zip
# okTicket-info.zip

It's not as elegant as a single X-Mailer header, but I haven't managed to implement the extended mail rules yet.

Unable to post a comment? Please read this for a possible explanation...