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.