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.
Lately, one detection in particular has raised more questions each day than we usually see across all of LinkScanner’s detections. In question is “JavaScript Obfuscation (type 1494)”, which, as its name suggests, is a detection for a specific obfuscation technique used to hide the intent of further malicious JavaScript.
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.
– The server-side script makes sure that the malicious client-side JavaScript is only injected on a “once-per-IP” basis. Thus, web masters who check their pages frequently will not be served the malicious script.
– Client side JavaScripts set cookies to avoid serving malicious script more than once.
– 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
The AVG Web Threats Research Group released this detection April 2, 2012. Thanks to the automatic reporting to us through the products’ optional “feedback” mechanism, we know that in the intervening two months, “JavaScript Obfuscation (type 1494)” has been detected on thousands of compromised webservers, and resulted in several hundred-thousand individual detections, and, more importantly, protective blocks for AVG customers. Despite this success in protecting many thousands of AVG customers, many webmasters whose sites are being blocked by AVG products still seem unable, or unwilling, to accept that their sites are compromised and serving malicious content to their sites’ visitors.
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
So, what is it about “JavaScript Obfuscation (type 1494)” that so befuddles many webmasters whilst being so obvious to the researchers in the AVG Web Threats Group?
Sadly, there is not a simple, single, answer to this question. The actual code that “JavaScript Obfuscation (type 1494)” detects is quite simple, but to see it all onscreen in a readable font size, you need to wrap it – usually this is all on one long line:
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?
No?
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:
Well, it’s not true confirmation, but a pretty strong clue. Why would a line of JavaScript be indented 418 spaces in this case other than to hide it from someone doing a cursory examination of the page’s source? Let’s scroll across the page until we get to the first bit of interesting content on this line (we’ve unselected the text as it’s easier to read this way):
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
True, it did not do so just then, but there’s a very good reason for that. The malicious JavaScript that is detected as “JavaScript Obfuscation (type 1494)” is commonly injected into webpages as they are being assembled for serving by a malicious server-side script that is part of the code that was installed onto the server when its security was compromised. This server-side script makes sure that the malicious client-side JavaScript it injects into pages — which will be detected by AVG products as “JavaScript Obfuscation (type 1494)” when webpages it has been injected into reach the computers running AVG — is only served on a “once-per-IP” basis. What is that? Loosely, the malicious server-side script on the compromised webserver makes note of the IP address of the computer requesting each URL, and if that IP is one the malicious server-side script has already served any page to with its malicious JavaScript injection, the malicious code on the compromised server does not inject its malicious JavaScript into subsequent pages served to the same 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.
Client side JavaScripts set cookies to avoid serving malicious script more than once
There are other tricks too, sometimes used in concert with this once-per-IP trick, and sometimes used instead of it. For example, some malicious client-side JavaScripts will set a cookie, and if that cookie is then supplied with subsequent URL requests the malicious server-side script knows that this client machine has visited this server before so the server-side script will not inject the malicious JavaScript into the pages it serves. Webmasters who have already visited a compromised page on their server will already have the cookie so will not see the malicious JavaScript served again.
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
Leave a reply
