Don't have an account yet? You can create one, it is free, just click here
as a registered user you have some advantages like free downloads, comments and posting on our forums, depending upon this site's configuration and options.
Joined: July 17, 2004
Posts: 254
Location: Victoria, British Columbia
Member
Posted:
Sep 07, 2008 - 10:46 AM
Post subject: Security issues
I have about 30 domains running various releases of MDPro and recently those domains were hacked. I deleted all of them and during the restore process they were hit again. Rebuilding 30 domains is a major pain.
First and foremost having any directory with permissions set to 777 is dangerous. Hackers can use the C99 shell to gain access the destroy the sites.
I was talking with a tech manager with my hosting company and he made a suggestion that I will pass along for discussion. Moodle does not keep writeable directories (777) inside the domain but for security reasons in the root instead
He has suggested the following. Create a directory called "files/" in the root folder, then create another directory with the domain name and then sub-dirs so that the 777 directories are not located within the domain folders but outside in "files/". Moodle does this for the 777 directories and writable files
Do the same for all 777 directories used by the php code
What do you think of his suggestion? Will this work to make MDpro more secure?
With 1.083 in the early stages it might be worth implementing.
David
dpottier MD user level 5
Joined: July 17, 2004
Posts: 254
Location: Victoria, British Columbia
bannato
Posted:
Sep 07, 2008 - 12:02 PM
Forgot this bit in first post. It is the message from the admin I spoke with
Quote:
The security of the website I would recommend any folder that needs 777 permissions to be moved to a folder outside of the domain root. This way it can still have the permissions without being web associable without a script. I would also use the /tmp folder when you are needing to write session data or temp files. It is accessible by everyone but file within can only be accessed if you know the file directly.
the /tmp directory he refers to is the unix /tmp, like /usr/local/tmp
not one created within the MDPro directory
David
TiMax Project Manager
Joined: July 31, 2003
Posts: 1560
Location: Quebec - Canada
Posted:
Sep 07, 2008 - 03:25 PM
First of all, you use php 4.3 this is a very old php version, unsupported and with several bugs, so please update.
then, you don't tell us witch mdpro version you use.
then where is the logs, what the hackers have done to crack your site
please come back with more info's
_________________ TiMaxMAX s.o.s.Fantasia e dinamicità Italiane, qualità e servizi Canadesi Web Services, hosting ed housing professionali
dpottier MD user level 5
Joined: July 17, 2004
Posts: 254
Location: Victoria, British Columbia
bannato
Posted:
Sep 07, 2008 - 03:50 PM
Currently in the process of moving all of the domains to updated PhP, MySQL, Apache, etc
As I have been using MDPro since the beginning the sites have not been updated, mostly due to loss of many modules if I do update them. A guess would be a range from 1.07 to 1.082
This afternoon I managed to notice one of the sites was hacked while I was talking to a tech manager. I am now analysing 3000 lines of log files with httpd access
What we were lucky enough to catch was the hacker's IP. I will have this dealt with by some law enforcement contacts in his country.
I will post the hackers access from the logs when I locate it.
TiMax wrote:
First of all, you use php 4.3 this is a very old php version, unsupported and with several bugs, so please update.
then, you don't tell us witch mdpro version you use.
then where is the logs, what the hackers have done to crack your site
please come back with more info's
dpottier MD user level 5
Joined: July 17, 2004
Posts: 254
Location: Victoria, British Columbia
bannato
Posted:
Sep 07, 2008 - 03:56 PM
Post subject: htaccess file
A starting point to possibly make security better for all of us.
register_globals should be OFF not set to register_globals On
added in this format
php_flag register_globals OFF
Something like the following should be added to all php files in the modules:
** ensure this file is being included by a parent file and stop direct linking */
defined( '_VALID_MOS' ) or die( 'Direct Access to this location is not allowed.' );
.htaccess
########## Begin - Rewrite rules to block out some common exploits
# Register Globals
php_flag register_globals OFF
#
# Block out any script trying to set a Config value through the URL
RewriteCond %{QUERY_STRING} config_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (\<3C>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]
#
########## End - Rewrite rules to block out some common exploits
dpottier MD user level 5
Joined: July 17, 2004
Posts: 254
Location: Victoria, British Columbia
bannato
Posted:
Sep 08, 2008 - 10:22 AM
I notice that some of the SQL Injection attach strings target pn_uid 2
I believe this issue was fixed in the Topics update. At some time in the future another module could have the same attack vulnerability.
Suggestion for release 1.083 or even a 1.821 update.
Could the pn_uid be selectable during the install process when the Admin Login and Password is set? It could either be a randonly generated number or user selected within a range and should not effect the site's operation.
David
Skin MD Staff
Joined: July 31, 2003
Posts: 410
Location: Italy
Posted:
Sep 09, 2008 - 11:31 AM
Are you talking about MD1076 or older? Because this bug (I mean Topics id Remote SQL Injection Vulnerability) has been fixed about a year ago.
Joined: July 17, 2004
Posts: 254
Location: Victoria, British Columbia
bannato
Posted:
Sep 09, 2008 - 12:26 PM
I realize it was fixed last year but was thinking of a module, possibly ported from Post-Nuke or other CMS that may be vulnerable to a user ID attack.
On one of the sites (release 1.76) I have just found over 260,000 user accounts injected in a pn_commerce_users table.
Don't think this vulnerablity has been reported before. No results on a Google. All the accounts were numeric with an IP affixed to the end. The MySQL tables were 46 Megs.
What version of pncommerce?
There is an italian user that is working of a new version of PNCommerce for MDPo 108x, may be he can investigate on this bug.
Joined: July 17, 2004
Posts: 254
Location: Victoria, British Columbia
bannato
Posted:
Sep 14, 2008 - 10:31 AM
Skin wrote:
What version of pncommerce?
I tested the original pnCommerce from the very early days in development. I might even have a set of the icons I designed for it. This was one of the earlier releases before it changed hands, then got dropped, etc.
The pnVersion shows "0.81a". When the module went to the German company I stopped testing.
I don't think this security hole has been found before, nor do I know what string was launched by the hackers. But I do think this is a serious issue for an eCommerce module.
Forum FAQ
Search
Usergroups
Preferences
Options forum
Watched Topics
Latest forum posts
Log in to check your private messages
Log in
