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.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html