Jump to content

Archived

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

khaos119

Serious Hole Found in osCommerce!

Recommended Posts

Its a bit of a double up, but it will work fine.

 

Be sure to at least have the following in your admin/includes/application_top.php file to replace the original faulty code.

 

  // set php_self in the local scope 
 if( !isset( $PHP_SELF ) ) { 
   if ( @phpversion() >= "5.0.0" && ( !ini_get("register_long_arrays" ) || @ini_get("register_long_arrays" ) == "0" || strtolower(@ini_get("register_long_arrays" ) ) == "off" ) ) $HTTP_SERVER_VARS = $_SERVER; 
   $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' ] ); 
 } 

 

 

yes, that´s part your osc_sec contribution I already had in place:

 

admin/includes/application_top.php

 

// set php_self in the local scope
// replaced for 7834 OSC_SEC:
//  $PHP_SELF = (isset($HTTP_SERVER_VARS['PHP_SELF']) ? $HTTP_SERVER_VARS['PHP_SELF'] : $HTTP_SERVER_VARS['SCRIPT_NAME']);
// BOF 7834 OSC_SEC
// set php_self in the local scope
 if( !isset( $PHP_SELF ) ) {
   if ( @phpversion() >= "5.0.0" && ( !ini_get("register_long_arrays" ) || @ini_get("register_long_arrays" ) == "0" || strtolower(@ini_get("register_long_arrays" ) ) == "off" ) ) $HTTP_SERVER_VARS = $_SERVER;
   $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' ] );
 }
// EOF 7834 OSC_SEC

 

... more than twice around the corner, I know. But it helps to remember what and why ...

 

Thanks again for your effort. It´s appreciated!

tom

Share this post


Link to post
Share on other sites

I came across another thread proposing a fix and wondered if any of the PHP Guru's could make comment on it? Will it remove the offending admin name from email headers?

 

X-PHP-Script fix

 

Like Tigergirl - I would like to know more about this as well - any views?

 

Thanks

 

 

I thinks that will remove admin folder exposed when sending email. Here another link with similar solution to obfuscate X-PHP-Script : Preventing X-PHP-Script Exposure of Variables.

 

We can make generic modification to tep_mail function in (CATALOG/ADMIN)/includes/general.php

 

 function tep_mail($to_name, $to_email_address, $email_subject, $email_text, $from_email_name, $from_email_address) {
   if (SEND_EMAILS != 'true') return false;

   global $PHP_SELF;
   //obfuscate url address
   $tmpSelf = $PHP_SELF;
   $tmpAddr = $_SERVER['REMOTE_ADDR'];
   $_SERVER['PHP_SELF'] = "/";
   $_SERVER['REMOTE_ADDR'] = $_SERVER['SERVER_ADDR'];
   $_SERVER['X_PHP_SCRIPT'] = $_SERVER['REMOTE_ADDR'] . $_SERVER['PHP_SELF'];

   // Instantiate a new mail object
   $message = new email(array('X-Mailer: osCommerce'));

   // Build the text version
   $text = strip_tags($email_text);
   if (EMAIL_USE_HTML == 'true') {
  $message->add_html($email_text, $text);
   } else {
  $message->add_text($text);
   }
   // Send message
   $message->build_message();
   $message->send($to_name, $to_email_address, $from_email_name, $from_email_address, $email_subject);

   //revert default value
   unset($_SERVER['X_PHP_SCRIPT']);
   $_SERVER['REMOTE_ADDR'] = $tmpAddr;
   $_SERVER['PHP_SELF'] = $tmpSelf;
 }

 

@zaenal

Share this post


Link to post
Share on other sites

Moving the admin directory or changing its name is a bit like putting a painting in front of the hidden wall safe. A burglar discovering the wall safe behind the picture does not automatically mean that the safe can be cracked.

 

However, hiding a wall safe => with faulty locking mechanism, behind a wall painting is rather risky, as the first priority in that situation, as with the outdated versions of osCommerce situation, is to fix the faulty locking mechanism.

 

Once that is completed successfully then hiding the admin directory from wouldbe attackers either via changing the name of the admin directory or adding HTTP Basic Authentication (or both) would be the finishing layer of security on your site.

 

osCommerce Security Hole Fix: http://forums.oscommerce.com/topic/380144-fixing-the-admin-login-bypass-exploit/

osC_Sec Security addon: http://addons.oscommerce.com/info/7834


- 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

Share this post


Link to post
Share on other sites

I have installed "Ultimate Seo Urls 5" and I understand it takes care of osCommerce Security Hole in application_top.php (correct?)

 

Is there still a need to install osC_Sec Security addon?

 

Thanks!

Share this post


Link to post
Share on other sites

@@callenords,

 

NO, Ultimate SEO URL's does not fix ANY security issues with osCommerce. If you have v2.2, I suggest reading and installing the security contributions mentioned in the Security Thread

 

If you are using v2.3.1, there is no need to install ANY contributions but you can if you wish.

 

 

 

Chris


:|: Was this post helpful ? Click the LIKE THIS button :|:

 

See my Profile to learn more about add ons, templates, support plans and custom coding (click here)

Share this post


Link to post
Share on other sites

In my opinion there are two parts to the security fix often called ( by me ) the admin login bypass exploit, in the 2.2 range of osCommerce sites.

 

1/ patch the admin login process which can be bypassed in the 2.2 range

2/ patch the $PHP_SELF code in application_top.php which is reports login.php as the $PHP_SELF rather than administrators.php when the URL is malformed like /admin/administrators.php/login.php

 

If you do either one of those, the admin login bypass exploit will cease to work. IMO, do both of them.

 

That takes care of the biggest security hole in that range of osCommerce systems.

 

From memory, Ultimate SEO URLs 5 by FWR Media has a fix to the $PHP_SELF code in it, which will prevent the misreporting thus prevent the malformed URL 'trick' from working, however the official fix is 1/

 

If you have installed that version of USU5 then test it out for yourself.

 

While logged out of your admin section, go to http://www.yoursite.com/admin/administrators.php/login.php and see if you are redirected to the admin login.php page, or whether you are able to see a rather distorted version of the administrators.php page.

 

If you get the distorted version of that administrators.php page, then add at least the first patch I listed above, or if you want an almost all in one patch up, then install osC_Sec.

 

Putting htaccess basic authentication protection on your admin directory is the first place to start though. version 2.3.1 has htaccess inbuilt into the install process. However I recommend site owners use a different set of login credentials for htaccess logins to those used in their admin user logins. ( 2.3.1 has them both the same probably for reasons of convenience ).


- 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

Share this post


Link to post
Share on other sites

my problem is I'm installing osc_sec and I find that I do change a variable and change for this $ PHP_SELF = usu5_base_filename (); in application_top.php

 

Code: Select all

/ / Set PHP_SELF in the local scope

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

 

IMPORTANT: Remove or comment out the line from Above Both application_top.php files and replace Entire line with:

 

/ / Set PHP_SELF in the local scope

if (isset ($ PHP_SELF)) {

if (@ phpversion ()> = "5.0.0" && (! ini_get ("register_long_arrays") | | @ ini_get ("register_long_arrays") == "0" | | strtolower (@ ini_get ("register_long_arrays")) == "off")) $ HTTP_SERVER_VARS = $ _SERVER;

$ 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']);

}

 

 

 

I have installed ultimate-seo-urls-5 which is the variable $ PHP_SELF = usu5_base_filename this (), which is the substitution ask me, as I do to be compatible with the 2? thanks!

and tested this

/// following section replaced for 7704 ultimate seo urls pro
// set php_self in the local scope
/**  if (!isset($PHP_SELF)) $PHP_SELF = $HTTP_SERVER_VARS['PHP_SELF'];**/
// End replacement 
// BOF 7704 ultimate seo urls pro
/**
 * ULTIMATE Seo Urls 5 PRO by FWR Media
 * function to return the base filename
 */
 function usu5_base_filename() {
   // Probably won't get past SCRIPT_NAME unless this is reporting cgi location
   $base = new ArrayIterator( array( 'SCRIPT_NAME', 'PHP_SELF', 'REQUEST_URI', 'ORIG_PATH_INFO', 'HTTP_X_ORIGINAL_URL', 'HTTP_X_REWRITE_URL' ) );
   while ( $base->valid() ) {
  if ( array_key_exists(  $base->current(), $_SERVER ) && !empty(  $_SERVER[$base->current()] ) ) {
    if ( false !== strpos( $_SERVER[$base->current()], '.php' ) ) {
	  preg_match( '@[a-z0-9_]+\.php@i', $_SERVER[$base->current()], $matches );
	  if ( is_array( $matches ) && ( array_key_exists( 0, $matches ) )
							    && ( substr( $matches[0], -4, 4 ) == '.php' )
							    && ( is_readable( $matches[0] ) ) ) {
	    return $matches[0];
	  }
    }
  }
  $base->next();
   }
   // Some odd server set ups return / for SCRIPT_NAME and PHP_SELF when accessed as mysite.com (no index.php) where they usually return /index.php
   if ( ( $_SERVER['SCRIPT_NAME'] == '/' ) || ( $_SERVER['PHP_SELF'] == '/' ) ) {
  return 'index.php';
   }
   // Return the standard RC3 code
   return ( ( ( strlen( ini_get( 'cgi.fix_pathinfo' ) ) > 0) && ( (bool)ini_get( 'cgi.fix_pathinfo' ) == false ) ) || !isset( $_SERVER['SCRIPT_NAME'] ) ) ? basename( $_SERVER['PHP_SELF'] ) : basename( $_SERVER['SCRIPT_NAME'] );
 } // End function
// set php_self in the local scope
 $PHP_SELF = usu5_base_filename();
// BOF 7834 OSC_SEC
 // set php_self in the local scope
 if( !isset( $PHP_SELF ) ) {
   if ( @phpversion() >= "5.0.0" && ( !ini_get("register_long_arrays" ) || @ini_get("register_long_arrays" ) == "0" || strtolower(@ini_get("register_long_arrays" ) ) == "off" ) ) $HTTP_SERVER_VARS = $_SERVER;
   $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' ] );
 }
// EOF 7834 OSC_SEC 
// EOF 7704 ultimate seo urls pro
// BOF 5752 Security Pro 2.0.7

but I get this error Error 310 (net::ERR_TOO_MANY_REDIRECTS):

Share this post


Link to post
Share on other sites

yes its compatible, the ultimate solution it´s osc_sec 5.0.6, the 5.0.5 have problems with redirect, 5.0.6 perfect

Share this post


Link to post
Share on other sites

Because ULTIMATE Seo Urls 5 PRO by FWR Media already sets the correct $PHP_SELF code then it is fine to leave out that part of the code changes in the osC_Sec instructions.


- 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

Share this post


Link to post
Share on other sites

×