다음을 통해 공유

Attachment Security, Part Deux

  • 아티클

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

  • Anonymous
    January 01, 2003
    PingBack from http://mstechnews.info/2008/10/human-nature-and-email-attachment-security/

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

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

  • Anonymous
    June 05, 2005
    The comment has been removed

  • Anonymous
    June 05, 2005
    Hrm, works fine for me... it's from august 04.

  • Anonymous
    June 05, 2005
    Good article.

    Did you know your typepad blog is down?

  • Anonymous
    June 05, 2005
    What URL are you using for typepad? I'm not having a problem.

  • Anonymous
    June 07, 2005
    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...

  • Anonymous
    June 07, 2005
    The comment has been removed

  • Anonymous
    June 09, 2005
    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.

  • Anonymous
    June 20, 2005
    The comment has been removed