Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
Loading site search ...

“Inlovebot” and “Crazymasya” Iframes on RackSpace

   19 Sep 10   Filed in Website exploits

A few days ago I noticed a new mass infection of sites on RackSpace. It mostly affects WordPress blogs and sites hosted under the same account with WordPress blogs.

Hackers create malicious .js files in some subdirectory of the compromised sites and inject links to those .js files into website pages.

The .js files contain a single long line of an obfuscated JavaScript that looks like:

var resLobo={rocPork:null};porkWye='';var porkDeb=0;do{var oohPork=0.013;porkDeb++;}while(porkDeb<6);var loboRes=new RegExp('[TDhg]','g');function drabDeb(oohLens,lensOoh){resPork=0;do{this.porkRes=0.009;porkRes-=2817;resPork++;}while(resPork<10);...skipped....function geekGod(drabGod,porkGod){for(lunyWye=0;lunyWye<8;lunyWye++){resLuny=0;do{var godPork=1562;godPork++;rocLuny=5706;rocLuny--;resLuny++;}while(resLuny<5);}tortGod=0;do{var godAbet={lunyRes:'lunyRoc'};tortGod++;}while(tortGod<9);return porkGod}}godLuny=2305;godLuny++;this.lensGod=0.0018;lensGod-=7205;oohAbet();lunyThy='wyeLuny';this.lunyOoh=new Date();

The actual content of this file varies from site to site. Hackers definitely use some tool to automatically create differently obfuscated copy of the malicious script for every site. This helps against malware scanners that are searching for hardcoded malware patterns only.

Once deobfuscated all those scripts do the same thing: inject a hidden iframe that loads malicious content from either hxxp://inlovebot .com/vip.php?s=0 or hxxp://crazymasya .com/vip.php?s=1 .

Naming patterns and locations

In case of WordPress blogs, this .js file is usually placed into the current theme’s directory and has the same name as the theme (for example wp-content/themes/thematic/thematic.js) or default.js or main.js. Here are the basic naming patterns for the rogue files on WordPress blogs:

  • wp-content/themes/<theme_name>/<theme_name>.js
  • wp-content/themes/<theme_name>/defailt.js
  • wp-content/themes/<theme_name>/main.js

The link to this malicious file is injected into the theme’s footer.php file.

<script src="<theme_name>/<theme_name>.js" type="text/javascript">

In case of non-WP sites, the files are usually placed into subdirectories with names like images, css, inludes, wp-includes (this approach can be used for WP sites too). Here are the names of the malicious .js files I’ve seen: img.js, click.js, tool.js.

Links to those files are usually injected at the very bottom of the HTML code, right before the closing </body> tag:

<script src="images/img.js" type="text/javascript"></script>

New malicious server

At this point all infected websites that I found are hosted on RackSpace Cloud (different IPs). This is not the first time we can see attacks targeted at RackSpace-hosted websites (mainly WordPress blogs). What makes this attack different is the use of a malicious server in Russia (94 .127 .69 .168) , while all previous attacks utilized servers on various networks of the American C I Host provider.

Does it mean that the hackers switched servers or we have a new gang that figured out how to exploit RackSpace infrastructure?

To webmasters

While I don’t have any internal information about this attack, I can suggest that webmasters check the following thing:

1. Check file permissions of the wp-config.php file. This file contains your database password in plain text. If it is world-readable, your neighbors can simply steal your DB password and mess with your WordPress database. It is possible to create a rogue WP admin user and use it to inject arbitrary content into WP theme files (for example, backdoor scripts that allow hackers to upload files to your site and modify existing files). Correct wp-config.php permissions on RackSpace Cloud should be either 600 or even 400.

2. Change database and WordPress admin passwords. Don’t forget to update them in wp-config.php (including security keys).

3. Make WordPress theme files and directories read-only for all, including the owner (400 and 500) . If you need to edit them, you can temporarily add the write permission and revoke it once the change is done. This should prevent infections via rouge WP users.

4. Make sure there are no rogue WP users and you recognize all of the users.

5. Check if there are any world-writable directories (with 7 in the last digit of permissions, e.g. 777). Hackers can use them to upload backdoor scripts. Specifically, check directories below the “wp-content/uploads

6. Check that WP theme files are intact and the theme directory doesn’t contain new suspicious files. You might what to compare the theme on your server with the original theme (either from a clean backup or from its vendor’s site). Also check for new .js files in other subdirectories of your site.

7. Some people reported that they had found backdoor scripts in different subdirectories of their sites. Scan your server for
suspicious files (especially .php). Search for the following keywords: “eval“, “base64_decode“, “gzinflate“. If you find any, please let me know about them.

8. Some people say that hackers could initially use stolen FTP credentials to upload backdoor scripts. I’m not sure, this is the case here, but still it’s a good idea to check your computers for malware and change FTP passwords, especially if you are on a Windows PC. Try not to use FTP at all. This protocol is not secure. It transfers passwords in plain text and everyone who can intercept your traffic (e.g. malware) can easily steal your passwords. Use SFTP instead (I believe RackSpace Cloud supports it). Most modern FTP clients support the SFTP mode, so the switch should be painless.

9. If your site is blacklisted by Google, you should request a malware review via Webmaster Tools (Diagnostics -> Malware) when it is clean. Without this review your clean site may remain blacklisted for weeks (more about it here).

You might also want to check this great RackSpace’s guide: Recovering from and Dealing with a Site Compromise

More information wanted

If you have any additional details about this attack, please share them in comments. If you own one of the hacked sites – did you notice anything suspicious that wasn’t mentioned in this articles? Or maybe you know what exactly helps hackers compromise all those sites and what can stop them? Your comments are welcome!

Related posts:

Reader's Comments (5)

  1. |

    […] This post was mentioned on Twitter by Denis and Keith Petersen, xanda. xanda said: “Inlovebot” and “Crazymasya” Iframes on RackSpace […]

  2. |

    Is a very similar attack seems to be occurring on MediaTemple now? I’ve had 5 MT grid-service sites hacked today. All sites that I’d done my best to harden.

  3. |

    I’ve had this issue, just dealt with it. There’s been two js files uploaded to my rackspace cloud hosting server, both named site.js, one in my /js folder, the other in /css folder, both sized around 5.3 kbs.

    One starts with “var coyGulp=0.0172;”, and has words like Gulp, Skew, Feu all around the place.

    The other starts with “this.damCess={drubDam:[‘sabsDam’,’tanShog’,’damSabs’]};” and has words Cess, Dam, Shog, Sabs repeated…

    Hope this helps somebody, and I thank to you unmaskers ;)

    • |

      Later on I found it again, in one of my WordPress sites hosted on rackspace. There were two js files again, both called from the footer.
      One was named cutline.js starting with “function dalsEbb(ebbBice,coffEbb)” which i found in my theme folder, and the other one was in the wp-includes folder, called site.js starting with “var nilFist=1908;”.

      Again, hope this is helpful to somebody.

  4. |

    Had this same problem on my rackpace server account that hosts about 30 websites currently and about 20 were hacked. 18 of them were wordpress and two were plain html sites with no database set-ups which led me to realize it didn’t just have to do with wordpress or database vulnerabilities like I first suspected. This was later reinforced by Rackspace that my sites were probably just insecure. So I added more security .htaccess files and database password changes etc. Which is all great, but the tough thing is stepping back from all this and realizing the hacks were really targeted at Rackspace and was infiltrated through their security weakness. Well after a week of submitting google webmaster requests and beefing up security I need to work double time to catch up on my overdue projects.

    Hope this helps somebody, Cheers!