<<< Date Index >>>     <<< Thread Index >>>

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@xxxxxxxxxxxx concerning security issues with Symantec products.