Google blacklisted a client’s website claiming that malicious content was being displayed from “forogozoropoto(dot)2waky (dot)com”.
A scan didn’t reveal anything suspicious. The next step was to check all third-party scripts on the website. Soon we found the offending script. It was hxxp://jquery .offput .ca/js/jquery.timers.js – a jQuery Timers plugin that was moderately popular 5-6 years ago.
Right now, the jquery.offput.ca site is hacked. The home page appears to be blank, but it contains a few hidden links, one of which leads to a pharma spam doorway on another hacked site:
The plugin script jquery.timers.js is no exception (note the first line of code):
First of all, the obfuscated part decodes to:
So, we know this is definitely the source of the problem.
Next, you may have noticed this construction:
Most browsers ignore the comment and never execute the malicious code, taking it as:
It will always execute the malicious code, due to the inclusion of the commented “!” character.
This IE-only, conditional compilation hack will prevent the forogozoropoto(dot)2waky(dot)com script from loading in non-IE browsers, even if using an IE User-Agent string. This means that if you are using, say, a Linux sandbox with a browser that pretends to be Internet Explorer, and then monitor the HTTP traffic — you will not see any requests to forogozoropoto(dot)2waky(dot)com.
What Happened to the jQuery Timers Plugin?
After the initial release and a few years of plugin support, the developer lost interest and abandoned the jquery.offput.ca site. The page says the plugin has moved to the official jQuery plugin repository, and all updates will be available there only:
However, the repository URL is redirecting to jQuery.com, and it can’t be found using the search function. I suppose that the plugin has been completely abandoned, only living in local copies on some websites, and as as the hacked original version on the jquery.offput.ca site.
The Risks of Using Hosted Scripts
This is neither the first abandoned script, nor the last. Thousands of developers create plugins for jQuery. Many develop their own libraries. Some of those libraries become really popular, but there is no guarantee that developers will remain committed to supporting their software forever.
Consider these potential situations and outcomes:
- The plugin site is temporarily down (e.g. maintenance or server problem) — your site is broken.
- The plugin author updated the .JS file with a buggy or incompatible version of the plugin – your site is broken.
- The plugin author abandons the site (the domain expires) or moves the plugin to a different domain — your site is broken.
- The plugin site gets hacked and some malicious code is injected into the plugin file — your site is spreading malware to your visitors.
Please review your site code. If it still uses the jQuery Timers plugin, make sure to use a local version (you can get a clean version here) and don’t link to the infected jquery.timers.js file on the jquery.offput.ca site.
If you see any other scripts linked directly to third-party websites, you might want to consider serving those scripts directly from your site, or from a trusted CDN. This will prove to be a more reliable and secure solution.
Actually, having scripts on another domain may help improve load time. Browsers try to load multiple assets (scripts, pictures, styles) using concurrent threads but the usually limit number of threads for resources from the same domain (so that they don’t overload the server and it’s channel). So having resources from other domains may increase the number of concurrent thread a browser uses for downloads. That’s one of the reasons why people use CDNs. And it’s quite a good practice to load script from trusted, secure and fast (geo-distributed) CDNs. But if it’s just a site of some developer, you’d probably prefer to put the script on your own server.
CDNs yes, but those are designed specifically to improve availability and lower network latency/packet loss, so it isn’t ‘exactly’ the same as linking to just about any 3rd party sites, which you’d often find in some websites. Again, the operative words being “trusted, secure and fast geographically distributed” CDNs.
As far as having scripts on another domain goes, I’d imagine this would only be the case if the resource is already cached in the browser? There’s really no guarantee that that domain is hosted as part of a CDN, not to mention a trusted, secure and fast one. Consider for example, a script on a 3rd-party domain that is hosted on a server whose cpu/memory resource is maxed out at the time the request for the script is made.
Comments are closed.