full-disclosure - Interspire shopping cart: incorrect permissions (stupid and trivial)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Wed, 22 Feb 2012 11:15:33 +0200
From: Jan van Niekerk <jvnkrk@...il.com>
To: full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Interspire shopping cart: incorrect permissions
	(stupid and trivial)

=========
Product:
Interspire Shopping Cart

=========
Problem:
config/config.php MUST be httpd-readable (inter-domain read access
permitted, which is a problem on shared hosting)

=========
About product:
What is Interspire Shopping Cart?
Interspire Shopping Cart is the most feature rich, all-in-one shopping
cart software available. It has an enterprise-grade feature set and is
trusted by more than 15,000 businesses in over 65 countries.

=========
Details:
This software uses the permissions for config/config.php to determine
the permissions for uploaded product image files.  Since images have
to be readable by the web server user, the config/config.php file must
also be readable by the web server user.  This means that for almost
all shared hosting configurations, config/config.php is insecure -- by
design.  You can set secure permissions on config.php, but this will
invariably cause static images to be unreadable by the web server.
Effectively this means that wherever you find Interspire shopping
cart, you can take over administration as another user on the same
system.

=========
Vendor response:
"I am aware of how hackers can read configuration files if they have
an account on the same server. However, this is an issue for hosting
companies, not for us. We are not mandating anything. It is just a
fact that the large majority of hosting companies do not run suphp."
"It does not look like we are going to agree on this. In my view, this
is entirely a hosting related issue, one that can be "fixed" by
modifying the config/config.php permissions."

=========
Exploit:
Look for /home/*/public_html/config/config.php file, or make a symlink
to it and read it via the web server.  The interesting bits are ...
$GLOBALS['ISC_CFG']["dbServer"] = 'localhost';
       $GLOBALS['ISC_CFG']["dbUser"] = 'somedatabse_user';
       $GLOBALS['ISC_CFG']["dbPass"] = 'somesecret';
       $GLOBALS['ISC_CFG']["dbDatabase"] = 'somedatabase_name';
       $GLOBALS['ISC_CFG']["tablePrefix"] = 'isc_';
       Once you have database access, application authentication data
is in the table isc_users (md5 auth if you want to google it, or you
can set your own password and lock the regular user out).

=========
Work-arounds:

1. Have a chat with your hosting company and ask them not to let
anyone else on the server you are sharing be hacked.  (Recommended by
vendor.)

2. In lib/init.php, the following HACK tells the software to ignore
the permissions on config/config.php.  After this you can set the
permissions securely without breaking the application:

       //define('ISC_WRITEABLE_FILE_PERM', fileperms(ISC_CONFIG_FILE));
       //define('ISC_WRITEABLE_DIR_PERM', fileperms(dirname(ISC_CONFIG_FILE)));
       define('ISC_WRITEABLE_FILE_PERM', 0644);
       define('ISC_WRITEABLE_DIR_PERM', 0755);

3. Use other software (e.g. oscommerce, ha ha :)

4. Unpredictable DocumentRoot will help. Chroot of other users will
seem to help, provided symbolic links are not permitted.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/