Re: FYI: Are you still looking for an excuse to block executable attachments?

From: Nick FitzGerald (nick_at_VIRUS-L.DEMON.CO.UK)
Date: 01/27/04

  • Next message: Brian Bergin: "Re: FYI: Are you still looking for an excuse to block executable attachments?"
    Date:         Tue, 27 Jan 2004 20:27:30 +1300
    To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
    
    

    Russ wrote:

    > I could tell you about a few really dumb email virus attacks that are
    > attempting to deliver executable attachments, or even better if you
    > really need to show how dumb you can be, executables within zip
    > attachments, but then if you needed to hear about it from me, you
    > probably wouldn't be able to do anything with the info. Granted, there
    > are new members to this list who many not know about such things, but
    > honestly, blocking attachments is really such a basic thing it shouldn't
    > have to be mentioned.
    >
    > The Internet is busy with people who don't get this, what a shame.

    Indeed, and as a result it looks as if some of us (well, some of the
    assembled "you" reading this and many more who aren't) will, come maybe
    2008-2010 (??), end up stuck with computer systems designed in Redmond
    as the (then) modern day version of Orwell's 1984 due to NGSCB and its
    offspring only allowing them to run Redmond-certified software because
    it appears that "we" are too stupid to (safely) use general purpose
    computers.

    > Remember, Anti-Virus doesn't stop viruses, it limits them. ...

    Well, it stops the ones it already knows about...

    > ... Only you can
    > prevent forest fires...so only you're employees who are so clueless can
    > cause them for you.

    ...but, because the use of known virus scanning also requires clue on
    the part of users if you want to prevent outbreaks of new things, it is
    doomed to partial failure if your users are clue-intolerant, and worse
    if they are clue-averse... 8-)

    > Sorry to be harsh, but to see AV people scrambling over this latest wave
    > is, well, pathetic. Here's a thought, take the BadURLs script code I
    > provided to the list at Christmas and modify it to look for attachments,
    > any attachment. Strip the attachment from the email and replace it with
    > a link to a website, but only if the user who the email is going to has
    > an AD attribute that gives them permission to receive such attachment
    > (create attachment groups and populate them, then do an AD lookup to see
    > if the email address recipient is a member of that group, again not
    > rocket science.) If not, just strip and drop the attachment. If yes, put
    > it on a webserver instead of delivering it in email.

    This would probably slow down massive outbreaks such as today's by a
    couple of replication generations at most. That is not enough of an
    edge from which the virus scanners could take a serious advantage. You
    assume that in general there are sufficient clueful folk to make the
    extra effort worthwhile. I'm more skeptical still and feel that your
    final suggestion (drop all attachments) is much more likely to the show
    not only the best ROI, but the only useful return. Of course, you'll
    get the belly-aching, mainly wannabe "power user" crowd demanding that
    you should let such expert users as themselves receive anything, but
    experience of four-plus years of fast self-mailers suggests that in
    reality there simply is not a high-enough density of such users
    anywhere Windows is deployed to dilute the risk.

    > Better still, unzip it (Winzip have an API you know) and then scan the
    > contents for attachment types you're blocking...IOWs, just because its
    > zipped doesn't mean you accept such attachment types from Internet
    > sources. ...

    But be careful to do this "intelligently" otherwise some of those
    massively heavily and/or recursively packed archives can be used to
    trivially DoS one of your mail server's "protective" mechanisms.

    > ... Too bad AV products are too dumb to do this, ...

    That is not the problem. Most AVs (at least, the half-decent ones that
    have dedicated gateway scanner versions) will recursively scan archives
    (to a reasonable depth) and can be set to quarantine anything that
    fails (because it is too deeply packed, "apparently corrupt" and so
    on). The trouble is the admins who have decided that, to appease the
    aforementioned belly-aching, mainly wannabe "power user" crowd, they
    should let .ZIP files pass without scanning or at least let them pass
    so long as they do not contain any known malware. This is the gateway
    scanner equivalent of "opening a hole in your firewall" and tends to
    result in much the same effect when some malcontent finds a way to
    exploit that hole...

    Further, the exploitability of the common ".ZIP hole" in Email gateway
    scanner _implementations_ has been made much easier with the increasing
    inclusion of ZIP (and other) archive handlers in a standard desktop
    configurations, exemplified in XP's inclusion of native .ZIP handling.

    > ... no wonder some
    > malcode writers have chosen to deliver the same old executable inside a
    > zip, they realize it'll get farther than plain attachments (but then
    > again, there was bagle last week.)

    If I understand you rightly, Mydoom is not "the same old executable" --
    is something new and thus the known fallibility of the known-virus-
    scanning approach comes into play. If, however, you meant "the same
    old trick of packaging up an executable" I agree, but as per the above,
    the fact these get through at all tends to be because either clue-
    challenged admins deliberately poke holes in their scanners and other
    policy enforcement devices or they are forced by entirely clue-
    resistant managers to poke such holes because the aforementioned belly-
    aching, mainly wannabe "power user" crowd have more sway over someone
    in management than the security admin has... (Need I remind you of
    your own classic "he can do whatever he wants because he makes $5
    million a week for the bank" example? 8-) )

    > Here's another thought, give Zimmerman his due and don't accept anything
    > that isn't PGP encrypted, first to a common key for your mail server
    > app, then to the recipient!! Wow, what a concept.

    Problematic if you must receive "unbidden" stuff, and odd as it may
    seem, there are many such places out there. Further, the widespread
    lack of suitable code installations makes it an unappealing choice
    (showing just why the aforementioned belly-aching, mainly wannabe
    "power user" crowd isn't...).

    > Ok, all that too much for you? Drop all attachments, plain and simple.
    > Either that or take the computer away from your, um, less than bright
    > users...;-]

    Yep and yep -- that would surely make our work a great deal easier...

    --
    Nick FitzGerald
    Computer Virus Consulting Ltd.
    Ph/FAX: +64 3 3529854
    -----
    NTBugtraq Editor's Note:
    I'm looking for an event at which I can speak in Australia, specifically near Brisbase, as close to Christmas as possible. Anyone interested in flying me down under at that time, please contact me at Russ.Cooper@rc.on.ca
    -----
    

  • Next message: Brian Bergin: "Re: FYI: Are you still looking for an excuse to block executable attachments?"

    Relevant Pages

    • Re: [opensuse] amavisd warning failure?
      ... executable attachments. ... I can't think of a good enough reason to accept executables in a corporate environment:-P ... scan this list mail, for instance? ... Scanninng text only files is very fast, most of the time is spent to actually load the scanner itself. ...
      (SuSE)
    • Re: [opensuse] amavisd warning failure?
      ... daemonized version is faster, so the slower command line scanner should only be used when the daemon is unavailable. ... After all, this is linux and I have no use for executables, even if bona fide;-) ... Scanninng text only files is very fast, most of the time is spent to actually load the scanner itself. ...
      (SuSE)