Cenzic 232 Patent
Paid Advertising
web application security lab

Malware Uses Browser Plugin Sniffing

Similar to Mr T, Łukasz Pilorz sent me a link to some malware that is actually doing browser sniffing. This was something we had thought was probably going on, but it was more of a theoretical attack. Now it’s clear it is actually being used in the wild. The interesting part of the code reads as follows:

if (win && ie) {
xd = _hwaPlugIE("SWCtl.SWCtl.1") ? "1" : "0";
sf = _hwaPlugIE("ShockwaveFlash.ShockwaveFlash.1") ? "1" : "0";

if (_hwaPlugIE("PDF.PdfCtrl.1")) pdf = "1";
if (_hwaPlugIE('PDF.PdfCtrl.5')) pdf = "1";
if (_hwaPlugIE('PDF.PdfCtrl.6')) pdf = "1";

qt = _hwaPlugIE("QuickTimeCheckObject.QuickTimeCheck.1") ? "1" : "0";
rp = _hwaPlugIE("rmocx.RealPlayer G2 Control.1") ? "1" : "0";
wm = _hwaPlugIE("MediaPlayer.MediaPlayer.1") ? "1" : "0";
} else if (!win || moz) {
for (var i=0; i < n.mimeTypes.length; i++)
_hmime += n.mimeTypes[i].type.toLowerCase();

xd = _hwaPlugMoz("application/x-director") ? "1" : "0";
sf = _hwaPlugMoz("application/x-shockwave-flash") ? "1" : "0";
pdf = _hwaPlugMoz("application/pdf") ? "1" : "0";
qt = _hwaPlugMoz("video/quicktime") ? "1" : "0";
rp = _hwaPlugMoz("audio/x-pn-realaudio-plugin") ? "1" : "0";
wm = _hwaPlugMoz("application/x-mplayer2") ? "1" : "0";
}

You can download the entire source here. It’s pretty interesting code, if you haven’t seen it before. Clearly it’s malicious so be careful about executing it, since it does use full paths. Interesting though. Thanks to Łukasz!

4 Responses to “Malware Uses Browser Plugin Sniffing”

  1. Aviv Raff Says:

    This is actually not the malicious section of the website.
    This JS is part of an installation of a web statistics tool that can be freely downloaded from http://statcounter.com/

    What we can clearly see here is the use of web analytics tools by malicious websites in order to map their victims.

  2. lpilorz Says:

    Yes, you are right, I did not check if this exact part was malicious, but saw this script included on a page that installed a trojan. This page was in turn put into an iframe, injected in the php source of a vulnerable page. Those techniques were already described, e.g. in “The Ghost in the Browser”, and are not new, but I haven’t seen browser plugin detection on malware pages in the wild before.

  3. Acidus Says:

    This is pretty standard web analytics code (go look at SiteCatalyst’s JavaScript for some creepy stuff) The only odd thing I see is it’s looking for specific PDF plugins instead of concating all the plugins into a list. Its possble this was modified to find a specific PDF plugin and exploit it, but I doubt that. All this web analytics code is bundled in a Single JS. If they hacked it to exploit certain plug ins, the exploit/attack would probably be in the same .JS file.

    As for a malware site using web analytics, its not too surprising. One explanation might be that its an accident. The stats tool could be included by default by the hosting company. Another might be the site owners want to know who many people visit them, what countries, what browsers and browser versions so then can decide who exploitable their audience is. However all of this is available using awstats against their server logs. Most people getting sent to this site are the sheep they are 0wning and so the user-agent strings, referrers, etc, won’t be spoofed.

  4. RSnake Says:

    Hi, Acidus - good points, but it can’t be an accident since it’s pointing to specific .php files. Other than that these are all good points. My guess is that it’s probably to identify what the typical profile of someone who gets exploited looks like. Demographic research on victims makes good sense from a business perspective. Since exploitation is money these days, I wouldn’t at all be surprised if that’s why they wanted that info.