|
- Readme First! -
Read and follow the rules, otherwise your posts will be closed |
|
|
|
|
|
There are currently, 680 guest(s) and 0 member(s) that are online.
You are Anonymous user. You can register for free by clicking here |
|
|
|
|
|
PHP-Nuke Security GFX Mapping - Potential Risk |
|
 In an attempt to prevent scripted bots from either generating new user accounts or attempting brute force password cracking against PHP-Nuke portals, the security graphic had been added in several versions ago. To establish an understanding of what that is, here is an image:
The process begins within the PHP code to generate a random number. That number is then stored in a URL that is resent to the security image creation engine as the login page is being generated:
modules.php?name=Your_Account&op=gfx&random_num=604071
The security graphic engine takes the random number and makes an MD5 encryption of it concatenated with other elements such as the $sitekey, $datekey, and the member's http_user_agent.
At this point the MD5 hash value is switched over to hexadecimal and stored in a variable whereby at a certain starting point (2 by default) a total of x places are read and stored (by default 6).
A potential security risk exists if the default $sitekey value is not changed because a malicious user can manually map out on a PHP-Nuke portal in a one to one relationship between random_num and the number shown in the image. So long as the following values do not change:
$sitekey
$datekey
$random_num
HTTP_USER_AGENT
The number shown back in the security image will always be the same. Such a mapping would be tedious to complete manually, but the possibility exists nonetheless.
Out of the four variables above, the user can manipulate only two:
$random_num
$HTTP_USER_AGENT
This effectively means that the entire process of mapping out the one to one relationship must occur in a single day due to the $datekey parameter. Each day adds a new value to the hexadecimal/MD5 concatenation process.
Lets take this a step further. If a PHP-Nuke webmaster does not change their default $sitekey parameter this could still open them up to attack. A malicious user may install a default PHP-Nuke portal on their own system and now they have access to manipulate all of the four variables above.
This means they can change the date on their system, altering the $datekey to each day of the year, and manually map out all the random_num values to their respective security image code values. At this point, they have a full database for every day of the year that can be used maliciously against default $sitekey value PHP-Nuke sites. With such data, a script can be written to check the random_num value, ie:
modules.php?name=Your_Account&op=gfx&random_num=604071
And such a script could call up the corresponding security code value thereby rendering the purpose behind it useless.
Conclusion? Change your $sitekey immediately from the default value, and change it often. On Nuke Cops for example, the random_num above, 60407, generates the number 588529 using my HTTP_USER_AGENT for today's date. You will most likely see a different code.
|
|
Posted on Thursday, February 12 @ 10:00:15 CET by Zhen-Xjell |
|
|
|
|
| |
|
Average Score: 2.23
Votes: 17
|
|
|
|
|
|
|
| | The comments are owned by the poster. We aren't responsible for their content. |
| | | | |
| No Comments Allowed for Anonymous, please register | | | | |
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by divslo on Thursday, February 12 @ 10:33:49 CET
(User Info | Send a Message) | How to change that site key. What can it be
can it be mayby
blablabla4423423
or must it be a i dont know md5 or something like that. Can someone explain that |
| | | | |
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 2, Informative)
by IACOJ on Thursday, February 12 @ 10:37:42 CET
(User Info | Send a Message) | Using our Analyzer program by default looks for the default $sitekey value and throws an immediate warning if it exists. This has been in place since the $sitekey value was introduced. Among other things, analyzer will spot other security risks and report them back. It also warns you that you shouldn't leave it up on your server. Please understand it is an extremely useful tool, however given the right circumstances it can be used against you.
Let's get back to $sitekey...
Assuming that you don't change $sitekey (many don't) and you leave analyze.php on your server under the same file name, how long do you think it would be before some resourceful chap came along and found that he could exploit your site?
Without much effort at all, and without writing a special script I found several sites through a simple search which could be open to this kind of attack.
You don't know if you have the default $sitekey or not? You don't know if your site is vulnerable in other ways? Download analyze.php and check [nukecops.com] Then to protect yourself later simply rename the script or remove it from your server.
Take a few minutes now to protect yourself from large headaches later. |
| | | | |
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by inkydink1234 on Thursday, February 12 @ 16:58:34 CET
(User Info | Send a Message) | | Nice article for explaining the concept. But, the site key isn't needed anyway. The mt_rand() function is producing a random number between 0 and 1000000. The key is that the random number changes every time when in fact, the sitekey is static whether you change it or not. Yes, it is one more level of randomization, but with a static seed. Read the php.net manual on mt_rand to see that it is more than enough coupled with the other variables. That annoying warning in analyze is very much overkill and will not prevent nor cause any more of a risk of being hacked. |
| | | | |
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by kipuka on Thursday, February 12 @ 17:32:03 CET
(User Info | Send a Message) | Changing a sitekey is a good idea; however, please realize this can be gotten around if someone really wants to break into your site. It serves more as a deterrent for those who do not have advanced technical skills or access to software written by those who do.
Perhaps bigger weaknesses than not changing the sitekey include: it always uses numbers, they are always of a set length, and they are very easy to distinguish using OCR. Serious crackers use OCR these days. Yahoo has spent a lot of money in captcha research because they are a big victim of bots trying to sign up for massive amounts of email accounts. Even with their current system, some bots can still get around it at times mainly because they will not stop using english words. If the bot can figure out one or two letters, it goes through the dictionary and will guess it right a certain percentage of tries. If it hits them 50,000 times and gets in only on 3% that's 1500 email accounts. |
| | | | | |
