It is not uncommon for the AVG Web Threats Research Group to receive comments from webmasters of compromised sites that are serving malicious content to their visitors, questioning whether the AVG detections on their sites are correct.
They almost invariably are correct. The Web Threats team maintains the LinkScanner component and the team is justifiably proud of a very low False Positive (FP) rate.
As of this writing, none of the reputed FP reports we have had about this detection have actually proven to be an FP. The confusion is understandable since the malicious operators have used several sophisticated ruses to hide their work:
– The injected malicious code is heavily indented.
– Exploit scripts are only injected into a visitor’s browser if the Referrer is from a top search engine.
Other site-security services are not detecting this
These webmasters’ denials are probably confounded by the fact that other anti-malware products, and various popular “site security” services such as Google Webmaster Tools and SafeBrowsing, and others, are not detecting this specific malicious code.
This lack of other detection reports, and perhaps most importantly, the fact that Google does not block their sites’ search results, means we have had some very indignant – even downright rude and ignorant – responses from the owners and/or administrators of many affected websites.
It is quite understandable that a website owner or administrator might prefer that a claim his or her server was dishing up malicious content was an FP. We explained to them where in the affected page(s) the content was and the twists they needed to be aware of so they were not tricked by the bad guys who planted the malicious code on their servers. However, many of these webmasters engaged in continued denials and even accusations that our researchers do not know what they are doing.
Malicious techniques detected by 1494
The issue for very many people is not deciding that code such as this may be up to no good, but rather, actually seeing it in a web page at all.
Heavy indentation of the malicious code
Here is a screenshot of the “source view” of a typical webpage that has had this script injected into it. We’re using the “view-source:” protocol in Firefox (and some other browsers) here, but much the same results are obtained by right-clicking on a page and selecting the relevant option. You want to be doing that in a virtual machine because you have to load and allow your web browser to render a potentially hostile webpage first. The identity of this site is obscured to protect the guilty:
Can you see it?
If you know what you’re looking for it’s pretty obvious, right there on the eleventh or twelfth line (in fact, once you’ve seen a few, you’ll be pretty sure it is the twelfth line). Let’s make it easier – we’ll hit “select-all” (Ctrl-A) in the browser to highlight all text in the window:
That makes it more obvious and confirms that the injected, malicious script is on the twelfth line – the one that looks like this:
This looks awfully like that script we introduced at the beginning of this section doesn’t it?
But, you may be thinking to yourself, surely few webmasters would be fooled by such a simple trick? Surely the very great horizontal displacement suggested in the horizontal scrollbar, as seen in the very first of these “source view” screenshots above should be a clue?
In this specific example that is the case, as this malicious script is by far the longest single line in the whole page. By comparison, here is the horizontal scrollbar of that browser window with that when the same page is served without the injected script:
But, of course, many webpages have extremely wide lines of source code, far exceeding the 2854 characters of the malicious script (plus its indenting spaces) seen in this example, so a protracted horizontal scrollbar is not necessarily a tell-tale of something bad.
So, imagine you’re a webmaster who didn’t fall for the old seriously-indent-the-malicious-code-off-the-right-of-the-screen trick. Earlier we said that there were multiple tricks in use here. Imagine, instead of seeing the page source in the first “view-source:” screenshot above, you saw:
What’s the difference?
In this second instance of the same URL being served, the eleventh and twelfth lines are “missing.”
In the first, there is no unexpected gap in the page’s source and the horizontal scrollbar is about the expected length. However, and this is the thing that really bakes many a webmaster’s noodle, this site is still serving malicious scripts!
Malicious scripts are only served once per IP address
In practice we tend to see that the “IP addresses already served” list is either dropped, or entries on it age-out, every 24 hours or so.
What this means in practice is that any given client (web-browser) IP address will only get one “infected” page load from one URL on the compromised server in any 24-hour period. Most website administrators visit their pages often, so by the time they get a complaint from a visitor that our products are blocking access to their sites, most webmasters will have already gotten their IP address(es) into the server-side script’s blocklist on their own servers, and will not be served the malicious code.
Exploit scripts are only injected if the Referer is from a top search engine
Another trick involves the HTTP Referer header (yes, “Referer” is misspelled in the HTTP protocol definition, so we’re stuck with it!). Exploit scripts will only be injected into pages served from a compromised server if the Referer header accompanying the URL request is from a specific location, or, much more commonly, if the Referer is from one of the top dozen or so search engines, such as Google, live.com, Baidu, Yandex, etc. This means webmasters who directly visit their sites to check complaints they are serving malicious content will not be served that content as they will not request the page with a suitable Referer.
– Web Threats Research Team