RE: Running renamed executables with CMD.EXE

[Michael Wojcik <Michael.Wojcik () microfocus 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