Jump to content

Archived

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

khaos119

Serious Hole Found in osCommerce!

Recommended Posts

Hi, We had the same issue this morning.

What line does this patch go on? I'm assuming the addition of this code is in the mail.php file, correct?

Thank you for providing a solution to this problem. :)

There was a better suggestion of code to put in application_top.php. If you only put that code in mail.php it does what it is supposed to do but there are other admin files that have the same vulnerability so you won't protect yourself. You really need to change the name of the admin directory and protect it with .htaccess anyway.


www.jyoshna.com. Currently using OsC with STS, Super Download Store, Categories Descriptons, Manufacturers Description, Individual Item Status, Infopages unlimited, Product Sort, Osplayer with flashmp3player, Product Tabs 2.1 with WebFx Tabpane and other bits and pieces including some I made myself. Many thanks to all whose contributions I have used!

Share this post


Link to post
Share on other sites

Marisa,

 

Someone suggested this: in admin/includes/application_top.php change

 

this line

if ($current_page != FILENAME_LOGIN) { 

 

to this

if(basename($_SERVER['SCRIPT_FILENAME']) != FILENAME_LOGIN && basename($_SERVER['SCRIPT_FILENAME']) != FILENAME_PASSWORD_FORGOTTEN){ 

 

We added this and it works just fine by not allowing access to any page if not logged in. Changing the admin dir name doesn't help anything because that can be determined easily.

 

htaccess is certainly a better way of protecting the admin directory, my client chose not to have it to avoid 2 logins.

Share this post


Link to post
Share on other sites

Changing the admin dir name doesn't help anything because that can be determined easily.

How do you determine the new name of the admin directory?

Share this post


Link to post
Share on other sites

There was an error in the code in my previous post. Below is what I actually use:

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

The code should be added to [admin]/includes/application_top.php, at the very top, ie, just after the opening php tag <?php.

Of course, you can replace http://www.xxx.html with any url you like, eg, your own home page.

Ali

 

Does this code stop the admin name being included in emails? If not, what does?


I'm feeling lucky today......maybe someone will answer my post!

I do try and answer a simple post when I can just to give something back.

------------------------------------------------

PM me? - I'm not for hire

Share this post


Link to post
Share on other sites

Does this code stop the admin name being included in emails? If not, what does?

No. It is a simple but effective way to foil the attempt to exploit this hole as highlighted in this thread such as: [admin]/customers.php/login.php or for filemanarer.php/login.php or [admin]/whateverfilename.php/lonin.php.

After adding the code you can test it yourself.

The admin name could be in the any email that is sent from admin but not from the shop eg, the first email sent to customers when they place an order. I got a feeling the admin name could only be excluded from emails sent from within admin with the help of your host but theu are unlikely do it on a shared server.

Alternatively, the shop could be modified to move the order update email from admin to the shop front so that the admin path wont be exposed.

Ali

Share this post


Link to post
Share on other sites

I identified the fix for the "login hack" back in July and it is far simpler than the suggestions here.

 

In admin/includes/application_top.php find this code beginning around line 124:

 

// redirect to login page if administrator is not yet logged in
 if (!tep_session_is_registered('admin')) {
   $redirect = false;

   $current_page = basename($PHP_SELF);

 

 

and change to:

 

 

// redirect to login page if administrator is not yet logged in
 if (!tep_session_is_registered('admin')) {
   $redirect = false;

   $current_page = basename($_SERVER['SCRIPT_NAME']);

 

$_SERVER['SCRIPT_NAME'] is reliable on all server types .. all the various connotations of PHP_SELF are known to be "unreliable/hackable/spoofable".

 

osCommerce itself and many contributions (Which is why header tags throws errors with Ultimate Seo Urls 5 in standard mode) .. rely on PHP_SELF and there is a possibility if you have installed a contribution such as this .. or any other that relies on the return of PHP_SELF that you may get problems/redirect loops .. the solution is to replace all instances of $PHP_SELF or $_SERVER['PHP_SELF'] or $HTTP_SERVER_VARS['PHP_SELF'] with basename( $_SERVER['SCRIPT_NAME'] ).

 

PHP_SELF is used (in the main) to return the current file name and for this purpose should NOT be used .. $_SERVER['SCRIPT_NAME'] performs the same function but reliably ..

 

basename( $_SERVER['SCRIPT_NAME'] ) is what will return a valid filename for the currently executing file.

Share this post


Link to post
Share on other sites

No. It is a simple but effective way to foil the attempt to exploit this hole as highlighted in this thread such as: [admin]/customers.php/login.php or for filemanarer.php/login.php or [admin]/whateverfilename.php/lonin.php.

This hole was in RC's with database driven login the "php self" hole - right?

 

 

The admin name could be in the any email that is sent from admin but not from the shop eg, the first email sent to customers when they place an order. I got a feeling the admin name could only be excluded from emails sent from within admin with the help of your host but theu are unlikely do it on a shared server.

Alternatively, the shop could be modified to move the order update email from admin to the shop front so that the admin path wont be exposed.

So we basically need to stop sending emails from admin now? I think many will be interested to know how to fix this. Now it's public more will get hacked.


I'm feeling lucky today......maybe someone will answer my post!

I do try and answer a simple post when I can just to give something back.

------------------------------------------------

PM me? - I'm not for hire

Share this post


Link to post
Share on other sites

I just ran into this problem today on one of my customer sites. There is a better fix than the one posted above, here is what I did:

 

around line 142 of admin/includes/application_top.php

 

replace:

 

if (basename($PHP_SELF) != FILENAME_LOGIN && basename($PHP_SELF) != FILENAME_PASSWORD_FORGOTTEN) {

tep_admin_check_login();

}

 

with:

 

if(basename($_SERVER['SCRIPT_FILENAME']) != FILENAME_LOGIN && basename($_SERVER['SCRIPT_FILENAME']) != FILENAME_PASSWORD_FORGOTTEN) {

tep_admin_check_login();

}

 

 

What if the code to replace is not there???

 

Here is what my "around line 142" looks like.

 

// redirect to login page if administrator is not yet logged in
 if (!tep_session_is_registered('admin')) {
   $redirect = false;

   $current_page = basename($PHP_SELF);

   if ($current_page != FILENAME_LOGIN) {
     if (!tep_session_is_registered('redirect_origin')) {
       tep_session_register('redirect_origin');

       $redirect_origin = array('page' => $current_page,
                                'get' => $HTTP_GET_VARS);
     }

     $redirect = true;
   }

   if ($redirect == true) {
     tep_redirect(tep_href_link(FILENAME_LOGIN));
   }

   unset($redirect);
 }

Share this post


Link to post
Share on other sites

What if the code to replace is not there???

 

Here is what my "around line 142" looks like.

 

// redirect to login page if administrator is not yet logged in
 if (!tep_session_is_registered('admin')) {
   $redirect = false;

   $current_page = basename($PHP_SELF);

 

Please re-read FWR Media's Post


I'm feeling lucky today......maybe someone will answer my post!

I do try and answer a simple post when I can just to give something back.

------------------------------------------------

PM me? - I'm not for hire

Share this post


Link to post
Share on other sites

This hole was in RC's with database driven login the "php self" hole - right?

It exists only in osc rc1 or rc2a which instroduce admin login. For any previous versions you either .htaccess protect it or you don't in which case your admin is open to the world, so there is no point of any loophole to exploit.

A word about the PHP_SEFT as against SCRIPT_NAME:

Quite the opposite is true. The latter is defined and only available in cgi 1.1, that means only available on servers that run PHP in cgi mode and with the right version, whereas the PHP_SELF, as the name may suggest, comes with PHP, so as long as you are coding in php and the server runs php, then it is ALWAYS there. You would be stupid to replace PHP_SELF with something else. If you got a problem with PHP_SELF, then that indicates your code logic is faulty.

I have been using the code I posted in this thread for almost one year now and it never fails on different hosts/servers.

Ali

Share this post


Link to post
Share on other sites

A word about the PHP_SEFT as against SCRIPT_NAME:

Quite the opposite is true. The latter is defined and only available in cgi 1.1, that means only available on servers that run PHP in cgi mode and with the right version, whereas the PHP_SELF, as the name may suggest, comes with PHP, so as long as you are coding in php and the server runs php, then it is ALWAYS there. You would be stupid to replace PHP_SELF with something else. If you got a problem with PHP_SELF, then that indicates your code logic is faulty.

 

Ali

 

Absolute rubbish.

Share this post


Link to post
Share on other sites

So we basically need to stop sending emails from admin now?

I think you should first determine whether or not your admin emails include the name of your admin folder in the headers. Mine do not. Hopefully someone can figure out why some apparently do and others do not. It would be helpful, I think, for those who have the problem to share some information about their configurations and operating environments (server information) to help isolate the cause of the problem.

Share this post


Link to post
Share on other sites

I checked before my last post and I can see it in emails... so it will give away a clue to the u know who's... I imagine it's OSC behaviour or do we blame the hosts? I'm not really interested in giving them any more info on the holes until there is a fix to hide the admin name.


I'm feeling lucky today......maybe someone will answer my post!

I do try and answer a simple post when I can just to give something back.

------------------------------------------------

PM me? - I'm not for hire

Share this post


Link to post
Share on other sites

I checked before my last post and I can see it in emails... so it will give away a clue to the u know who's... I imagine it's OSC behaviour or do we blame the hosts? I'm not really interested in giving them any more info on the holes until there is a fix to hide the admin name.

If you change the name of the admin folder and stop sending out admin emails until the cause and solution are determined, I would think that you would minimize the risk to your site. I would imagine it's going to be difficult to come up with a solution that directly addresses the root cause until the root cause is known. Maybe the people who have the problem can figure out both the cause and the solution without sharing any information with those of us who do not have the problem. I hope so and wish you luck.

Share this post


Link to post
Share on other sites

Just add this to your aplication_top.php in admin/includes

 

if(basename($_SERVER['SCRIPT_FILENAME']) != FILENAME_LOGIN && basename($_SERVER['SCRIPT_FILENAME']) !== false){ header('Location: /admin/');

}

 

 

that will fix the issue and redirect to whatever you give in the header('Location: /admin/');

Share this post


Link to post
Share on other sites

Just add this to your aplication_top.php in admin/includes

 

if(basename($_SERVER['SCRIPT_FILENAME']) != FILENAME_LOGIN && basename($_SERVER['SCRIPT_FILENAME']) !== false){ header('Location: /admin/');

}

 

 

that will fix the issue and redirect to whatever you give in the header('Location: /admin/');

By "fix the issue" do you mean it will stop the admin path from being disclosed in outgoing admin emails?

Share this post


Link to post
Share on other sites

$_SERVER['SCRIPT_NAME'] is reliable on all server types .. all the various connotations of PHP_SELF are known to be "unreliable/hackable/spoofable".

 

osCommerce itself and many contributions (Which is why header tags throws errors with Ultimate Seo Urls 5 in standard mode) .. rely on PHP_SELF and there is a possibility if you have installed a contribution such as this .. or any other that relies on the return of PHP_SELF that you may get problems/redirect loops .. the solution is to replace all instances of $PHP_SELF or $_SERVER['PHP_SELF'] or $HTTP_SERVER_VARS['PHP_SELF'] with basename( $_SERVER['SCRIPT_NAME'] ).

 

PHP_SELF is used (in the main) to return the current file name and for this purpose should NOT be used .. $_SERVER['SCRIPT_NAME'] performs the same function but reliably ..

 

basename( $_SERVER['SCRIPT_NAME'] ) is what will return a valid filename for the currently executing file.

Utterly useless and hopeless, not even qualified for rubbish, which could be recycled. Useless/hopeless can only be good for landfill.

Ali

Share this post


Link to post
Share on other sites

How do you determine the new name of the admin directory?

 

 

You can call it whatever you want, you just have to change the defined vars in your config. Changing this directory name doesn't do much for security, the headers in emails sent from the admin contain the directory name.

Share this post


Link to post
Share on other sites

... the headers in emails sent from the admin contain the directory name.

Mine do not.

Share this post


Link to post
Share on other sites

Mine do not.

How do you check your headers?


The Coopco Underwear Shop

 

If you live to be 100 years of age, that means you have lived for 36,525 days. Don't waste another, there aren't many left.

Share this post


Link to post
Share on other sites

Just add this to your aplication_top.php in admin/includes

 

if(basename($_SERVER['SCRIPT_FILENAME']) != FILENAME_LOGIN && basename($_SERVER['SCRIPT_FILENAME']) !== false){ header('Location: /admin/');

}

 

 

that will fix the issue and redirect to whatever you give in the header('Location: /admin/');

 

there are two issues in this thread -

1) the login h*ck

2) the email headers

 

which is this fix for? I would state how to check headers but think someone needs to come up with a fix first before the next wave of h*cks.

 

Sorry I am not a php guru... seems little point in everyone banging on about changing admin name if it's so easy to find.


I'm feeling lucky today......maybe someone will answer my post!

I do try and answer a simple post when I can just to give something back.

------------------------------------------------

PM me? - I'm not for hire

Share this post


Link to post
Share on other sites

seems little point in everyone banging on about changing admin name if it's so easy to find.

 

 

That would be a mistake, for this to work for a hacker they have to set up a accounrt & provide a valid e-mail, there's not many thay would do that as far as I am aware.

 

Many people that get hacked r through automated scripts usually, those search for the common ways in, changing admin name will defeat them.


Sam

 

Remember, What you think I ment may not be what I thought I ment when I said it.

 

Contributions:

 

Auto Backup your Database, Easy way

 

Multi Images with Fancy Pop-ups, Easy way

 

Products in columns with multi buy etc etc

 

Disable any Category or Product, Easy way

 

Secure & Improve your account pages et al.

Share this post


Link to post
Share on other sites

Personally I don't see changing the name of the admin directory, or having it appear in email headers, as such a big deal. Security that relies only on changing a path name from the ordinary is not real security. More important is to plug the real holes. Some of the methods described here can plug the problem described at the beginning of this topic, the question is whether there are also other vulnerabilities in the admin files that require the use of .htaccess to protect them? This (use of .htaccess) was a change recommended to plug an undisclosed problem sometime before this particular problem was pointed out, I am left wondering whether this is in fact the same problem or whether there are others/is another?

 

So far as removing the headers that give away the directory name in admin emails are concerned, I do not think this problem is created by osC. I don't think osC is telling the server what headers to use and I would presume it is the server's mailserver that does this, therefore any solution lies outside osC. But personally, as above, I would rather

fix the file vulnerabilities than rely on trying to hide them as a solution.


www.jyoshna.com. Currently using OsC with STS, Super Download Store, Categories Descriptons, Manufacturers Description, Individual Item Status, Infopages unlimited, Product Sort, Osplayer with flashmp3player, Product Tabs 2.1 with WebFx Tabpane and other bits and pieces including some I made myself. Many thanks to all whose contributions I have used!

Share this post


Link to post
Share on other sites

a hacker they have to set up a accounrt & provide a valid e-mail,

 

well maybe I'm just being paranoid (I am female after all) but it is possible that they would create an account with a valid email. So to be safer, isn't it better to stop it being public? They will just find more and more ways in, that's what they get kicks from.

 

I have opened a ticket with my host. I would think that giving away some login details was a risk, no?


I'm feeling lucky today......maybe someone will answer my post!

I do try and answer a simple post when I can just to give something back.

------------------------------------------------

PM me? - I'm not for hire

Share this post


Link to post
Share on other sites
I am left wondering whether this is in fact the same problem or whether there are others/is another?

 

 

It is the same issue as was addressed b4, as I already pointed out in my ealier post here, and yes certainly you must use the methods detailed here to secure your admin, that includes renaming it, its an easy process & you should take all measures to keep the buggers out, not just some, remember if you only use one securty method, then there is only one they need to get around. wink.gif

 

 

 

I would also point out if you look at the latest base64 hack, that script is looking for osC sites with an 'admin' dir, so just the rename blocks its initial probe.


Sam

 

Remember, What you think I ment may not be what I thought I ment when I said it.

 

Contributions:

 

Auto Backup your Database, Easy way

 

Multi Images with Fancy Pop-ups, Easy way

 

Products in columns with multi buy etc etc

 

Disable any Category or Product, Easy way

 

Secure & Improve your account pages et al.

Share this post


Link to post
Share on other sites

×