Re: Running renamed executables with CMD.EXE

From: Michael Wojcik (Michael.Wojcik_at_MICROFOCUS.COM)
Date: 08/24/04

  • Next message: Russ: "Re: Odd SP2 Behavior"
    Date:         Tue, 24 Aug 2004 07:13:27 -0700
    To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
    
    

    > From: Geoff Vass [mailto:geoff@cadzow.com.au]
    > Sent: Saturday, 21 August, 2004 07:43
    >

    [Your messages would be easier to read if you kept them to a reasonable line
    length.]

    > A while ago I "discovered" that CMD.EXE would launch renamed
    > executables. I
    > felt that this was a security problem because until fairly
    > recently most
    > virus scanners would be checking .exe, .com, .pif etc for
    > viruses but would
    > not bother scanning .txt files,

    What's "fairly recently"? If Symantec (not, IMO, the world's greatest
    security products) is typical, then this hasn't been a problem for a while.
    According to the Symantec KB, their anti-virus products since at least NAV
    2000, except for NAV 2001, scan all files by default.[1] And while NAV 5.0
    scanned only "program files" by default, at least as far back as November
    1999 Symantec had KB articles explaining (for the daft) how to configure it
    to scan all files.[2]

    > and of course email
    > attachment filtering
    > would not generally block a .txt file.

    The only email attachment filtering that works worth a damn is common sense.
    People who are "protected" from evil attachments by filtering will fall to
    social engineering attacks such as phishing.

    > Coincidentally, shortly after MS issued KB811528 which says
    > that CMD.EXE
    > looks at the header of the file and because it is an
    > executable, executes it
    > and that you should only run code from trusted sources (blah
    > blah blah).

    MS products have been ignoring metadata for years. It's well known that IE
    attempts to determine disposition from content rather than from the HTTP
    headers.

    I suppose this makes it all the more ironic that MS is now pushing another
    metadata "security" scheme, with the file zone ADS. But really there's
    nothing new here and nothing particularly exciting.

    > But the real issue to my mind is that if you are a hacker and you have
    > infiltrated a system a great way to hide your malcode would
    > be to rename it
    > all to .txt or .tmp and launch it when required using "cmd /c
    > malcode.tmp".

    This is only great insofar as you're dealing with an incompetent
    administrator; under that assumption, there are plenty of other
    opportunities.

    To put it in more formal terms, you're worrying about pruning a rather small
    branch of the attack tree. There just aren't going to be many (if any)
    attacks which depend solely on the capability of cmd.exe to process files
    based on content inspection.

    > But if you have
    > ever tried to
    > clean an infected system or look for a possible compromise
    > you know the
    > first thing you are looking for is funny .exe files.

    No, that's not the first thing I do. Perhaps your procedures need an
    update?

    > I think it's a problem because we have a section of the
    > operating system
    > that behaves totally counter-intuitively, considering that
    > every other part
    > of the operating system looks at the file extension and not
    > the contents.

    Simply not true; IE is the most prominent example, but it's not the only
    one.

    > And now we have this new functionality in the shell which
    > remembers which zone a file was downloaded from and prompts
    > you according to
    > its safety level yet CMD.EXE totally ignores it.

    Not a big deal, since the file zone ADS isn't worth the bytes used to store
    it.

    > And this
    > from a company
    > that went so far as to alter the DLL search order behaviour
    > to block certain
    > types of DLL spoofing, which is another obscure type of
    > attack that assumes
    > the malcode is already in your system.

    If interpositioning is an "obscure" attack, then I think cmd's behavior is
    not your greatest worry. Interpositioning should be completely obvious to
    anyone with any degree of security training and understanding of Windows;
    and anyone without security training has already lost the fight by the point
    where an attacker can create files on the target.

    > So considering all the tweaking that took place in Windows XP
    > for SP2 it's a
    > bit peculiar that this obscure and counter-intuitive
    > behaviour has remained
    > intact.

    "Intuitive" is what the user expects - no more and no less. File extensions
    as metadata that determines disposition is not a universal mechanism among
    OSes. It might be "intuitive" to people who used MS-DOS and older versions
    of Windows, but it's not intuitive for Unix users, for example, and there's
    no reason it should be for people who start with XP. (And it doesn't even
    translate to, say, people using MVS via TSO and ISPF, where you might exec a
    CLIST or submit JCL, but you don't go creating programs that look like OS
    commands.) Ditto "obscure".

    I'm not saying that cmd's content-inspection execution heuristics are good,
    mind you; in fact I think that's a fairly stupid idea, particularly when
    carried to excess, as it has been. I think the Unix model (where only a few
    magic numbers are recognized, and the rules are well-known) is a decent
    compromise, and the old MS-DOS model (where there are strict execution rules
    based solely on filename metadata, ie extensions) was clumsy but workable.
    But I don't believe it's a huge threat; I think a formal model (such as a
    well-drawn attack tree based on a reasonable threat model) would show you
    that it's not; and I don't think "fixing" it is the right way to go, since
    there's little to gain and potential compatibility issues.

    1.
    http://service1.symantec.com/SUPPORT/nav.nsf/df0a595864594c86852567ac0063608
    c/4978f97c99d2fa7b8825690d008012d6

    2.
    http://service1.symantec.com/SUPPORT/sunset3.nsf/4a466c543a83dec985256c92005
    cb9ae/2154e3ea5303ddbf85256c92005b5ce9

    --
    Michael Wojcik
    Principal Software Systems Developer, Micro Focus
    -----
    NTBugtraq Editor's Note:
    Want to reply to the person who sent this message? This list is configured such that just hitting reply is going to result in the message coming to the list, not to the individual who sent the message. This was done to help reduce the number of Out of Office messages posters received. So if you want to send a reply just to the poster, you'll have to copy their email address out of the message and place it in your TO: field.
    -----
    

  • Next message: Russ: "Re: Odd SP2 Behavior"

    Relevant Pages

    • RE: Running renamed executables with CMD.EXE
      ... security products) is typical, then this hasn't been a problem for a while. ... branch of the attack tree. ... no reason it should be for people who start with XP. ... I'm not saying that cmd's content-inspection execution heuristics are good, ...
      (Bugtraq)
    • Re: Offsite JSP
      ... I don't see any reason why you should be attacked ... not looking for my sorts of statements, ... potentially attack. ... "People think of security as a noun, ...
      (comp.lang.java.programmer)
    • Re: Firewall Necessity
      ... One good reason to run a firewall. ... > which a multitude of compromised systems attack a single target" ... > millions of dollars in lost productivity and security expenditures. ...
      (microsoft.public.windowsxp.network_web)
    • Re: Firewall Necessity
      ... One good reason to run a firewall. ... > which a multitude of compromised systems attack a single target" ... > millions of dollars in lost productivity and security expenditures. ...
      (microsoft.public.windowsxp.help_and_support)
    • Re: "Local" and "Remote" considered insufficient
      ... > attack (one system, many systems, trusted systems, same physical wire, ... The "underlying nature" to all Vulnerabilities is a question of "Human ... attacker -- so YES, Social Engineering, Policy Oversight, and even Security ... Consequence -- the coding and actions required from the point of execution ...
      (Vuln-Dev)