|
Posted by =?Utf-8?B?ZmFsY29uZXJjazE=?= on June 29, 2005, 1:26 pm
If you were Registered and logged in, you could reply and use other advanced thread options
"Bigbruva" wrote:
> Thanks for sharing this, did you happen to find out if they use the same
> scanning engine in there PC-cillin Internet Security suite?
>
> BB
>
> >I spent 3 hours on the phone yesterday with Trend Micro working on a
> >problem
> > that we observed.
> >
> > The short synopsis is that their OfficeScan V7.0 spyware/adware/greyware
> > detection and remediation application is, in my opinion, badly broken and
> > can
> > wreak havoc in an enterprise.
> >
> > OfficeScan corporate edition version 7.0 includes a
> > spyware/adware/greyware
> > detection and cleanup feature. After our upgrade installation of V7.0, we
> > noticed a significant detection rate (~50%) of HKTL_Bruteforce.A,
> > SPYW_Csnoop.A, SPYW_Marketscore.A, and SPYW_Gator, among others. I started
> > looking into these detections and became alarmed at what I found.
> > Searching
> > Trend's website for information on these detections told me that I should
> > be
> > seeing as many as 20 or so different files that has been placed on the
> > supposedly infected machine by the exploit. When I checked the client
> > logs,
> > there was only one file and in some cases a few registry values/keys that
> > had
> > been identified and deleted. Here are some details on the files that were
> > deleted:
> >
> > Bruteforce.A: C:\WINNT\system32\regobj.dll
> > Csnoop.A: C:\WINNT\uninst.exe
> > Marketscore.A: C:\WINNT\system32\sporder.dll
> > Gator: C:\WINNT\system32\wbem\Logs\wmiadap.log
> >
> > I did some more research on these files and found that these were all
> > legitimate system files that were used by other processes and were
> > actually
> > part of our base image. These files are used by VB app runtimes,
> > InstallShield uninstall routines, Winsock LSP chains, and WMI providers
> > and
> > readers.
> > There were also a number of registry keys/values that were deleted during
> > this detection. (most reg entries were in HKLM\software\classes and
> > consisted
> > of guids.)
> >
> > I contacted Trend's customer support to find out why their product was
> > deleting these files without any cross-checking with the virus pattern
> > files
> > to determine if the files being deleted were indeed malicious.
> > Long story short, they don't check. If even one file from the detection
> > definition matches the pattern definition, it triggers the anti-spyware
> > action. This includes legitimate system files.
> > It would be easy to write a spyware app that drops a perfectly legit copy
> > of
> > ntoskrnl.exe or something like that which would then be detected and
> > deleted.
> >
> > I asked Trend if they had a fix for the machines that had had these system
> > files and registry entries deleted. Their answer, after well over an hour
> > of
> > checking, was "you need to copy the files from a good system back to the
> > damaged system. You need to recreate the registry entries by hand as
> > well."
> > They do not have a tool to fix the problems that their app causes. They
> > admitted that this product was broken.
> > They did know about the regobj.dll problem, and had labeled that as a
> > false
> > positive already. They opened a case to look into the additional false
> > positives, since they said their engine shouldn't have done what it did.
> > There is an updated spyware engine and client pattern file available that
> > supposedly prevents the regobj.dll detection, but there's a catch on that.
> >
> > Most of us set our AV apps to update from the manufacturer once per day or
> > once per hour. We then know that our pattern files will be as current as
> > possible.
> > Problem is, the DCS component, which is what performs the automatic
> > updates
> > for the spyware engine (as compared to the AV engine), requires purchase
> > of a
> > different product (the DCS product) in order to be fully operational (as
> > in
> > allowing automatic updates), even though the anti-spyware interface is
> > installed and functional as part of the OfficeScan console install, is not
> > greyed out, and that additional purchase requirement is not documented in
> > their manuals. So, unless I want to purchase their DCS component, I have
> > to
> > manually get the files from Trend each time I want to update, and then
> > manually install them on the server and restart the master service. I can
> > use
> > the anti-spyware component, but can't update it.
> > New buzzword - hostageware.
> >
> > So, to recap, I believe that the spyware detection component of Trend
> > Micro's OfficeScan V7.0 is badly broken. Not only does it not perform
> > detailed inspection of possible spyware, it deletes legitimate system
> > files
> > and registry entries. It also does not allow for automatic updates that
> > could
> > correct this type of problem unless you are willing to purchase another
> > license that isn't mentioned in your admin or installation manual. Oh, and
> > when it does damage your systems, you have to touch each one and fix it
> > manually. No fix tool.
> >
> > Thankfully, we have not yet migrated our servers running Trend's
> > ServerProtect to the recommended OfficeScan product. So far our only
> > effect
> > is on client PCs.
> >
> > I am awaiting further explanations/fixes from Trend on this issue. My
> > recommendation in the meantime is that if you are running Trend OfficeScan
> > v7.0, you inspect your settings to see if you are scanning for
> > spyware/adware/greyware and evaluate whether this scanning method and its
> > ramifications are going to adversely affect your environment. If you are
> > seeing similar actions in your environment, I would contact Trend and ask
> > them why they are using this method to detect spyware and how they are
> > going
> > to fix it.
> >
> > Trend's AV product has been pretty good to us over the years. Their new
> > version, however, specifically the spyware detection app, does not seem to
> > have anywhere near the quality that we are used to from them. The abysmal
> > detection logic and inability of Trend's technical support to adequately
> > address this issue have lead us to begin evaluating other antivirus
> > vendors.
> >
> > Charlie
>
>
>
| 
XML site map