2017-11-29
Sometimes the right thing to do about a spate of spam is nothing (probably)
We have a program
to capture information about what sort of email attachments our
users get. As part of its operation it
tries to peer inside various types of archive files, because you
can find suspicious things there (and,
of course, outright bad things, some
of them surprising). This program is written
in Python, which means that its ability to peer inside types of
archive files is limited to what I can find in convenient Python
packages. One of the archive formats that it can't look inside right
now is .7z files.
Stretching through August, September, and October we received a
drizzle of email messages with .7z attachments that our commercial
anti-spam system labeled as various sorts of 7z-based malware (a
typical identification was CXmail/7ZDl-B).
I rather suspect that if our program had the ability to peer into
7z archives it would have found one of the file types that we now
block, such as .exe files. While
the drizzle was coming in, it was frustrating to sit there with no
visibility inside these 7z archives. I was definitely tempted by
the idea of using one somewhat complicated option to add 7z support to the
program.
I didn't, though. I sat on my hands. And now the drizzle of these 7z-attachment malware emails has gone away (we haven't seen any for weeks now). I'm pretty sure that I made the right decision when I decided on inaction. There are a number of reasons for this, but the narrow tactical one is simply that this format of malware appears to have been temporary (and our commercial anti-spam system was doing okay against it). Waiting it out meant that I spent no time and effort on building an essentially permanent feature to deal with a temporary issue.
(I admit that I was also concerned about security risks in libarchive, since parsing file formats is a risk area.)
It's become my view that however tempting it is to jump to doing something every time I see spam, it's a bad practice in the long run. At a minimum I should make sure that whatever I'm planning to do will have a long useful lifetime, which requires that the spam it's targeting to also have a long lifetime. Adding features in response to temporary spammer and malware behaviors is not a win.
(The other thought is that although some things are technically nifty, maybe there is a better way, such as just rejecting all .7z files. This would need some study to see how prevalent probably legitimate .7z files are, but that's why we're gathering attachment the information in the first place.)
PS: Yes, this malware could come back too; that's why this is only probably the right decision.