Today I came across an interesting attack that injects malicious scripts at the very bottom of existing .js files.

Update: at the bottom of this post you’ll find information about how a security hole in Plesk Panel was used to infect websites. Comments are also worth reading.

Update (July 26, 2012): The attack has changed both the injected script and the domain generating algorithm. See details in my follow up article. Information about the Plesk security issues are still can be found in the current post and comments.

The script (surrounded by the /*km0ae9gr6m*/…/*qhk6sa6g1c*/ pair of comments ) looks like this:

I say “currently”, because the most interesting thing about this script is the built-in domain name generator.
If you decode the script (see the code), you will see functions with names like nextRandomNumber, RandomNumberGenerator, createRandomNumber and generatePseudoRandomString and the iframe URL generation based on the current date and time:

Unlike that Twitter-based algorithm, this new attack has a really dumb pseudo random string generator. It’s based on such a predictable factor as a current data and time (before noon or after noon). It generates new domain names every 12 hours.

Predicted malicious URLs and sink holes

No wonder, it only took a couple of minutes to write a simple script that predicts URLs of the malicious iframes that this attack will use by the end of summer of 2012. Then a quick check showed that 89 of the domain names (up to August 7th, 2012) are already registered and point to 95.211.27.206. When I try to open the predicted malicious URLs I see the “domain suspended due to abuse reports” message. It looks like someone has already taken care of this attack and sink-holed its domain names.

Or is it a just trick that attackers use to make me think that there is nothing to worry about? It looks quite suspicious that 95.211.27.206 is on Leaseweb (cybercriminals like to use this hosting provider), and nameservers have Russian names “evilstalin.compress.to” and “smolny.compress.to“. At the same time all domains are registered by a “Private Person” using a Russian registrar NAUNET that is known for being loyal to spammersand other cybercryminals. The WHOIS information and IP addresses for domains registered before the beginning of the attack (on June 8th) are the same as for domain names that had been registered just yesterday — this means that they all have been registered by the attackers.

And if you read comments to the following reddit thread, you will see that some people get the “domain suspended due to abuse” message while others get redirected to “hxxp://db8237d82bdu .ipq .co/feed/xml.php?uid=12” and “hxxp://masvip .ru/6662/take.html“, which suggests that there is some server-side logic that filters traffic (probably by IP, Referrer , etc.)

Update (June 28, 2012): Today I saw myself how the “hxxp://gytcnulxsxpsqkfn .ru/runforestrun?sid=cx” URL returned 302 redirect to “hxxp://insurancecentre .ru/in.cgi?7“, which in turn redirected to “hxxp://freshtds .eu/default.cgi“.

And what do you think? Are these domains sink-holed or they only pretend to be sink-holed?

By the way, here’s my list of the predicted malicious URLs.

Update (July 6, 2012): At this point I see that predicted domain names are already registered through September 7th, 2012, so I genarated a new list (up to October 9th) and put it here: http://pastebin.com/iZWFrDPC

Update (July 26, 2012): The attack has changed both the injected script and the domain generating algorithm. See details in my follow up article.

What’s the security hole?

Another important questions is how all those legitimate sites had been compromised in the first place.

At this point I haven’t had a chance to work directly with infected sites and check what’s going on inside. So I have to resort to analysis of factors that I can see from outside. I checked about a dozen of infected sites and they all use different web technologies from ASP.NET to pure HTML. They are all on different web servers: IIS, Litespeed, Apache. The only common link I can see is Plesk. When I check other sites on the same IP addresses I usually find a few more infected site (not all though). So could this be some security hole in Plesk that made this attack possible. What do you think?

Update (June 23, 2012): Thanks to everyone who left comments. The problem seems to be really in Plesk. Axel found traces of the attack in Plesk access logs. The attacker logged in and used file manager’s editor to modify .js files. Axel blames the Plesk vulnerability (versions before 10.4 are affected) found earlier this year and suggests that server admins fix it: http://kb.parallels.com/en/113321 and reset passwords for all plesk accounts:

So if you are affected, then immediately change passwords of ALL Plesk accounts. This means: Plesk-admin-user, all reseller-accounts, all domain-administrators, FTP users of subdomains and web users of domains. And of course, if not previously done, update your Plesk installation!!

To webmasters: If your site is affected by this hack, contact your hosting provider ASAP and show them this post. Change your account passwords. And if your host resets your passwords there is a good reason for that. Don’t change your passwords back to your old ones!

Update 2 (June 25, 2012): To find out more about this problem, I asked Axel a few questions and he agreed to explain what’s going on:

It is important to distinguish between the attack and the security hole. The attack was not carried out directly by a security hole, but by means of a valid username/password combination.

The attacker used the built-in Plesk File Manager to replace files, so there are no entries in other log files (such as FTP-log -> Shafiq’s comment). And there were a number of files changed with the same javascript code at a time. As you can see in the log-excerpt, there were 3 replacements: javascript_a1cb3a5978.js / jquery.min.js / easySlider1.7.js

This file selection has been very well analyzed (no TYPO3 standard files), so it is also clear that it was not an automated attack, but was executed by a human. By the way: the origin of my attack was another compromised server from Germany.

However, the real problem was/is the Plesk vulnerability (http://kb.parallels.com/en/113321). Many admins do not realize that their passwords have been spied out weeks or months ago. To make it more clear: Due to the Plesk vulnerability database tables could be read. And unfortunately all Passwords in Plesk are stored in plain text!! Take a look in database ‘psa‘ at table ‘accounts‘ (and better sit down before doing that!). That’s why it is so important to change ALL passwords.

Just fixing this vulnerability AFTER the server has been compromised, without changing ALL passwords, leave valid username/password combinations! So the attacker can come back after weeks or months and attack even in the meantime updated Plesk systems!!!

How can one find out whether the server has been compromised (weeks ago)? This is actually very difficult. For me it works to look at the Plesk Action Log: There were times were I detect many VALID account logins from different IPs in a very short time. This can’t be real and seems to be a kind of automated control of the captured login data. A very clear sign of the attack :-(

Update (July 8, 2012): Here’s an interesting thread on the Parallels forum where server admins say that they applied security patches and reset passwords but their servers were re-infected shortly after that. Anyone has a proven solution to permanently fix this issue without breaking the File Manager (as suggested in the following comment)?

A few more questions to admins of affected server. Especially if your servers got reinfected after changing passwords and applying security patches.

Did you consider use of backdoors? Did you search for backdoors?

Did you consider scenario where hackers created some rogue users on your server? Maybe even an extra admin user? Did you try to search for users with suspicious activity or with excessive permissions?

By the way, the rumor has it that on hacker forums, someone offers an exploit (quite expensive) for Plesk <=10.4 that allows to obtain admin password and remotely execute code on server (looks like it’s for Windows servers only).

Update (July 15, 2012): Parallels has just released the “Big” Security Update for Plesk v8-10 (all OS) and Plesk 11 (Windows only). They don’t disclose details but mention that the security issue is “critical” and they found it during internal testing. Not sure whether it can fix this current issue but it is definitely something administrators of servers with Plesk Panel should do. (And then comment whether it helped or not)

It can help if you could get FTP and access logs for compromised sites and check if you see any signs of the attack there. If there are no signs in the logs then the problem is most likely with server infrastructure/configuration.

Just to add, I’m a member of a site that offers hosting, they have several different IPs and also use Plesk. Most sites are running wordpress. I’d say that a third of the sites I checked on each IP had been infected.

The attacker uses a domain/password he found out at an earlier attack in late February / early March (http://kb.parallels.com/en/113321). I (as admin) changed all passwords after that, but unfortunately one customer changed his password back to the old one. Gotcha.

So if you are affected, then immediately change passwords of ALL Plesk accounts. This means: Plesk-admin-user, all reseller-accounts, all domain-administrators, FTP users of subdomains and web users of domains. And of course, if not previously done, update your Plesk installation!!

My host is running Plesk 8.6.0 and has not updated in spite of what amounted to a DoS attack earlier in the year after which they said they would give everyone strong passwords (have they? why ask! their certificate is two years out of date as well).

I forwarded a security report from a large international client which said that Plesk was not up to the job, but they ignored it. At that time I was getting email bounces from addresses I was not including in the list of addressees and which genuine recipients were not forwarding (to their knowledge).

From the posts here, it seems that sites with js are vulnerable since there was a password hijack in Feb 2012.

I had a script inserted into index.html (the plainest of plain html pages you will ever see) and the hacker very kindly copied the file to index.htm first. That was done on 22 June.

I got warned today that avast! was blocking a URL linked from my site. I deleted and replaced the file, complained to the host, changed my passwords (admin, domain and ftp). Went back to the site after that and found the contaminated file was back. Timestamped: midnight UK time. After I had changed the domain manager and ftp passwords, but not the admin password.

I have another (older) domain on the same admin account and that has not (yet, touch wood) been affected.

Forgot to say, the affected site has only been in existence since 14th June so the domain and ftp passwords are new, but my admin password has not been changed as often as it should over the last six years…

Fastest way to check if you think your site has been injected with malware is to use Google Chrome > Developer tools (F12) > network tab. You’ll see all request going to a random sites runforestrun (lfbocaitdrjmkbe.ru), in.cgi (netbizz.ru), default.cgi (freshtds.eu).

Hey all. Sorry for the all caps, but this seems important to me. I have a server running Plesk 9.5.4, and have the IP address restriction turned on in the control panel, restricting logins to just 2 ip addresses (my office, and the office of 1 of my web clients).

Be careful with this one as it will delete all the line. You’ve to consider that the ones doing this exploit usually put the code appended to the last line, so the code above will delete the last line of the file.

HI. I posted this point earlier, but thought I’d mention it again. Anyone else had this script posted despite server IP address restrictions? (see my earlier post). I’ve updated all passwords, etc., but I’m mystified as to how the attacker could have logged in in the first place from an IP address not allowed by Plesk’s IP address restrictions. That really scares me.

Another question. In digging through log files, I’m finding some entries I don’t quite understand. Can anyone tell my why the localhost address is appearing after the inbound IP address below? I still have not been able to determine how my hacker got past Plesk built-in IP address restriction. Thought this might be a clue.

Scott: the ip restriction only affect to the main admin account of plesk, dont affect to the domain admins accounts (checked in my 9.5.2 panel).
The request to page login_up.php3 always will return status 200 although the ip restriction deny the login (the page show the denied login message but the page request return status 200) I checked that too.
I think that the hackers always use the admin domain accounts becouse of this, then the ip restrictions has nothing to do here.

But I have one question: in my case, the hackers have used one domain account to modify a lot of other domains, but only using an legitimate user/pass from one domain. How the filemanager allow that? to modify files of other domains? Is there a patch for that?

@ Brod – in my case, it appears that the hackers logged in as admin, but I still don’t understand how. As I stated before, IP address restrictions were on. The sites that were compromised were from multiple clients, so I’m sure that this could not have been accomplished with just one client login. My admin password is ridiculously complicated. So I don’t think brute force is a possibility. Password is also only a few months old, and the password before that was also bulletproof.

One thing that I have been looking into is a way to set up Apache/PHP to run as a different user for each site. Many CMS (anything that allows uploads) require write/execute permissions for the web server. However, there were compromised files on several of my sites that did not have write access enables for Apache/PHP – so although that is a concern, I don’t think those permissions were a factor in this attack.

Just stopped in to let you know, I have been messing with this script too, and the URLS it created for the last 2 days show up in your list here in the proper order. Tomorrow, July 6th should be ciqmhuwgvfsxdtrw. Looks like your list is the real deal.

Great write up, very interesting! Unfortunatley I’m not much of a coder myself, you say it only took you a few mins to make a script that predicts the urls, would this be somehthing you could share? Thanks in advance!

I have a site hosted on a Plesk server. I have left a message with the administrator and meanwhile ran the sucuri checker. It said i have 4 infected js files. Manually edited out the bad code, reran the checker, it says I am clean.

But I’m not :(
Here is what developer tools shows in Chrome:

Cyprus Property & Villas ≈ Contact Us

I have been through each of the js files and they all look clean, but I still get this appearing

Thank you so much for posting this information. Our site became infected July 2, 2012, flagged by Google. I deleted and re-added scripts and an html page flagged by Google. Google verified the site and it was okay until July 7. The script files were modified at 5:55 am on July 7 – and not by me. I again deleted and re-added.

Right now I have the index removed and plan to find a host server that does not use Plesk.

Thanks ever so much for this post and all the useful comments! Just for other folks, I noticed that one of the most useful commands posted above had some html entities, and I just thought I’d summarize here exactly what I did that helped fix this situation for me (hopefully sans html entities).

First to find all the infected files:grep -rl –include=*.{php,js,html,htm} “km0ae9gr6m” *

Next to break Plesk’s compromised File Manager (assuming you’re not using it… and because we all know what fun it is updating Plesk!):cd /usr/local/psa/admin/htdocs/filemanager/
mv filemanager.php filemanager._hp

Does anyone know what kind of payload this script had? I did visit an infected site on my server before I realized what was going on (while troubleshooting initially). I’m on Mac OS X, and since this was written on Windows, I’m hoping that it only affects those machines. I’m now running an app called “Litte Snitch” to monitor all my outbound traffic for suspicious activity; so far nothing (also ran ClamXAV, also nothing).

Ah, thanks for the link! It appears I was rather lucky in that the Ghostery browser plugin on my Mac blocked that iFrame in both Firefox and Webkit and so I was never redirected to any payload site :) So far so good here having disabled Plesk’s File Manager and cleaned infected files; I’ve also setup a cron job to check for the infection regularly to keep an eye on things. Migrating to Virtualmin away from Plesk (that was already in the works, but this sped that up a bit!)

My site was also infected by July the 2nd (running wordpress) and with a massive flood of spam comments. Cleaned the site but later, on July the 7th I found that index.php was infected by this script. Immediately I requested to change the passwords for plesk and sucuri marked the site with an outdated version of plesk.

Cleaning the site only worked for a few hours since on the 8th I found again the file index.php with the additional javascript. Cleaned again and the password for plesk was changed again….

Notice this, I had a PLESK password until July the 7th, changed by the webhosting service support on July the 8th before 4 AM and after that (I guess that in between 4 AM and 11 AM) the file index.php was once again changed to include the script. The password has been reset again, but I guess there’s another exploit that hasn’t been detected so the files can be changed…

Currently I blocked the access to PLESK (not even I can access) by killing the browser during a PLESK session. I’ve monitored the site since then and it’s stable.

I want to add that in the meanwhile a constant flow of HTTP POST requests to comments were issued to the site almost every second from random IPS (some of China, Russia and even in the range of Microsoft Headquarters)…

This plesk garbage has me so frustrated. I have been working for days to find the infections in my server and it seems it must be in my sites database but I can’t seem to find it anywhere. I’ve changed my passwords and tried multiple things to find the infection and can’t seem to locate it.

It also seems that the script only runs between 4am and 6am EST, which makes no sense to me… If anyone is willing to help me track down the infection I would greatly appreciate it.

To your lastest update to your blogpost: Perhaps it makes sense to write another blogpost how to lock plesk down and make external access as hard as possible. What are the best practices to stop the next wave?

I’m not a Plesk expert and never worked with Plesk. I totally rely on the information provided by server administrators who take time and leave their comments here. If anyone want to do a guest post about Plesk security on this blog, please contact me.

Meanwhile a link to the SparkTrust’s article Plesk vulnerability remediation tips
Literally the same advice as you can find here in comments (patch Plesk, reset passwords, break File Namager), just more detailed.

Hmm… No sorry. Everything is cleaned and I didn’t keep any reference…
A customer cleaned his server only looking at “km0ae9gr6m”. After that I discovered more with clamscan and/or avgscan. That is how I discovered there were similar but not the same fingerprints like that /*km0ae9gr6m*/.