Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Fixes after being hacked.


Plux

Recommended Posts

All files having certain names where infected with an iframe. I deleted this iframe however after a while it got re-injected into those pages.

 

What could be the cause of this?

Link to comment
Share on other sites

You need to either delete the whole fileset and restore with a recent site back up that you know is clean, or go over every file line by line to remove all traces of hacker activity.

There are probably files added that you might have missed the are the source of the reinfection.

Its a ball ache of a job to do but one that must be done properly, also once clean ensure that your site is secure folder permissions and file permissions are correct, you have changed the admin name to something else and that the filemanager and define languages files in admin are removed.

Search the pinned topic in the security forum for add ons to use to help with protecting your site in the future

Nic

Sometimes you're the dog and sometimes the lamp post

[/url]

My Contributions

Link to comment
Share on other sites

Generally the attack goes through 3 stages.

1/ attackers exploit the security hole in unpatched versions of oscommerce to steal important customer information

2/ via this exploit rogue file manager type files are uploaded into writable directories.

3/ via these file managers which allow for mass appending of code to all writable site files an attacker is able to write iframe into either the head or tail of a php, html and/or .js file.

 

In order to defeat the attack you have to address all three issues.

 

Firstly patch the security hole in your site. This can be done in two ways, one is to upgrade to oscommerce 2.3.1 or comparative version, or install Osc_Sec which has the patch within its code.

 

Secondly you need to remove any rogue files that are not a part of the oscommerce file set. These for example are often uploaded into the image directory.

 

Then lastly you have to remove code that has been added into files that are a part of the oscommerce file respository.

 

To see examples of what the types of added code look like, read the link in my signature that reads Another discussion about infected files. Its not only rogue iframe code you need to remove from site files, but also appended base64 encoded additions that allow an attacker to upload files. Examples are in that link.

 

You have to clean up all 3 aspects of the attack, beginning with patching your site so that an attacker cannot use an appended login.php to bypass site security. The other method is as FIMBLE suggests which is to try to hide the security hole from attackers by cleaning out your site then changing the name of the admin directory.

- 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

Link to comment
Share on other sites

Can the define languages files in admin just be deleted without having to edit any files calling it?

 

I am having a weird feeling that the attacker might have uploaded a file using a RFI exploit. Is the attacker able of injecting the initial attack with this issue into any folder he wants to or will that help me limit the search?

Link to comment
Share on other sites

I am having a weird feeling that the attacker might have uploaded a file using a RFI exploit. Is the attacker able of injecting the initial attack with this issue into any folder he wants to or will that help me limit the search?

 

There is a known security hole in version 2.2.1 and earlier of Oscommerce. You need to patch that as I explained earlier. It would have allowed an attacker to get access to your admin section and upload rogue files into writable directories. Those files which are just file managers in themselves will be allowing attackers to do pretty much anything they wish on some sites where the script (PHP) has owner permissions. So they do not need to find a security hole which allows for file inclusion to pull this off, although I am not saying that they could be doing so, its just that there are no known RFI type security holes in 2.2.1 and neither would an attacker need one in an unpatched site.

 

If you have patched your site to close this hole then any other changes you make like hiding the admin directory are just extra layers of security. However if you have not removed all the rogue files and included code from your site files then attackers can simply use the added code to read the file and directory listing and find your new admin directory name, and in some cases, delete the htaccess protection from the admin directory.

 

What is needed is a thorough clean out of files as has been expressed to you above.

 

Initially they would have had full admin rights using urls such as www.yoursite.com/admin/categories.php/login.php

 

By merely constructing urls in that manner an attacker can bypass the need to log in as an admin, and can do whatever and admin can do on a site (on 2.2.1 sites). The reason this is possible is because as has been said, there is a security hole in the 2.2.1 code which needs patching as described above.

 

Once that is patched you can then continue the cleanup rest assured that you have stopped the initial attack, and by removing any files they were able to upload to your server, and, removing any added code like those in the examples given in my signature, you put a stop to further exploitation.

- 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

Link to comment
Share on other sites

Unfortunately there is nothing weird in my images folder. At least I presume the injected file should be a .php file?

 

Should the install directory not be removed after installation? I know most packages see this as a dangerous thing to keep. I do not know how this is for oscommerce?

Link to comment
Share on other sites

Unfortunately there is nothing weird in my images folder. At least I presume the injected file should be a .php file?

 

In some webserver configurations files with the default file permission of 644, cannot be written to as they are read only, and where a directory permission of 755 also cannot have files uploaded into it, however, on many shared host configurations and others, all files can be written to by a PHP script resident in a websites directory (see links in my signature for more).

 

There are different types of attacks based from the Oscommerce 2.2.1 admin bypass exploit. In the first instance attackers aim at uploading rogue file managers into uploadable directories, others try to insert code into website files using these previously uploaded files. In this second server configuration type, all files are vulnerable if the attacker has been able to upload a rogue file manager via the security hole in 2.2.1, injectable files are not just php, but also including html files and javascript files.

 

Should the install directory not be removed after installation? I know most packages see this as a dangerous thing to keep. I do not know how this is for oscommerce?

 

Completely removed is safest.

- 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

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...