Chris Mosby at myITforum.com

Symantec accused of using 'scareware' tactics to sell full-version products

By Zack Whittaker | January 11, 2012, 6:05am PST

Summary: Anti-virus maker Symantec is charged in a lawsuit with misleading users into purchasing full versions of its software by peddling ’scareware’ tactics.

Security firm Symantec is being taken to court over claims that the company’s flagship anti-malware and performance software suites mislead consumers into buying full versions of its products.

The suit, which seeks class action status, was brought by Washington state resident James Gross. It was filed in the District Court of San Jose, California on Tuesday on behalf of his lawyers, according to Reuters.

The complaint alleges that misleading ’scare’ tactics are being used by Symantec in its Norton Utilities, PC Tools Registry Mechanic, and PC Tools Performance Toolkit products. The claims also suggest the software range always report harmful errors, privacy risks and other issues that exist, regardless of whether they actually exist.

Many ’scareware’ tactics used by online scammers intercept websites and display within the browser a simulation of an anti-virus scan, that invariably tells the user that the PC they are using is infected.

“The software is falsely informing the consumer that errors are high priority and in addition it is falsely informing the consumer that their overall system health and privacy health is low”, the complaint stated.

“The truth, however, is that the scareware does not actually perform any meaningful evaluation of the user’s computer system, or of the supposed ‘errors’ detected by the software”.

One analyst said that the claims would be difficult to prove. Andy Kellett, senior analyst at Ovum, said speaking to The Inquirer: “It’s a tricky one as there are lots of unknowns, how do you prove Symantec is in the wrong?”, adding: “It’s not something that has been done before”.

The news comes only a week after Symantec confirmed an Indian hacker group hacked a “third-party” and acquired source code relating to an enterprise anti-virus solution the company once offered.

While the lawsuit will likely go Symantec’s way, it is nevertheless been a bad month for the security firm.

A Symantec spokesperson said it was “aware” of the allegations made, but declined to offer additional comment at the time of publication.

More information on MS12-004
swiat
10 Jan 2012 10:10 AM

This month we released MS12-004 to address CVE-2012-0003 and CVE-2012-0004.

CVE-2012-0003

The most severe of these vulnerabilities is CVE-2012-0003 which is a Critical, Remote Code Execution vulnerability. This CVE affects all editions of Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. Windows 7 is not affected by this vulnerability.

An effective workaround for CVE-2012-0003 is to disable Directshow’s MIDI parsing. Apply the following registry file would unregister the MIDI parser in Directshow.

Windows Registry Editor Version 5.00
[-HKEY_CLASSES_ROOT\CLSID\{D51BD5A2-7548-11CF-A520-0080C77EF58A}]

CVE-2012-0004

CVE-2012-0004 is an Important-class vulnerability also involving Windows Media Player. The vulnerability in the closed caption decoding component (L21 decoder) is contained within DirectShow. Therefore, the multimedia applications that leverage DirectShow to decode closed caption streams might be affected.

As a mitigation, the latest WMP player, WMP12, has closed caption turned off by default. As shown in the below picture, the setting to display close caption content is disabled. Therefore, WMP12 users are not affected by this vulnerability by default.

Summary

MS12-004 is our top-priority bulletin for January 2012; though the mitigation described above is effective and we have seen no exploitation attempts against either of the CVEs covered, we recommend that customers apply the bulletin as soon as possible.

Special thanks to Jeremy Tinder in MSRC and Ali Rahbar in MSRC Engineering.

- Chengyun Chu, MSRC Engineering

More information on the impact of MS12-001
swiat
10 Jan 2012 9:43 AM

Today we released MS12-001, which addresses an issue that can enable an attacker to bypass a defense in depth feature known as SafeSEH. This bypass is limited in scope to applications that make use of binaries that were built with Microsoft Visual C++ .NET 2003 RTM. Binaries that have been built with Microsoft Visual C++ .NET 2003 Service Pack 1 and beyond are not affected. In this blog post we wanted to provide more details on the issue that has been addressed and what impact it has. In addition, we’ll clarify the parameters of the “Security Feature Bypass” vulnerability category assigned to this bulletin.

What is SafeSEH?

SafeSEH is a defense–in-depth security feature that is designed to make it more difficult for attackers to exploit certain types of vulnerabilities. In particular, SafeSEH is designed to prevent attackers from using an attack technique known as an “SEH overwrite”. More details on how this is accomplished can be found in a report we released in July of last year: http://go.microsoft.com/?linkid=9776900.

Microsoft released support for SafeSEH in Visual Studio 2003 RTM. Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1 were the first versions of Windows to be built with SafeSEH enabled.

What issue is being addressed?

This issue can result in SafeSEH not being enforced for a binary that has been built with support for SafeSEH. This occurs when a binary that was built with Microsoft Visual C++ .NET 2003 RTM is loaded by an application running on a version of Windows that is affected by MS12-001.

The reason that SafeSEH is not enforced in this scenario is because Microsoft Visual C++ .NET 2003 RTM produces binaries with metadata that is a different size than what the Windows loader expects. As a result, the loader conservatively falls back to assuming that the binary does not support SafeSEH. MS12-001 addresses this issue by allowing binaries to have metadata of the size that is produced by Microsoft Visual C++ .NET 2003 RTM.

What impact does this issue have?

Failing to enforce SafeSEH for a binary can enable an attacker to more easily develop an exploit for a vulnerability. The attacker must have found a vulnerability that can enable code execution for this to be possible; the issue addressed by MS12-001 does not enable code execution in and of itself. Furthermore, it does not enable elevation of privilege, information disclosure, or the like. For this reason, we’ve assigned MS12-001 to the very small category of “Security Feature Bypass” vulnerabilities. Though failure to enforce SafeSEH is by no means desirable, the issue in itself does not constitute an exploit vector.

Although the set of binaries affected by this issue is limited, some of the affected binaries are extensively used by applications. For example, the redistributable C runtime DLLs (such as msvcrt.dll) from Visual Studio 2003 are affected by this issue. These DLLs also do not enable support for ASLR and are therefore an attractive target for use in developing an exploit. EMET can be used to better mitigate these concerns by enabling mandatory ASLR and SEHOP for applications that make use of such DLLs.

Do I need to rebuild my binaries if they were built with Visual C++ 2003?

Installing the update for MS12-001 will fully address this issue without requiring any binaries to be rebuilt. Alternatively, this issue can also be resolved by rebuilding affected binaries with Microsoft Visual C++ .NET 2003 Service Pack 1 or later. You can determine if your binary is affected by this issue by using the Microsoft Visual C++ linker command “link.exe /dump /headers binary.dll”. Binaries with a Load Config Directory size of 0x48 are affected as shown below.

File Type: DLL
7.10 linker version
…
100000 size of heap reserve
1000 size of heap commit
0 loader flags
10 number of directories
3AC74 [ 43E0] RVA [size] of Export Directory
49298 [ 28] RVA [size] of Import Directory
52000 [ 3B8] RVA [size] of Resource Directory
0 [ 0] RVA [size] of Exception Directory
0 [ 0] RVA [size] of Certificates Directory
53000 [ 2B64] RVA [size] of Base Relocation Directory
39B48 [ 38] RVA [size] of Debug Directory
0 [ 0] RVA [size] of Architecture Directory
0 [ 0] RVA [size] of Global Pointer Directory
0 [ 0] RVA [size] of Thread Storage Directory
49078 [ 48] RVA [size] of Load Configuration Directory

Thanks to Gerardo Di Giacomo and our colleagues in Windows Sustained Engineering for their work on addressing this issue.

Matt Miller, MSEC Security Science

Symantec is investigating claims by a group of hackers that they are in possession of source code for its Norton AntiVirus (NAV) product.

The group, which uses the name "The Lords of Dharmaraja," claims to have stolen Symantec source code and documentation from the servers of Indian intelligence agencies, along with intellectual property from other software companies that have contracts with the Indian government.

"As of now we start sharing with all our brothers and followers information from the Indian Military Intelligence servers," the group said in a Pastebin post on Wednesday. "So far we have discovered within the Indian Spy Programme source codes of a dozen software companies which have signed agreements with Indian TANCS programme and CBI."

The original post has been deleted from Pastebin but was still available in Google's cache. It contains a draft document describing API (application programming interface) procedures for Symantec's virus definition generation service.

According to Symantec, the leaked documentation dates back to April 1999 and is no longer relevant for its current systems.

"This document explains how the software is designed to work (what inputs are accepted and what outputs are generated) and contains function names, but there is no actual source code present," said Cris Paden, Symantec's senior manager of corporate communications.

"The information in the 1999 document has no bearing or impact on our current products, i.e., the information in the document cannot be used to impair or corrupt our current solutions," Paden added.

The hackers also said that they are in possession of source code for Norton AntiVirus, which they plan to release at a later time. "We are working out mirrors as of now since we experience extreme pressure and censorship from US and India government agencies," the group said in their Pastebin post.

To substantiate their claim, The Lords of Dharmaraja made a second post on Pastebin with a listing of files allegedly contained in the Norton AntiVirus source code package.

Symantec could not confirm whether the file listing corresponds to its source code.

"A second claim has been made by the same group regarding additional source code and we're currently investigating that. For that one, we don't have any information to provide as of yet," Paden said.

It remains to be seen if The Lords of Dharmaraja will release any actual files and what version of Norton AntiVirus, if any, will be affected. If it's current enough, the code could potentially provide malware writers with the knowledge required to evade detection, and could give Symantec's competitors an inside look into the company's technology.

If the leak turns out to be real, Symantec wouldn't be the first antivirus vendor to deal with such an incident. In January 2011, the source code for an older version of Kaspersky Antivirus was uploaded to a torrent site. The intellectual property was stolen in early 2008 by a former Kaspersky employee who attempted to sell it on the Internet. He received a three-year suspended prison sentence in Russia.

January 2012 Microsoft Black Tuesday Summary

0 comment(s)

MS11-100 DoS PoC exploit published
Published: 2012-01-09,
Last Updated: 2012-01-09 19:21:27 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
Rate this diary:

0 comment(s)

If you have not patched yet for vulnerability MS11-100 you might want to do it ASAP, because the DoS PoC exploit for this vulnerability has been published two days ago.

More information about the vulnerability and patches at http://technet.microsoft.com/en-us/security/bulletin/ms11-100

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org