Message-ID: <000901c4c7f9$3c45ad80$668b28c8@administrator>
Date: Thu, 11 Nov 2004 11:17:53 -0300
From: "Jeff Donahue" <jeff@...net.com.uy>
To: "Daniel Milisic" <dmilisic@...ealbox.com>,
   <full-disclosure@...ts.netsys.com>, <bugtraq@...urityfocus.com>
Subject: Re: RE: Norton AntiVirus Script Blocking Exploit -- Symantec's response


Here Symantec, much like Microsoft does very often, prefers to give a silly 
excuse instead of admitting their product needs to be fixed. I agree with 
you in that Script Blocking is supposed to block *any* script-based threats, 
without the need for any signatures. Obviously, that's not the case and 
Symantec won't admit Script Blocking has a hole.

----- Original Message ----- 
From: "Daniel Milisic" <dmilisic@...ealbox.com>
To: <full-disclosure@...ts.netsys.com>; <bugtraq@...urityfocus.com>
Sent: Thursday, November 11, 2004 8:33 AM
Subject: [Full-Disclosure] RE: Norton AntiVirus Script Blocking Exploit --  
Symantec's response


> 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@...antec.com concerning security issues with 
> Symantec products.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html 

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

Powered by blists - more mailing lists