Re: [Full-Disclosure] RE: Norton AntiVirus Script Blocking Exploit -- Symantec's response

• Previous message: Ulf Härnhammar: "[Full-Disclosure] ez-ipupdate format string bug"
• In reply to: Daniel Milisic: "[Full-Disclosure] RE: Norton AntiVirus Script Blocking Exploit -- Symantec's response"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: "Daniel Milisic" <dmilisic@myrealbox.com>, <full-disclosure@lists.netsys.com>, <bugtraq@securityfocus.com>
Date: Thu, 11 Nov 2004 11:17:53 -0300

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@myrealbox.com>
To: <full-disclosure@lists.netsys.com>; <bugtraq@securityfocus.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@symantec.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

• Previous message: Ulf Härnhammar: "[Full-Disclosure] ez-ipupdate format string bug"
• In reply to: Daniel Milisic: "[Full-Disclosure] RE: Norton AntiVirus Script Blocking Exploit -- Symantec's response"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]