recent attack on OSCommerce enabled sites

[jimlongo]

My site was recently the victim of an attacker that placed several php files on my server. No other files were changed or manipulated in any way.

My logs and my hosting provider seem to indicate that the attacker used OSCommerce to upload these files. I really don't understand how, but I've since followed all the security precautions I can find against this exploit.

Tonight in researching this further I've found dozens of sites running OSCommerce which have been affected by this exploit.

 

DESCRIPTION--

The attacker uploads the following php files to your webserver

bety.php, sh1.php, lname.php, mm.php (there may be others), they are often found in images folders, but I have even had them one level up in public_html folder.

 

Your website will function in exactly the same manner as before . . . there is no visible change and no change to any of your code.

The initial purpose of the files is to fool Googlebot into seeing totally different content than the public. There will start to be hundreds or thousands of pages in your sitesearch results in the form

http://www.yourdomain.com/bety.php?=some-garbage-keywords

You might see this doing a google search for site:yourdomain.com tiger

 

The initial result will be that your Google keywords will be changed. I noticed this attack when I woke one morning to find my keywords in Google WebmasterTools all suddenly changed to tiger,woods,nordgren,nfl,30rock,etc., nothing to do with my site. This is the first stage which is bad, but it can get worse.

 

Then there are pages in russia like the following (beware of the following links, they may try to tempt you to download a virus)

http://my.mail.ru/community/abdul_and_asem/journal/?skip=200912210411211CC1FD6563BD0C00&type_filter=&blogsort=date

 

These pages have thousands and thousands of bogus links which if you have the bety.php file on your server initially displayed pages with thousands of keywords, but now seem to be redirecting to pages that attempt to download a virus through the client browser.

---------

 

If you have these php files on your server please immediately isolate/rename/delete them.

 

Next you need to determine what steps you need to take to secure your installation and webserver.

 

Next you have a big mess to clean up with Google.

 

Hope this helps,

jim

[vakondweb]

If you have TinyMCE with file manager, then you have to know that this is the security hole in your system.

Use ibrowser instead, that one can not be attacked, also use .htaccess protection for the admin folder and rename the admin folder to an other word, for example gfhjg765

what can not be found out.

In the main folder of your webshop, put one more line:

Options -Indexes

 

This line will not let the attacker (or google) to scan your folder system.

[Ben Nevis]

There's a lot that needs to be done to secure osc properly. There are many ways to hack it. Look in the first post in the security forum.

[web-project]

the best way to secure:

 

1) for 2.2 RC version patch using manual at URL:

http://github.com/os...caf2764ba1457c4

2) rename almost all files in /admin/ folder (example: file_manager.php --> abc_file_manager_zxv.php) and don't forget to update /admin/includes/filenames.php file

3) rename the default admin folder to other name.

[Ben Nevis]

the best way to secure:

 

1) for 2.2 RC version patch using manual at URL:

http://github.com/os...caf2764ba1457c4

2) rename almost all files in /admin/ folder (example: file_manager.php --> abc_file_manager_zxv.php) and don't forget to update /admin/includes/filenames.php file

3) rename the default admin folder to other name.

There are several patches and changes needed to secure osc rather than one single 'patch'. That one in the github is just about avoiding logging in twice when using .htaccess as well as osc's admin username/password login routine as one method of preventing people from getting into the admin section. That doesn't mean there aren't other ways, such as sql injection attacks. Changing the name of the admin folder or securing it with .htaccess doesn't prevent that. As for changing the name of the file_manager, I suspect it's not also known as 'file_mangler' for no reason. It should be deleted. There is no reason to keep it, and it should be deleted.

 

Although in general it's useful to know the routes for specific attacks and how to close the door for a specific type of attack, people need to know there are many types of attack and all doors need to be closed and not just one or two.

[web-project]

Changing the name of the admin folder or securing it with .htaccess doesn't prevent that. As for changing the name of the file_manager, I suspect it's not also known as 'file_mangler' for no reason. It should be deleted. There is no reason to keep it, and it should be deleted.

it will prevent the attacks which I have seen.

 

That doesn't mean there aren't other ways, such as sql injection attacks.

blocked by proper firewall this attacks! not like on some other shity web hosts

[Ben Nevis]

it will prevent the attacks which I have seen.

 

 

blocked by proper firewall this attacks! not like on some other shity web hosts

I don't think even a 'proper firewall' is likely to prevent attacks resulting from vulnerable coding. SQL and code injection attacks arise because the fields available for user input allow SQL statements to pass through and query the database directly. There is no avoiding the fact that a firewall needs to allow communication between web traffic, the application, script engine, and the database, and the script engine needs to be allowed to execute any functions the application requires.

 

Anyway, my approach would be to say better safe than sorry. The fact is that exploits on the admin directory are far from being the only attacks osC users have suffered. Better to secure the vulnerabilities in the coding than to rely on firewall rules that the host provider has set up - they are concerned with protecting their servers, not your applications, and will close you down if your application is insecure and threatening their services.

 

That is why the reason why the How to Secure Your Site thread has far more to suggest than simply securing the admin directory.

[ozEworks]

There's a lot that needs to be done to secure osc properly. There are many ways to hack it. Look in the first post in the security forum.

I think that is an over-statement.