|
- Readme First! -
Read and follow the rules, otherwise your posts will be closed |
|
|
|
|
|
There are currently, 350 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: 1)
by IACOJ on Thursday, February 12 @ 10:40:42 CET
(User Info | Send a Message) | Hi
Your $sitekey can be anything you like. If you open config.php it is the last variable to be changed. Change it to a new value and reupload. |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by gear on Thursday, February 12 @ 13:22:21 CET
(User Info | Send a Message) http://toprake.com/ | | ...and for the passwordly challenged people like me, there is this tool [www.winguides.com]. Set it to 32 (or more), and choose every option but the first ;-) |
]
| | | | |
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 Zhen-Xjell on Thursday, February 12 @ 17:47:54 CET
(User Info | Send a Message) http://castlecops.com | If you take a more indepth look at the code:
$rcode = hexdec(md5($_SERVER[HTTP_USER_AGENT] . $sitekey . $random_num . $datekey));
mt_rand is not being used at this point to generate the actual security code. It is only the beginning point.
From the $rcode, the following is extracted:
$code = substr($rcode, 2, 6);
$code is what gets sent back as the security code value.
So you see, the $random_num has already been generated. Which means if you refresh the link in the article several times or hundreds of times today without changing your user agent you will see the same security code value over and over again:
http://googletap.com/modules.php?name=Your_Account&op=gfx&random_num=604071
You can remove the $sitekey and the number will of course be different. But that number will also remain the same as I described above.
Which means under my specific conditions, the random_num 60407 equals 588529 for today's date with the Nuke Cops secret sitekey.
Please ensure you understand how the code works, because your explanation is not correct.
As to the annoying warning in analyzer, it is especially meant to be just that. Its purpose is not to fix any issues, but to alarm the owner of those that exist.
With that said, what have you done to help improve the security holes and issues in the PHP-Nuke community? |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by MadHatter on Thursday, February 12 @ 22:06:24 CET
(User Info | Send a Message) http://www.bindmaker.org | here's a stupid question, just because I'm curious as to why you did this the way you did it (and I think I know why, but want to hear the actual reason).
why not get a date/time value to add to the salt, and or use a random value between 1-26 for the substring block of the code?
I know there are 7 ways from sunday that you could implement a security code (including getting a longer code to type in as well as using the ascii value of the random numbers to print out or use all printable ascii characters), but I just wanted to know the methodology in why you implemented what you have (great job btw ;) |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by Zhen-Xjell on Thursday, February 12 @ 22:58:37 CET
(User Info | Send a Message) http://castlecops.com | | Those are implemented, I covered it in the article above where it shows four values being concatenated for the final code value. |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by MadHatter on Friday, February 13 @ 00:41:35 CET
(User Info | Send a Message) http://www.bindmaker.org | I saw what you mentioned, but what I was meaning, was instead of using $datekey = date("F j"); so that the seed of the datekey was "Februrary 13" doing something like:
$datekey = date("Y-m-dTH:i:sO");
$rcode = hexdec(md5($_SERVER[HTTP_USER_AGENT] . $sitekey . $random_num . $datekey));
$rand_start = rand(1,26);
$code = substr($rcode, $rand_start, 6);
(just to comment on your original post) I already had a 512 bit site key on my site (over kill i know, but hey) generated from all printable ascii characters, and Have replaced original code for the gfx mapping with the above.
by "date time" I meant the actual date (which you already use in another form) and the time (hour:min:sec+tzd). (I'm using the ISO 8601 date time format for mine) so that it does not stay the same value all day, little alone between refreshes...
I'm sure Francisco had something in mind when he designed and wrote it as we now have it, but I was wondering why such a change has never been introduced? (again just curious)
--thanks |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by MadHatter on Friday, February 13 @ 00:43:19 CET
(User Info | Send a Message) http://www.bindmaker.org | hrm... forgot to write the backslash b4 the T previously (that's what I get for doing it from memory :S )
$datekey = date("Y-m-dTH:i:sO");
$rcode = hexdec(md5($_SERVER[HTTP_USER_AGENT] . $sitekey . $random_num . $datekey));
$rand_start = rand(1,26);
$code = substr($rcode, $rand_start, 6); |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by MadHatter on Friday, February 13 @ 00:58:33 CET
(User Info | Send a Message) http://www.bindmaker.org | $datekey = date("Y-m-d\TH:i:sO"); (guess it was there, just didn't double escape it).
I'll quit now |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by Zhen-Xjell on Friday, February 13 @ 06:35:41 CET
(User Info | Send a Message) http://castlecops.com | | You are correct in adding that the datekey would do well if expanded to include more data. The article's intent is to focus in on what is here and now however. |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by inkydink1234 on Friday, February 13 @ 07:32:08 CET
(User Info | Send a Message) | You say "Please ensure you understand how the code works, because your explanation is not correct"
As usual, your 'holier' than thou' attitude keeps you from seeing facts that don't agree with your perception of the world.
Look at the code yourself, Paul, because mt_rand is called EVERY time PRIOR to gfx being called. It is one of the value pairs that are passed TO gfx. That is why selecting refresh 100 times produces 100 different values. That makes the value of sitekey much less relevant.
And as to your question "With that said, what have you done to help improve the security holes and issues in the PHP-Nuke community?", here again, you seem to think that you hold the keys to the kingdom and to the pulse of the community. Yes, your site is large and does a good work. But, there are many who do much and contribute much to that work behind the scenes and don't seek the glory and ego trip that you do. Even on your own 'staff'. There are many other support sites out there too, and together they form a support ring. But none dare challenge the great and awful 'Oz' of nukedom. You would do much more for the community if you would quit purporting yourself to be the self acclaimed security and nuke god. |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by Zhen-Xjell on Friday, February 13 @ 09:11:45 CET
(User Info | Send a Message) http://castlecops.com | Ok, lets follow your train of thought. Then why does the security code value stay the same for you all day given the same random number?
As to the 'unsung' heros... realize that I too have done work that others have claimed. I haven't stood up to protect those credits. Its the same for everyone. We're all here to help, not fight. |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by inkydink1234 on Friday, February 13 @ 10:11:40 CET
(User Info | Send a Message) | I just don't get what you're trying to prove or say here. I just used NC - Your_Account as a test, since we know that you have changed your site key. Subsequent refreshes of the page proved this:
1 - 672390/205909
2 - 678472/116440
3 - 362551/26993
You are claiming that by not changing the sitekey the values stay the same all day. That is total crappola and I keep trying to get you to see and admit that. It just doesn't matter as then value gets randomized with or without it. It changes 100% of the time. |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by MadHatter on Friday, February 13 @ 10:27:08 CET
(User Info | Send a Message) http://www.bindmaker.org | that is because you are using the random number that is being generated on the page as your value. the whole point was that if you used a static number as the random_num you get the same gfx code. I believe the point was that if you were to know the site key and the random number (by passing it in manually) you could render the code usless because you can guess what the code is actually going to print.
try this link and see if you don't get the same code everytime. that is what he was talking about. I don't think you quite understand the article (that or we don't quite get your point).
http://nukecops.com/modules.php?name=Your_Account&op=gfx&random_num=604071 |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by inkydink1234 on Friday, February 13 @ 10:47:22 CET
(User Info | Send a Message) | I understand completely. Paul said
"So you see, the $random_num has already been generated. Which means if you refresh the link in the article several times or hundreds of times today without changing your user agent you will see the same security code value over and over again"
Refreshing the link is the test I performed and fails. That's what I am responding to. If you want to depend on the sitekey as a seed then forget about the config.php and set $sitekey equal to another random number right in the routine. Or randomize $sitekey from config.php in the routine. Virtually any breach of a system is dependent on being able to reproduce or reconfigure some kind of code. As you or someone else has said, all of these things are meant to deter and/or confuse. To me this is not a SECURITY risk because no security is ever breached, I get more useless hits from one time wonders with yahoo addresses than any bot would do. |
]
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by Zhen-Xjell on Friday, February 13 @ 10:53:46 CET
(User Info | Send a Message) http://castlecops.com | The security risk as stated a long time ago in these discussions and in the article is that for a php-nuke fresh install, the default sitekey exists. You or anyone can download phpnuke and see what that value is. You can then sit there and run a generation against all possible random numbers. Each one will give you the same security code on the same day. Run that for 365 days for each possible random number, you now have a database that can be used by a bot to run brute force attacks against a phpnuke that didn't change their sitekey.
This isn't about changing something in phpnuke that already has this implemented. Its about getting folks to change their sitekey value so that the stock database cannot be used.
And if your code is changing that is due to your user agent changing if you are utilizing the same random_num.
I think at this point you are not inline with what this article is discussing and going on a complete tangent. |
]
]
| | | | |
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. |
Re: PHP-Nuke Security GFX Mapping - Potential Risk (Score: 1)
by Zhen-Xjell on Thursday, February 12 @ 23:01:04 CET
(User Info | Send a Message) http://castlecops.com | What you specify is correct, however, this article sheds light as to a possible reason why the default sitekey should be changed.
You are correct also with your theory that security codes (I'll extend that to passwords as well) should be completely random including extended ASCII if possible.
In this situation, the default security code has 6 numbers. Each digit has a choice of 10 numbers.
Now that's a pretty big shot in the dark. And that is precisely why the PHP-Nuke portals that would be affected are those that maintain the original sitekey value.
|
]
| | | | | |
