full-disclosure - MyDoom-M evades attachment filters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4106390C.17551.A49F37B@localhost>
From: stuart at cyberdelix.net (lsi)
Subject: MyDoom-M evades attachment filters

Since the first MyDoom (which appeared almost six months ago, to the 
day) I have been nice and snug behind my executable attachment 
filter.  And my zipfile attachment filter.  But then MyDoom-M slips 
past ....

The reason is because it puts spaces or newlines into its MIME.  Very 
smart.  Apparently the MIME decodes OK (spaces and newlines are 
ignored by the MIME parser) but it sure makes it look different to my 
filters.

I post this message so that folks can get working on regexp rules 
that take spaces and newlines into account.

This MIME filter worked on almost all zipfiles until now:

UEsDBAoAA*

MyDoom-M however sends itself like this (two examples only):

U EsDBAoAA [rest of MIME here]

or

UEs 
DBAo
AA [rest of MIME here]

Not one shy of a challenge, I'll admit this beat my filter.  And I'll 
also speculate that this will not pose a long-term problem.  If 
you're a regexp w1zard, feel free to share how you'd approach this!

My current thoughts are something like this:

U*E*s*D*B*A*o*A*A*

Still got newline prob though.

Stu

---
Stuart Udall
stuart at@...erdelix.dot net - http://www.cyberdelix.net/

--- 
 * Origin: lsi: revolution through evolution (192.168.0.2)