Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

What are these site visitors up to ?


JohnDet

Recommended Posts

We are running 3 sites 2.2-MS2, we removed file_manager & define_language, and have our renamed admin password protected.

 

For more than 1 month, and increasingly, we are swamped with visitors from around the globe, although notably France calling for site URL's that don't exist

 

Maybe 800 - 1,000 requests so far in March like this :

 

/shopping_cart.php/admin/categories.php/login.php?cPath=&action=new_product_preview

/support.php/admin/categories.php/login.php

/shipping.php/admin/file_manager.php/login.php

/shopping_cart.php/admin/categories.php/login.php

/[An information page].php/admin/categories.php/login.php

/contact_us.php/admin/categories.php/login.php

 

Are they probing a hack, taking pot luck to actually find a valid page ? Most of them end with login.php

 

Would htaccess banning them sysematically make the problem go away, or make it worse, by attracting more attention, or is it safe to just ignore them

 

We never had any successful hack attempts, and things are running well for many years

 

Please help

Link to comment
Share on other sites

John,

 

 

Hackers are running vulnerability scripts through proxy servers or through compromised osCommerce sites they have already hacked in search of other vulnerable sites. These automated scripts are using extreme amounts of bandwidth and type up server resources but so far, they seem to be unstoppable. I ran an IP block on one clients website and banned more than 3000 IP addresses in one night. This didn't even slow them down, they just kept sending the bad URL requests from different IP addresses.

 

 

 

Chris

Link to comment
Share on other sites

If your site is secure then you should be ok, but the main problem lies with bandwidth

 

if your hosting plan is limited bandwidth you don't want these attacks to use all your bandwidth

 

the bad behavior contribution might help to reduce the bandwidth if that is a problem.

 

JLewis

 

edit see http://www.oscommerce.com/forums/topic/372284-ip-trap-variable/

 

as all your links end in .php/login.php

Link to comment
Share on other sites

i have seen what you show here (but only once or twice) on sites i manage. if you add this few lines of code to the two application_top.php, one under [admin-folder]/includes/, the other [yourshop-webroot]/includes/, they will go away:

$hacker_test = strtolower($_SERVER['PHP_SELF']);
if (substr_count($hacker_test,'.php') > 1 ) {
 header('Location: http://www.anti-hacker.info/contact.html');
}

remember you must add it at the very top of the two files, before any line of code runs.

ken

 

We are running 3 sites 2.2-MS2, we removed file_manager & define_language, and have our renamed admin password protected.

 

For more than 1 month, and increasingly, we are swamped with visitors from around the globe, although notably France calling for site URL's that don't exist

 

Maybe 800 - 1,000 requests so far in March like this :

 

/shopping_cart.php/admin/categories.php/login.php?cPath=&action=new_product_preview

/support.php/admin/categories.php/login.php

/shipping.php/admin/file_manager.php/login.php

/shopping_cart.php/admin/categories.php/login.php

/[An information page].php/admin/categories.php/login.php

/contact_us.php/admin/categories.php/login.php

 

Are they probing a hack, taking pot luck to actually find a valid page ? Most of them end with login.php

 

Would htaccess banning them sysematically make the problem go away, or make it worse, by attracting more attention, or is it safe to just ignore them

 

We never had any successful hack attempts, and things are running well for many years

 

Please help

commercial support - unProtected channel, not to be confused with the forum with same name - open to everyone who need some professional help: either PM/email me, or go to my website (URL can be found in my profile).

over 20 years of computer programming experience.

Link to comment
Share on other sites

i have seen what you show here (but only once or twice) on sites i manage. if you add this few lines of code to the two application_top.php, one under [admin-folder]/includes/, the other [yourshop-webroot]/includes/, they will go away:

$hacker_test = strtolower($_SERVER['PHP_SELF']);
if (substr_count($hacker_test,'.php') > 1 ) {
 header('Location: http://www.anti-hacker.info/contact.html');
}

remember you must add it at the very top of the two files, before any line of code runs.

ken

Link to comment
Share on other sites

Just have to be careful with banning two instances of .php in the category side. There are occasions in some configurations of oscommerce where there are 2 instances of '.php' in the url on the main catalog side.

 

It might be safer to actually patch the faulty PHP_SELF code in the first place which is resulting in many of the admin hacks. The 'fault' not so much in $HTTP_SERVER_VARS, but rather it is depending on it further into the sites code to find the filename.

 

Code in question in both include and admin/includes application_top.php in all versions other than the latest 2.3.1:

 

if (!isset($PHP_SELF)) $PHP_SELF = $HTTP_SERVER_VARS['PHP_SELF'];

 

There are variations of this in the earlier versions of oscommerce.

 

This should be replaced with the code from the latest version of oscommerce, 2.3.1:

 

  $PHP_SELF = (((strlen(ini_get('cgi.fix_pathinfo')) > 0) && ((bool)ini_get('cgi.fix_pathinfo') == false)) || !isset($HTTP_SERVER_VARS['SCRIPT_NAME'])) ? basename($HTTP_SERVER_VARS['PHP_SELF']) : basename($HTTP_SERVER_VARS['SCRIPT_NAME']);

 

That way even if a request is for something like /index.php/admin/categories.php/login.php the PHP_SELF will always be index.php (the first file in the URI).

 

Once that is patched then as people have pointed out, it comes down to a matter of bandwidth since you have removed the admin bypass exploit now.

 

Which the simplest concept is to kill the page if a malformed URL is called.

 

So the only other place to accurately and safetly determine a url with bad intent is via REQUEST_URI.

 

The combo in question, and you will find this in all attack url attempts, is this:

 

.php/login.php

 

The login.php is always called last or after another php file. There is no legimate reason for this combination so it can be safely banned.

 

So directly under the patched $PHP_SELF code above, add the following:

 

if  (strpos($_SERVER['REQUEST_URI'], ".php/login.php") !== false) {  
       die("give them your own message here"); // or do something else with it other than let it proceed
}

 

The amount of bandwidth used would be in bytes and depending on how long that die() sentence was.

 

i have seen what you show here (but only once or twice) on sites i manage. if you add this few lines of code to the two application_top.php, one under [admin-folder]/includes/, the other [yourshop-webroot]/includes/, they will go away:

$hacker_test = strtolower($_SERVER['PHP_SELF']);
if (substr_count($hacker_test,'.php') > 1 ) {
 header('Location: http://www.anti-hacker.info/contact.html');
}

remember you must add it at the very top of the two files, before any line of code runs.

ken

- 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

although i listed my code above and said it could also be added to the shop front application_top, i do not normally do it (add to shop front) as there is not report of such specific hack at shop side. just out of curiosity: example of two php files in one url at the store side? not in my memory.

as for php_self against script_name, i pointed out last year php self is in php itself, whereby same could not be said to script name, which is 'imported' into php, ie, some php installation may not have script name available. there is php, theres php self, same cant be said to script name.

from a practical point of view, the purpose is to avoid that specific hack. for some one who does not know much about coding, adding a few lines of code at the top of the file is much easier than digging into the file to locate and make change. both achieve the same but i love the fun to refer hackers to register with a anti hacker site! :)

ken

commercial support - unProtected channel, not to be confused with the forum with same name - open to everyone who need some professional help: either PM/email me, or go to my website (URL can be found in my profile).

over 20 years of computer programming experience.

Link to comment
Share on other sites

Yeah, nice idea that anti hacker site thing. There is a debate about what one should do with malformed URL requests. Some prefer not to piss the attacker off any further and just redirect them to the homepage, others like myself stick to the strict rule of banning the IP with as little amount of bandwidth used as possible (and CPU as well).

 

As for the issue of the double .php, when I first coded up osc_sec.php contrib, I was using that concept to ban attacks but the feedback I got basically showed me that there were too many either misconfigured oscommerce sites or whatever older configurations of oscommerce that I am not familiar with, that could lead to 2 counts of .php in the customer catalog side.

 

In theory it worked well, and on my own sites there was not problem, and certainly no accidental bans from URLs via the admin folder, however it just ended up banning too many legitimate visitors via the catalog folders on other sites, so I changed to:

 

if  (strpos($_SERVER['REQUEST_URI'], ".php/login.php") !== false) {   
       // do something else with it other than let it proceed 
}

 

Which focusses on the appended login.php which to date has been in my experience the primary method of bypassing admin permissions via the php_self misreporting the filename. So far that has been the winning method of blocking that specific attack aside from patching the PHP_SELF.

- 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

Would there be any reason why this cannot be handled on an Apache server by the .htaccess file?

 

For example:

 

RewriteEngine on
RewriteCond %{QUERY_STRING} \.php/login\.php
RewriteRule .* - [F]

I believe this approach will use the least amount of bandwidth and cpu time?

Link to comment
Share on other sites

Or to be doubly safe ...

 

RewriteEngine on
RewriteCond %{REQUEST_URI} \.php/login\.php [OR]
RewriteCond %{QUERY_STRING} \.php/login\.php
RewriteRule .* - [F]

Because on one of the osCommerce sites I manage I have seen these malformed URL requests come in as part of the query string, like this ...

 

/catalog/index.php?cPath=123/admin/file_manager.php/login.php

 

And in Apache REQUEST_URI is that part of the URI which follows the domain up to but not including the ? character of a query string. (Unlike in PHP, where it includes the query string.)

Link to comment
Share on other sites

Would there be any legitimate reason why login.php would be in a query string in the first place? even without the '.php/ before it?

 

Then the other question is does htaccess understand urlencoded query string content?

 

Example: urlencoded

 

www.somesite.com/index.php?cPath%3D123%2Fadmin%2Ffile_manager.php%2Flogin.php

 

Example 2: hexcode

www.somesite.com/index.php?%63%50%61%74%68%3d%31%32%33%2f%61%64%6d%69%6e%2f%66%69%6c%65%5f%6d%61%6e%61%67%65%72%2e%70%68%70%2f%6c%6f%67%69%6e%2e%70%68%70

 

Both read as:

www.somesite.com/index.php?cPath=123/admin/file_manager.php/login.php

- 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

Thanks to all respondents for your constructive input.

 

I didn't implement any changes yet, as there's one thing bothering me about trying to stop these visitors, and that's the risk that i will be in for some special and targeted treatment having bounced these requests, as and when i'm flying above the radar, as i think at present our sites are just part of an automated scripting execution, and not of real interest to these guys.

 

We are 3 ecommerce sites in 3 niche markets

 

I worked out the statistics of March :

 

10% of bandwidth used so far [ 1146 / 12000 ]

4% of bandwidth is suspicious [ 44 / 1146 ]

2720 suspicious page views [ average 16kb ]

84 different page entries [ highest 276 views ]

 

I think it's impractical to ban ip addresses as there are so many of them, although the facility is in our CP

 

I'm not sure what threat level these malformed visits are to us. So far the 3 sites are all intact

 

We're running RG off, [that's been flagged as a risk to us by our host], php 5.2.14 2.2-MS2, we removed file_manager & define_language, and have our renamed admin password protected.

 

If there's little risk of a hack, and the bandwidth is not an issue, is it safer to ignore it all, or does it need 'nipping in the bud now' ?

 

Any pragmatic advice appreciated

 

JohnDet

Link to comment
Share on other sites

i get at least 5 of these attack attemps a day i have one now as a matter of fact.

 

but i have secured my site and moved the admin area so its not where they are looking for it, this only started since i listed the site on the oscommerce shop listing lol.

 

its funny to watch them try all the backdoors they know and they are looking in the wrong area lol.

 

but it bugs me that there is no way of kicking them off or anything.

Link to comment
Share on other sites

Just discovered a new kind of attempt today. In Who's Online I see hackers trying to access //catalog/product_info.php/images/m32.php (always 2 slashes before catalog...not sure why) This just leads to a 'product not found' page.

 

I have security measures in place so I'm not worried, but still, what are they up to?

Link to comment
Share on other sites

I had very similar until I installed Bad Behavior then they slowly dried up and only reappear when I answer posts like this.

 

If you ban hackers (or spammers) at the time they make the attempt, they do get the message and do give up - well move on to easier pickings anyway

 

Oh and you never need to worry what they are up to because you know the answer - getting banned :lol:

My store is currently running Phoenix 1.0.3.0

I'm currently working on 1.0.7.2 and hope to get it live before 1.0.8.0 arrives (maybe 🙄 )

I used to have a list of add-ons here but I've found that with the ones that supporters of Phoenix get any other add-ons are not really neccessary

Link to comment
Share on other sites

Hello,

I've also noticed just this past week the same types of hits mainly...

/index.php/admin/file_manager.php/login.php and

/account.php/admin/file_manager.php/login.php showing up in our whos_online.

 

I've installed the Bad Behavior contrib and it appears to working with one notable exception, it doesn't catch these URLs. Now I've moved our admin and password protected the directory long ago so theres no threat, but I basically want these people to go away.

 

Is there a way using the RewriteCond clause in the .htacess to throw any URLs containing file_manager or even /admin to the ban.php

 

I've tried...

RewriteCond %{REQUEST_URI} ^(.*)file_manager$ [NC,OR]

RewriteCond %{QUERY_STRING} ^(.*)file_manager$ [NC,OR]

RewriteCond %{REQUEST_URI} ^(.*)file_manager$ [NC,OR]

RewriteCond %{SCRIPT_FILENAME} ^(.*)file_manager$ [NC,OR]

RewriteCond %{PATH_INFO} ^(.*)file_manager$ [NC,OR]

 

None seem to check the above URLs. Thanks for any suggestions?

Link to comment
Share on other sites

Frank,

 

I added this little snippet of code to the .htaccess file and it stopped ALL bad URL requests.

 

 

RewriteEngine on

RewriteCond %{REQUEST_URI} \.php/login\.php [OR]

RewriteCond %{QUERY_STRING} \.php/login\.php

RewriteRule .* - [F]

 

 

(submitted by Jeff in post #11)

 

 

 

 

Chris

Link to comment
Share on other sites

Hello,

I've also noticed just this past week the same types of hits mainly...

/index.php/admin/file_manager.php/login.php and

/account.php/admin/file_manager.php/login.php showing up in our whos_online.

 

I've installed the Bad Behavior contrib and it appears to working with one notable exception, it doesn't catch these URLs. Now I've moved our admin and password protected the directory long ago so theres no threat, but I basically want these people to go away.

 

Is there a way using the RewriteCond clause in the .htacess to throw any URLs containing file_manager or even /admin to the ban.php

 

I've tried...

RewriteCond %{REQUEST_URI} ^(.*)file_manager$ [NC,OR]

RewriteCond %{QUERY_STRING} ^(.*)file_manager$ [NC,OR]

RewriteCond %{REQUEST_URI} ^(.*)file_manager$ [NC,OR]

RewriteCond %{SCRIPT_FILENAME} ^(.*)file_manager$ [NC,OR]

RewriteCond %{PATH_INFO} ^(.*)file_manager$ [NC,OR]

 

None seem to check the above URLs. Thanks for any suggestions?

 

Frank,

 

what you have done is limited the conditions to file_manager by adding $ to the end however the following will do what you ask

 

RewriteRule \.php/login\.php bad_conduct/ban.php [NC,L]

 

added after

 

RewriteRule file_manager\.php$ bad_conduct/ban.php [NC,L]

My store is currently running Phoenix 1.0.3.0

I'm currently working on 1.0.7.2 and hope to get it live before 1.0.8.0 arrives (maybe 🙄 )

I used to have a list of add-ons here but I've found that with the ones that supporters of Phoenix get any other add-ons are not really neccessary

Link to comment
Share on other sites

It will keep you out as well plus it will only affect a request ending in login.php most hackers continue after that ie /index.php?cPath=26/admin/categories.php/login.php?cPath=&action=new_product_preview

 

use this

 

RewriteCond %{REQUEST_URI} \.php/login\.php [OR]

RewriteCond %{QUERY_STRING} \.php/login\.php

RewriteRule .* - [F]

My store is currently running Phoenix 1.0.3.0

I'm currently working on 1.0.7.2 and hope to get it live before 1.0.8.0 arrives (maybe 🙄 )

I used to have a list of add-ons here but I've found that with the ones that supporters of Phoenix get any other add-ons are not really neccessary

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...