RE: Norton AntiVirus Script Blocking Exploit -- Symantec's response

[Daniel Milisic <dmilisic () myrealbox com>]

Hello,

This is regarding my post on FD from a couple of days ago:
Unfortunately it got bounced by Bugtraq.

Norton AntiVirus 2004/2005 Scripting Vulnerability Pt.3
http://seclists.org/lists/fulldisclosure/2004/Nov/0160.html

I slapped together a flash movie of the NAV Vulnerability in action so 
anyone interested can see for themselves without trashing a machine:

http://64.5.53.205/navdemo.html (1.2MB, Flash plugin red'd; vnc2swf)

This is a show featuring Norton AntiVirus getting deactivated and Script 
Blocking uninstalled by the VBScript code from my FD post.  I don't have 
the bandwidth to host this file for long so if anyone wants to mirror 
feel free to do so.  It was done on a slow VM and the WinXP splash 
screen takes a little while post-reboot so be patient, it's worth the wait.

You'll see that Script Blocking gets *completely* uninstalled.  As well, 
notice that Auto-Protect doesn't kick in until you click on the tray 
icon and launch the NAV console.  By then, the 'Virus' had already 
launched quite some time before, as you can see in the cmd.exe window.

Symantec's response goes something like:  Yes, the exploit works but you 
have to be an administrator.  That's ridiculous!  Any customer who 
purchased Norton AntiVirus for their XP Home/Pro computer almost 
certainly *is* logged in as an Administrator.  And in those situations, 
Script Blocking does a good job in blocking malicious JScript and 
VBScript...  but *not* WMI in a .vbs (VBScript) file.

Now, this shouldn't come as a surprise to anyone (especially Symantec), 
but NAV is aimed at the Home/SOHO market.  By default, in the Windows XP 
OOBE (Out Of Box Experience) a Windows user *is* an administrator!  So, 
the users of this product already meet the "administrator rights" 
requirement nicely.  If the rare conscientious/paranoid user wanted to 
run with as a "Limited" User account, they would see how poorly NAV's 
update mechanism handles this scenario, so it's ironic and amusing they 
have chosen to take this position.

Symantec tells users that "Script Blocking" is there to protect users in 
case they do something silly or get phished into running a script. 
There isn't any fine print and it's a blanket statement.  The thing is, 
I demonstrated that Script Blocking doesn't protect the customer like it 
says it does.  This is the whole point -- Script Blocking does not work 
as advertised.  It's trivial for a Bad Guy to script around the 
limitations ScriptBlocking sets on the Windows Scripting Host.  It's a 
joke.

Regarding the signature detection; my demonstration code is one of many 
methods to wreak havoc using WMI.  No, I will not point out all of them 
but my second FD post illustrates this... it's like plugging a hole in a 
dam.  There are many ways to spin WMI to evade signature detection and 
accomplish the same goal.

To summarize, I feel Symantec's response to this issue is disingenuous 
at best, and misleading at worst.  In the end customers will either call 
them on it, or keep drinkin' the Kool-Aid... but at least the issue's 
out there for them to decide.

Best Regards,
Daniel Milisic

______________________________________________________________



Symantec is responding to a posting and an article that ran on public 
Web sites on November 3, 2004.  The author of the article stated that 
his source, the poster, was able to create a VBS script that caused a 
minor denial of service by terminating the system tray icon for Symantec 
Norton AntiVirus as well as preventing the Auto-Protect pop-up alerts 
from displaying on the user’s system.

Symantec would like to reiterate that the situation described is one of 
access rather than threat. The VBS scripts described can only be 
successfully run on the target system with administrator rights. To get 
a malicious script on a targeted system, the attacker requires “user 
assistance” by either enticing the targeted user to visit a location 
where the malicious file could be downloaded or have access to the 
target system to upload or transfer the malicious file.

Script blocking, which is a function of Symantec Norton AntiVirus, 
assists its signature- based detection in identifying malicious scripts. 
The VBS script that has been referred to in the latest posting requires 
action on the part of an administrator to have any affect on the target 
system and to avoid detection by the script-blocking module. It should 
be noted however that signature-based detection is still functional. In 
the event that malicious code were to be created from this VBS script, 
Symantec would simply add a signature to its virus definitions and the 
threat would be eliminated. Symantec’s Security Response routinely 
updates virus definitions daily.

As a part of normal user best practices, Symantec highly recommends a 
multi-layered approach to security.
·        At minimum, run both a personal firewall and antivirus 
application with current updates to provide multiple points of detection 
and protection to both inbound and outbound threats.
·        Keep vendor-supplied patches for all application software and 
operating systems up-to-date.
·        Exercise caution when visiting unknown/untrusted websites or 
opening unknown URL links.
·        Do not open unidentified attachments or executables from 
unknown sources or that you didn't request.
·        Always err on the side of caution. Even if the sender is known, 
the source address may be faked.
·        If in doubt, contact the sender to confirm they sent the 
attachment and why before opening the attachment. If still in doubt, 
delete the attachment.
·
Symantec takes the security of our products seriously and is a 
responsible disclosure company.  You can view our response policies at 
http://www.symantec.com/security.
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.

Please contact secure () symantec com concerning security issues with 
Symantec products.

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