KC Lemson

By KC Lemson [MS]

Blogs

Attachment Security, Part Deux

  • Comments 12
  • Likes
Here's Part One. OK this isn't really a continuation of the history, but rather some more rambling on some of what I discussed in part one. I just wanted an excuse to say "Part Deux".
 
After the news reports about the first big email-borne viruses like Melissa started showing up, stories would pop up on Slashdot from time to time that ripped Outlook to shreds. As I mentioned in the footnotes of Part One, I'm all for assigning blame where blame is due when there is a bug in the code or design flaw (like not displaying extensions by default in the shell - oh boy) that results in a security hole, but a lot of the people who ranted incessantly about Outlook's insecurity had obviously never used it, and certainly had no idea how it worked.
 
I hope that these days these misconceptions aren't still around (or as prevalent), but don't keep tabs on this area enough to know for sure. Admittedly, most of these are probably "duhs" for the core audience of this blog, but I do get a wide variety of readers and plus, I think it's an interesting topic (probably because so much of my life was once spent chasing these things down, it's hard to let go). Some of these were also covered a while back on slipstick, but hey, it's my blog, so I'll talk about it some more.
  1. Misconception #1: Outlook opens attachments without user intervention.
    • A lot of people (of the slashdot variety, at least) thought that Outlook's design was to automatically launch attachments when an email was received or opened. No. That would just be silly.
    • Plus, it's so easy to get [enough] people to open a message with simple social engineering techniques ("What? A bill for a pearl necklace? I ordered no such thing!" or "What's this, oh the latest patch from Microsoft to keep me secure, I read how insecure they were in the NYTimes, I better run this to stay safe!"), you wouldn't even need this functionality to spread a virus. Or heck, as Peter mentioned a while back, who even needs social engineering? It's all about the end user, baby. 
  2. Misconception #2: Just tell users not to open attachments from people they don't know and you won't have a problem.
    • First problem with this statement: "Just tell users". I hope we all know by now that user education can only go so far (during the height of the attacks, our corporate security group put pamphlets around the entire campus, the most well-read of these were probably the ones in the elevators and the inside of stalls in the bathrooms). Although software manufacturers still need to do as much as they can to help users make the right decisions and IT administrators need to guide their users as much as possible, user education alone will never solve the entire problem. As Raymond, Eric or Mike can tell you, users are curious creatures and most don't read dialogs anyway. Think about it - do you? One of my favorite quotes from this slashdot thread was this "Most users do NOT want their email to be able to destroy their entire system, and thus would be perfectly happy if said executables ran in a "jail" that couldn't affect the rest of the filesystem without a prompt. "This program is attempting to delete c:\windows\SOMEFILE.EXE, should I allow it to do that? (OK/CANCEL)." As I covered in my first ramble on this topic, popping up dialogs does not a security system make.
    • Second problem with this statement: Only the earliest or the most simple of email-borne viruses could be avoided by this problem. Explore.Zip was the first one I recall that replicated by replying to messages in the users' inbox - ingenious at the time.
  3. Misconception #3: Because unix clients have an executable bit and most mail clients don't set this bit on attachments saved from an email by default, these viruses would never have spread on unix machines.
    • I dug up an old slashdot article where some posters mentioned this. One person posted a [perfectly valid and reasonable] comment that average end-users would open any attachment regardless of file extension, and got many snarky responses such as "Ever heard of something called the 'execute permission bit'?" and "Since in order for this to work you need mail software which treats emails as executable code. Something which is rather specific to Windows apps (and Windows itself.)" I hope that the existence of Bagle and other such viruses stops anyone from thinking that the lack of the executable bit being set by default would prevent many end-users from opening an attachment. Bagle included a password-protected .ZIP attachment, with the password in the message body. If these same users were using linux clients and received an email telling them to "Save greetingcard.exe locally and run chmod 755 greetingcard.exe", they'd do it.
    • Also, as the expansion in virus type over the last few years has shown, it's not just executable filetypes that are the problem. AnnaKournikova.html as an attachment, when opened, has the potential to wreak havoc on a machine - whether that be from an exploit in the HTML rendering engine that results in a buffer overrun or browsing to a phisher's website that pretends to be a porn site that asks for credit cards as validation or heck, who knows, MicrosoftSafetyInstructions.html that tells users they might be infected with a virus if they have a file named ntldr and how they need to delete it.
  4. Misconception #4: Just have a client-side anti-virus scanner installed and you'll be fine.
    • Obviously this is an important part of the solution, but just a part. Many antivirus apps install filesystem filters so that as files are written to the filesystem, the AV app gets notification of their existence (if real-time monitoring is enabled) and can scan the file before releasing it for the rest of the system to use. This is all goodness, but any detection that relies on signatures (and automatic updating of those signatures, and real-time scanning being enabled, and and and...) is always going to lag behind the industry discovery and deconstruction of the culprit, and the subsequent publishing and client updates of those new signatures.
    • More recent versions of the AV apps install network filters as well, another layer in the defense.[1]
  5. Misconception #5: If I'm protected from bad attachments, I'm safe.
    • The existence of HTML viruses and the creation of the phishing industry have knocked this one out of the park. As far as HTML viruses go, the only ones I'm aware of were due to bugs in HTML rendering engines vs "working as expected" behavior, however. But phishing - whoo boy. This is a new avenue entirely and a variety of companies in the industry (including us) are working on technology to help combat it. Plus there are less severe security vulnerabilities like web bugs that let spammers know you read the message (Outlook 2003 & OWA 2003 help protect against this but ultimately it comes back down to the user).
    • The slashdot thread I've quoted a few times has a real doozy on this issue. In response to one person's [perfectly valid and reasonable] comment about how any mailer that renders HTML is at risk, someone said: "Don't be rediculous [sic] here. How can you say that ANY MAILER that renders HTML is vulnerable to an attack? Does that apply to my browser accessing my webmail account? Though Outlook may have some problems here, it is entirely acceptable to believe that a mailer can render HTML emails in a safe and protected way. And the same for Javascript - Javascript can be annoying, but the security holes it has introduced have not been severe. The security problems here are not inherent to HTML and Javascript, they are caused by poor mail clients. It is important to not confuse the problem."
    • Actually, it's quite easy to say that any mailer that renders HTML is vulnerable to an attack. And yes, it applies to browsers accessing webmail accounts. And no, it's not acceptable to believe that a mailer can ever be written to guarantee that it renders HTML email in a safe and protected way. Code is code is code. Mailers by definition display external content. Code has bugs. Bugs can have serious consequences. External content increases the risk of a bug having serious consequences.
  6. I'm sure I'm missing some. If they come to me, I'll write another post. Or feel free to add a comment.
One of the most disturbing comments I've ever seen on slashdot: "Why can't these virus writers do something cool?". Oh boy. I really hope the people who write those kind of comments are still kids with a lot to learn versus engineers in the software industry.

This is an industry problem. We need to solve it with better software, better documentation, better user guidance, better IT pro guidance, legal ramifications and more. We've made huge strides over the last few years but there's still a ways to go if something like Bagel can still be so destructive, as Peter mentioned.
 
[1] These are a great idea in theory, but boy did one of them drive me nuts trying to troubleshoot a problem on my mother's laptop a few months ago. Outlook wasn't able to send mail via SMTP, so I thought I'd "remove Outlook from the picture" and just telnet to port 25 to figure out what was wrong. Every time I did an EHLO I kept getting an SMTP error from Exchange. It didn't repro from any other machine, and I pounded my head against the wall for two hours about this, until I got a big floating lightbulb over my head and checked the AV app options and yep, network scanning was enabled. Disabled it and boom, problem solved. Turned out it was a bug in the AV app.
Comments
  • An interesting read indeed. BTW...the link for part one doesn't work :-(.

    Is sure is humid and hot here in FL this week....ugh.

    Thanks!

  • Hrm, works fine for me... it's from august 04.

  • Good article.

    Did you know your typepad blog is down?

  • What URL are you using for typepad? I'm not having a problem.

  • http://lemson.typepad.com/kc/
    has been sitting in my bookmarks for a while. Also googled you and got the same url. Perhaps I'm just being a bit dim...

  • I know you didn't write this post to rebut them, but Slashdot posters should generally be ignored.

    Nothing cures user apathy about attachments like a good virus infection. After the owner of our company opened an unknown attachment and spread a virus throughout the network, the incidence of people doing that dropped to zero.

    Also, a good Exchange-based attachment blocking by extension filter does wonders. We have been protected from several new viruses before the signatures were updated just by blocking executable attachments at the gateway.

  • Chaz: I saw on that blog that you found the new URL, sorry - I changed 'kc' to 'cynical' as I didn't want people who googled my name to find that one *first*, since they were probably looking for this one instead :-)

    Peter: In general I agree, but it's difficult to ignore ignorance in such cases :-) I totally agree in the effectiveness of simple file-extension-blocking filters, both on the client and server. When we first did the Outlook block for attachments, it seemed like such a major step, to completely block access... now it's a given.

  • Might be a bit late to chime here, but...

    The problem (that I see) with blocking attachments by extension is that it means that ligitimate attachments which are .exe or whatever (it happens, I'll often find some cool tool on the net and forward it 'round to my team mates) means that we need to create "workarounds" like zipping the .exe first.

    But of course, that just conditions users to open a virus in Winzip and run it from there... so then you block .exe-in-.zip files, and ligitimate people have to work around /that/ and that just conditions people to..., and so on.

    It's kind of like that feature in OSX where if you run something that needs admin privileges, it pops up a dialog asking for the password. All that does is condition people to type in their admin password all time and all it takes is someone to create a copy of that dialog in their phishing app, and away it goes!

    (By the way, I don't use OSX so maybe that dialog is just an urban legend, I don't know...)

  • Dare's post about human nature touches on UAC in Vista: How do you design a dialog prompt to warn users

  • PingBack from http://mstechnews.info/2008/10/human-nature-and-email-attachment-security/

  • PingBack from http://blog.hi-tech-sw.net/2008/12/11/human-nature-and-email-attachment-security/

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment