Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Securing PHPNuke against hackers UNIX
This article is not intended to teach you how to hack into PHPNuke but how to secure it properly. Again this is NOT a license for you to poke around sites where you don't belong but I digress...

If you are like me and want to have a nice-looking, easy to manage dynamic website then PHPNuke is arguably the most popular out there. It installs, configures and runs very well on Mac OS X. However there a few security issues that you need to be aware of and this is all about how to secure your PHPNuke powered site.

Read the rest of this article for some ideas on how to secure PHPNuke against hackers...

This article is not intended to teach you how to hack into PHPNuke but how to secure it properly. Again this is NOT a license for you to poke around sites where you don't belong but I digress...

If you are like me and want to have a nice-looking, easy to manage dynamic website then PHPNuke is arguably the most popular out there. It installs, configures and runs very well on Mac OS X. However there a few security issues that you need to be aware of and this is all about how to secure your PHPNuke powered site.

Read the rest of this article for some ideas on how to secure PHPNuke against hackers...


I've been running PHPNuke since September of last year and it has performed for me flawlessly. Recently though, the site was hacked. Thus began my journey to discover the holes the hacker was using.

Since our site is small and would not gather too much attention I never really worried too much about pluggin everything. Besides, I have an cron job that backs up the web root and MySQL database and copies the whole thing off-site. So in the event of a catastrophe I could get it back and running in no time. Not really an excuse but just common sense with vital data.

Anyhow, thanks to Apache's logging I was able to discover the time and file(s) the hacker changed. Furtunatly for me the only file munged was the default index.php file in the web root. But here is what I found after doing some searches on the net...

PHPNuke has a very serious hole...it allows you to 'cp' any file on the box... or even upload files!

Let me explain the bug... admin.php contains this routine:
$basedir = dirname($SCRIPT_FILENAME); 
$textrows = 20;
$textcols = 85;
$udir = dirname($PHP_SELF);
if(!$wdir) $wdir="/";
if($cancel) $op="FileManager";
if($upload) {
copy($userfile,$basedir.$wdir.$userfile_name);
$lastaction = ""._UPLOADED." $userfile_name --> $wdir";
include("header.php");
GraphicAdmin($hlpfile);
html_header();
displaydir();
$wdir2="/";
chdir($basedir . $wdir2);
CloseTable();
include("footer.php");
Header("Location: admin.php?op=FileManager");
exit;
}
That routine doesnt do a check to see if you are logged as admin or not. Thus by careful manipulation of a URL you can COPY ANY FILE and call it up in the web browser or upload your own file (more on this in a bit)

Example:
http://www.yourdomain.com/admin.php?upload=1 & file=config.php & file_name=hacked.txt & wdir=/images/ & userfile=config.php & userfile_name=hacked.txt [spaces added to improve readability and allow line breaks].

The admin 'login' page will be prompted just go to http://www.yourdomain.com/images/hacked.txt and you will see config.php that as everyone knows contain the SQL passwords. This way the hacker could get in and manupulate the SQL server!

Solution:
The most effective way to remove the security hole is to comment out the upload function in admin.php. You will lose the ability to use the built-in filemanager in PHPNuke but you're better off using FTP or SSH to do those kinds of functions.

Comment out the upload function like this:
if($upload) { 
// copy($userfile,$basedir.$wdir.$userfile_name);
// $lastaction = ""._UPLOADED." $userfile_name --> $wdir";
// include("header.php");
// GraphicAdmin($hlpfile);
// html_header();
// displaydir();
// $wdir2="/";
// chdir($basedir . $wdir2);
// CloseTable();
// include("footer.php");
// Header("Location: admin.php?op=FileManager");
exit;
}
You can use pico to do this (pico admin.php and seach for upload (command-w). Save it back out (control-o) and quit (control-x). This will effectively disable the security hole. You can even go one step further if you wish to display a message to would-be script kiddies:
if($upload) { 
echo "Uploading facility removed from this site. Script kiddies are not welcome."
;
exit;
}
OK, so I plugged the hole. I thought I was safe. But I was hacked again!

This time I missed a file the hacker had uploaded into my web root by exploiting this flaw before I disabled it.
The little file was just sitting there... phpshell.php

phpshell uses PHP to act as a shell on your web server. This effectively by-passes SSH and Telnet. The hacker can call up phpshell in a web browser and command away to his heart's desire. In my case a simple text redirection into index.php was enough to deface the site!

I also was dumb enough to leave all the files in the web root set to 777 which allowed any file to be overwritten. I changed that in a hurry. Unless you change the files quite a bit, set them all to 644 like this:
chmod -R 644 *
and change all the directories to 777 like this:
chmod -R 777 */
So in the end I changed all my passwords, permissions and disabled the upload funtion of admin.php and even removed the links.filemanamger.php in ./admin/links/

If you don't wat script kiddies playing around in your PHPNuke site then go the extra mile and learn to secure it properly!
    •    
  • Currently 1.50 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (2 votes cast)
 
[13,307 views]  

Securing PHPNuke against hackers | 6 comments | Create New Account
Click here to return to the 'Securing PHPNuke against hackers' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Permissions
Authored by: nullprogram on Jan 08, '02 09:38:50PM

The proper permission level for web-served files is 644 - even if you change the files a lot. You don't need execute permission to change files. Directories should be 755, not 777. 755 prevents other users from modifying the directory. 777 leaves you wide open.



[ Reply to This | # ]
Permissions
Authored by: zellpharm on Jan 08, '02 11:26:16PM

You would be correct in with the privilesges you suggest however PHPNuke and many 3rd-party modules need write privs to the folders.
Again, if you secure admin.php with the file upload mod then you are safe from the Nuke security hole. You're at your own risk if you have other serevices open though...



[ Reply to This | # ]
Not in my version of PHPNuke
Authored by: mike3k on Jan 08, '02 10:20:20PM
What version of PHPNuke are you running? In 5.3.1, the code looks like this:
if ($admintest == 1) {
    $basedir = dirname($SCRIPT_FILENAME);
    $textrows = 20;
    $textcols = 85;
    $udir = dirname($PHP_SELF);
    if(!$wdir) $wdir="/";
    if($cancel) $op="FileManager";
    if(($upload) && ($admintest)) {
	copy($userfile,$basedir.$wdir.$userfile_name);
	$lastaction = ""._UPLOADED." $userfile_name --> $wdir";
	$wdir2="/";
	chdir($basedir . $wdir2);
	Header("Location: admin.php?op=FileManager");
	exit;
    }
}


[ Reply to This | # ]
Not in my version of PHPNuke
Authored by: zellpharm on Jan 08, '02 11:29:44PM
I'm running 5.2. You can modify your code as such:

if ($admintest == 1) {
    $basedir = dirname($SCRIPT_FILENAME);
    $textrows = 20;
    $textcols = 85;
    $udir = dirname($PHP_SELF);
    if(!$wdir) $wdir="/";
    if($cancel) $op="FileManager";
    if(($upload) && ($admintest)) {
	// copy($userfile,$basedir.$wdir.$userfile_name);
	//$lastaction = ""._UPLOADED." $userfile_name --> $wdir";
// 	$wdir2="/";
//	chdir($basedir . $wdir2);
//	Header("Location: admin.php?op=FileManager");
	exit;


    }


}




     

[ Reply to This | # ]
PostNuke is Better
Authored by: monickels on Jan 09, '02 02:53:24AM
PostNuke, a spin-off of PHP-Nuke, is superior. More than 80 developers, fast-moving code, a rock-solid development path clearly laid out, an active and large community, better security, etc., etc. One of the main flaws with PHP-Nuke is that its development is not open, thus bugs seem to last and last, from version to version. I've recently installed PostNuke 0.72 on my TiBook for development and it runs perfectly on OS X with MySQL and PHP. I intend to upgrade from a heavily modified 4.2 version of PHP-Nuke and never look back. Regarding the bug, the best solution is to simple take all the filemanager code out. It never worked well and was always a security risk.

[ Reply to This | # ]
PostNuke is Better
Authored by: ProMac on Jan 28, '02 04:49:39PM

I agree PostNuke is better. I'm using version .7.0.3 and it's going strong. I created a usergroup site with PN it's still new but definetly secure. From what I read PN is more secure and increasingly popular.



[ Reply to This | # ]