Sponsored by..

Showing posts with label False Positive. Show all posts
Showing posts with label False Positive. Show all posts

Saturday 14 March 2015

Quttera fails and spews false positives everywhere

By chance, I found out that my blog had been blacklisted by Quttera. No big deal, because it happens from time-to-time due to the nature of the content on the site. But I discovered that it isn't just my blog, but Quttera also block industry-leading sites such as Cisco, VMWare, Sophos, MITRE, AVG and Phishtank.

For example, at the time of writing the following domains are all blacklisted by Quttera (clicking the link shows the current blacklisting status):

www.cisco.com
www.vmware.com
cve.mitre.org
www.auscert.org.au
www.phishtank.com
www.buzzfeed.com
www.reddit.com
dl.dropbox.com
www.avg.com
www.malekal.com
nakedsecurity.sophos.com
blog.dynamoo.com
malware-traffic-analysis.net
blog.malwaremustdie.org

Cisco's blacklisting entry looks like this:

Now, you can ask Quttera to unblacklist your site for free by raising a ticket but the most prominent link leads to a paid service for £60/year. Hmmm.

I don't think that I will rush to subscribe to that. Obviously, something is seriously wrong with the algorithm in use, some of these sites should obviously be whitelisted. Quttera also doesn't understand the different between a malicious domain or IP being mentioned and such a site being linked to or injected into a site.

I guess there are many, many more domains that are in a similar situation. Perhaps you might want to check your own web properties and share your findings in the comments?

Monday 24 June 2013

www.public-trust.com false positive at Phishtank

public-trust.com houses Certificate Revocation Lists (CRLs) and is controlled by Verizon. It probably houses other certificate infrastructure too, but at the moment several web filtering systems are detecting it as a phishing site due to a false positive at Phishtank.

Some example URLs (which are perfectly safe) include:
http://www.public-trust.com/cgi-bin/CRL/2018/cdp.crl
http://cdp1.public-trust.com/CRL/Omniroot2025.crl

The problem with the website at www.public-trust.com is that it forwards to www.verizonenterprise.com (a perfectly legitimate Verizon site), but this does make it look a bit like a phishing site. This is the false positive at Phishtank.

At least one person seems to have spotted that it wasn't a phish, but it's quite an easy mistake to make because the screenshot of a Verizon site combined with the very non-obvious domain name makes it look extremely phishy.

For the records, these are the WHOIS registrant details:

Verizon Business Global LLC
Verizon Business Global LLC
One Verizon Way
Basking Ridge NJ 07920
US
domainlegalcontact@verizon.com +1.7033513164 Fax: +1.7033513669

The domain was created in 2002 (most phishing sites don't even last a few weeks) and is hosted on 64.18.30.10 (Verizon Business Global, LLC). At the moment the false positive is in Phishtank, AVGThreatLabs, SURBL and MyWOT blacklists plus anything downstream that uses that data.

Thursday 19 November 2009

Avira detects TR/Crypt.XPACK.Gen in MW2

I don't play Modern Warfare 2 - but some reports indicate that it has a virus in it.

What seems to be happening is that Avira is coming up with a generic detection of TR/Crypt.XPACK.Gen on a temporary file (perhaps ~B8.tmp) in C:\Documents and Settings\%USERNAME%\Local Settings\Temp.

However, "TR/Crypt.XPACK.Gen" is a generic detection - Avira is scanning the file and determining that it might be suspicious because it has been compressed with a commercial packer (a bit like a ZIP file). It is almost definitely a false positive that will be fixed quite soon.

If you like, you can head to the Avira Support Forums although where there is a short thread about it.

Wednesday 12 August 2009

CA eTrust goes nuts with StdWin32 and other false positives

CA eTrust ITM has gone completely nuts today, with a load of seemingly random false positives mostly for StdWin32 in a large number of binaries, including some components of eTrust itself.

The core problem seems to be a signature update from 31.6.6672 to 33.3.7051, there seems to be little consistency in what is being detected as a false positive although there are multiple occurrences of Nokia software, VNC and event DLLs and EXEs belonging to eTrust's core components.

Probably the best thing to do is block the update or change the Realtime scanning behaviour to "disabled" or "report only".

Update: problem seems to have started at about 0525 GMT when the new signature pattern applied. There no consistent pattern to the infected files, it looks like it happens at random. Several other people seem to be having the same issue!

Update 2: Signature pattern 34.0.6674 appears to fix this problem. You can then enjoy repairing your faulty machines.. thanks CA!

Update 3: Amusingly, CA eTrust seems to have deleted its own key components in many cases. I don't know if this is the first recorded case of an anti-virus application mistaking itself as malware!

Update 4: CA have released a statment as follows:

Last night, CA released a new updated antimalware engine. This new release has resulted in false positive detections of a number of files. CA Threat Manager customers are the only customers being affected by this issue. This is not a result of signature updates and does not impact CA consumer Internet security products.

To resolve the issue, CA has rolled back the new engine and re-released its previous antimalware engine. CA customer support representatives are on call to answer customer questions and to provide remediation support. A remediation tool to rename the quarantined files is now available through CA support and will soon be accessible online.

CA is aggressively working to resolve the issue, assist any customers who have been affected, as well as identify the root cause of the incident. We apologize for this inconvenience and look forward to the roll out of our new antimalware engine, which will ultimately offer our customers many benefits including enhanced malware protection and improved performance.

Update 5: Got a mention on El Reg.. funny thing is that I went in to work today wearing my El Reg T-Shirt. Coincidence? Consiparacy? Cockup?

PS: Please remember to read the comments if you are still having problems!

Friday 20 February 2009

CA eTrust woes, Win32/Tnega.AC and widespead update failure

CA eTrust has thrown up a couple of problems - first a false positive identifying Win32/Tnega.AC in the setup.exe for Office 2000 Professional, with signature version 31.6.6361.0.

However, when having a poke at this it turns out that the current version is 31.6.6367 and 6361 is a few days old. A check of our distribution servers show that every single one of them worldwide failed to download version 31.6.6362 from the CA servers and fell over. This happened at around 2245 GMT on 17/2/09.

Log files are showing the following error: Error [0xc0010003] initializing redistribution job.

If you are running CA eTrust ITM, then it's worth checking that your signatures are up-to-date.

Friday 13 February 2009

BitDefender: Trojan.Generic.1423603 in winlogon.exe

This looks like a false positive: BitDefender is reporting Trojan.Generic.1423603 in C:\windows\system32\winlogon.exe. This name is sometimes used by malware, but in this case no other product is detecting anything malicious.

Current pattern is for BitDefender is 2640654, pushed out on Friday 13th February (!).

I will post the ThreatExpert prognosis when I get it.. in the mean time I would suggest that you do NOT try to remove winlogon.exe as you will render your system unbootable. (NOTE: Do NOT reboot your machine as this will most likely break it!)

Update: ThreatExpert indicates that it is clean. Several comments confirm that it is a false positive. The problem seems to be on Windows XP SP3, SP2 does not seem to have the same issue. The MD5 for this file is ed0ef0a136dec83df69f04118870003e

It seems that there are several reports at the BitDefender forum. I would guess that BitDefender are aware of the problem, temporarily disabling the anti-virus scanner may be a good idea else your system may become unusable. Usually these issues are fixed in 24 hours.

Update 2:
If you can't get the winlogon.exe out of quarantine, then this is a copy of the original (English US) file for XP SP3. Use at your own risk - password is "bitdefender".
winlogon_xpsp3.zip

Wednesday 10 September 2008

PestPatrol: SillyDl FFL in wuauclt.exe

It looks like CA PestPatrol might have a false positive, detecting SillyDl FFL in C:\windows\system32\wuauclt.exe. This is a component of Windows Update, and in the case of the false positive it is a 124,184 byte file with an internal version number of 5.8.0.2469.

PestPatrol does not appear to be trying to delete the file, it is merely blocking access to it. Updating your Windows Update components should clear the problem. CA usually fix these false positives in a day or so.

The current signature version is 2008.9.9.15. Note that the PestPatrol engine is used in some other products, not all of which have the CA name on them.

Wednesday 30 July 2008

PestPatrol: Zuten detected in c:\windows\minidump

This one looks like a false positive.. CA PestPatrol with signature version 2008.7.29.15 seems to be detecting Zuten in the c:\windows\minidump folder.

A close examination of the description indicates that the following files may be being misdetected:

%windows%\minidump\mini072908-01.dmp
%windows%\minidump\mini072908-02.dmp
As you can see, yesterday's date in encoded into the .dmp files. If your computer system has generated a .dmp file in the past day, then PestPatrol may well be mis-detecting it.

Tuesday 22 April 2008

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!

Monday 14 January 2008

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.

Thursday 3 January 2008

JS/Exploit-BO false positive in McAfee

In what looks like a re-run of a recent false positive from eTrust, McAfee Anti-Virus is detecting JS/Exploit-BO in a number of innocent javascript applications, including Mootools. It's likely that McAfee is detecting the Dean Edwards Packer Tool as malware, although that's just an innocent application. Pattern 5197 has the problem, upgrading the signatures to pattern 5198 or later should fix it.

Unfortunately I guess this goes to show that packer tools can be a menace. There have been reports of this tool being used to obfuscate malware, so the smart advice to javascript developers is probably to not encode, compress or encrypt your code in any way if you want it to be trusted.

Monday 31 December 2007

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!