Win32/Loodok!generic.2 in SYSTEM.DLL - likely false positive

We're getting a plague of these with eTrust (pattern 5723):

[time 22/04/2008 12:54:21: ID 14: machine xxxxx.com: response 22/04/2008 12:54:46] The Win32/Loodok!generic.2 was detected in C:\DOCUME~1\XXXXX\LOCALS~1\TEMP...\SYSTEM.DLL. Machine: XXXXX, User: XXXXX\xxxxx. Status: File was cured; system cure performed.

The subdirectory varies, but it is usually %user profiles%\local settings\temp\ns???.tmp where the question marks indicate a random letter/number. You may find that the subdirectory has vanished by the time you investigate.

This appears to be happening with the installer for Firefox (also tested with Netscape Navigator). You can see the problem if you snooze the AV scanner and then fire up the Firefox installer and leave it running.. the SYSTEM.DLL is clearly there.

Apart from eTrust, VirusTotal gives it a clean bill of health.

You may be seeing this fire off by itself if a software package is autoupdating. I can't identify exactly which installer is in use here, but it is likely to be shared between many other applications.. so expect a storm of these.

As usual with false positives, expect a fix to be issued by CA very soon. The problem seems to be with pattern 5723, so updating to a later virus signature should probably cure it.

Added: Pattern 5724 also reports a positive, but the beta version of 5725 does not. You can download beta signatures from CA here.

Added: 5725 is now available for download as normal, this should cure the problem!

CA PestPatrol false positive - NeoSpy / rarsfx0 directory / WinRAR

Another false positive doing the rounds, this time in CA's PestPatrol software which is incorrectly identifying %profile%\local settings\temp\rarsfx0 as being part of part of the rogue NeoSpy package (see here for CA's description).

In fact, the rarsfx0 directory is just a temporary folder created by RARLAB's WinRAR application - that's a harmless commercial file packager. This folder looks to have been included accidentally in a PestPatrol signature released on 9th January.

Note that if you have PestPatrol installed with the faulty signature, then WinRAR archives may not unpack properly.

eTrust ITM 8.1 fails to update

I've been grappling with a strange problem with eTrust ITM 8.1 for a couple of weeks - the software installs just fine, but the signature updates never apply. The problem occurs on a whole batch of machines that aren't exactly related, but which were all bought in early 2005.

The eTrust Distribution log shows the following:

Completed Time Type Code Description
09-Jan-2008 08:46:11 Information 0 1) Selected component "eTrust Antivirus Arclib Archive Libra...
09-Jan-2008 08:46:11 Information 0 2) Selected component "eTrust Antivirus Base"
09-Jan-2008 08:46:11 Information 0 3) Selected component "eTrust Antivirus Realtime Drivers"
09-Jan-2008 08:46:11 Information 0 4) Selected component "iGateway"
09-Jan-2008 08:46:11 Information 0 5) Selected component "eTrust ITM Common"
09-Jan-2008 08:46:11 Information 0 6) Selected component "eTrust ITM Agent GUI"
09-Jan-2008 08:46:11 Information 0 7) Selected component "CAUpdate"
09-Jan-2008 08:46:11 Information 0 8) Selected component "eTrust PestPatrol Base"
09-Jan-2008 08:46:11 Information 0 9) Selected component "eTrust PestPatrol Clean"
09-Jan-2008 08:46:11 Information 0 10) Selected component "eTrust PestPatrol Engine"
09-Jan-2008 08:46:11 Information 0 11) Selected component "eTrust PestPatrol Realtime"
09-Jan-2008 08:46:11 Information 0 12) Selected component "eTrust PestPatrol Signatures"
09-Jan-2008 08:46:11 Information 0 13) Selected component "eTrust Vet Engine"
09-Jan-2008 08:46:11 Information 0 Checking updates for "eTrust Antivirus Arclib Archive Librar...
09-Jan-2008 08:46:11 Information 0 Downloading from "SERVERNAME:42511"
09-Jan-2008 08:46:09 Information 0 The distribution program started the download process.
Show 10 Show 25 Show 50 Show All Page 1 « ‹ 1-16 of 16 › »

Note that there are always 16 lines in the log.. the update process starts but never completes, and there's no error message.

After working with our reseller we discovered the problem - it's not a problem with eTrust, but instead a very strange permissions issue that has happened with those PCs. What has happened is that the computer's SYSTEM account (which the eTrust services run under) doesn't have access to write to that part of the disk, despite having permissions explicitly set.

In the case of eTrust, the fix is to open up the Services control panel (Start.. Run.. services.msc), and then.

• Double-click on the eTrust ITM Job Service
  
• Click the Log On tab
• Change the credentials from the "Local System account" to the local Administrator account on the PC (i.e. username Administrator, password to whatever you set it to).
• Restart the service
• Either reboot the machine, or terminate the ITMDist service
• Tell the machine to download updates again.

In the cases I have seen, the update works correctly after the Administrator account has been specified. There does seem to be some problem with the SYSTEM service not working properly.

Of course, you can also do this all remotely with the Computer Management tool and something like PSKILL (from PSTools), so you don't have to be sitting at the machine to do it.

As I said, I don't believe that this is an eTrust problem, it looks as though Windows is borked somehow, possibly an issue with SIDs or something. I have a feeling that other software misbehaves, possibly including Active Directory policies. I have no solution other than a complete rebuild, but if you're struggling to get eTrust updating properly, then I would definitely look at the user rights for the service.

CA.com compromised / Zero-day RealPlayer flaw

The ISC reports that several websites have been compromised by a zero-day vulnerability in RealPlayer. The halware is hosted or routed via uc8010.com (currently down).

Surprisingly, one of the compromised web sites (since cleaned up) is ca.com (Computer Associates), who make the eTrust anti-virus product.

A Google search for uc8010.+com site:ca.com comes up with several dozen hacked pages, mostly press releases.



A look at a cached copy of the code shows a link to n.uc8010.com/0.js (don't visit this url) which then loads the exploit.



Note that everything here is a .gif to stop virus scanners freaking out.

To be fair, a lot of sites are compromised including government bodies and large corporations. It just goes to show that there's no such thing as a "safe site" any more.

Js/snz.a - likely false positive in eTrust / Vet Anti-Virus

It appears that CA's eTrust Anti-Virus product (also known as Vet Anti-Virus, often bundled with other security applications such as ZoneAlarm) is coming up with a false positive for js/snz.a for several complex javascript applications.

As far as I can tell, the javascript uses complex encoding but is not malware. These javascript elements are widely used on the web. As far as I can tell, they are not harmful in any way and this is a mis-identification by eTrust / Vet.

The signature that has the problem is 31.3.5417 dated 31/12/07

Some of the Javascript files that seem to trigger an alert are named:

• jquery.js
• mootools.js
• ifx.js
• show_ads.js
• relevancead.js
• submodal.js
• iutil.js
• ifxslide.js

There may be other javascript apps that show the same problem - of course, filenames are arbitary and can be absolutely anything at all.

If you're running Internet Explorer, then you may see an alert for an individual .js file as above, in a Mozilla-based browser (such as Seamonkey or Firefox) you may get a virus alert for a file named something similar to C:\Documents and Settings\USERNAME\Application Data\Mozilla\Profiles\Default\xxxxxxxx.SLT\CACHE\xxxxxxxxxxx

Usually, these false positives are fixed by CA pretty quickly. For most people this should just be a temporary nuisance that will be fixed with the latest virus update.

You can submit suspect files to CA here for analysis, that may well help them to fix the problem.

Follow up: this problem has now been fixed. It turns out that the javascript had been compressed using this packer tool which itself is harmless, but it does appear that the packer has been used for malicious javascript applications in the past as well as legitimate ones. Perhaps the lesson is.. don't pack or obfuscate your javascript!