NukeCops - Bypassing PHP-Nuke Membership Restrictions

Recently, our site had two members join without permission. This went unnoticed for several hours as all the administrators tried to sort out whether one of us had approved their memberships. When it turned out that they weren’t approved, you will no doubt believe we were a little panicked!

It turns out that by adding a header back to the forums, I exposed a link that had not been on the site ever since the new skin was installed. Even though the link wasn’t there before, anyone could have created an unapproved account before at any time. It’s actually pretty laughable that with all the self-proclaimed hackers who have enjoyed spamming this site in the past and voting against all our articles, not a single one found this security hole.

Rationale

I would like to share with you how this hole worked for a couple reasons. The obvious one is that if you run a PHP-Nuke site like ours, you may be vulnerable as well. The bigger reason is that this is a good example of how a lot of hacking is done and how a little research goes a long way.

The Scenario

Let me explain the situation briefly. We are running a PHP-Nuke site with an embedded PHPBB forum. This version of PHP-Nuke has the embedded board for the benefit of users only needing to create one account. In other words, both systems share the same SQL database. While the PHP-Nuke software has overall control, PHPBB still retains a few of its own security settings. In this case, more than we realized.

The site was set in the PHP-Nuke software so that users could only create accounts after being approved by an administrator. After this, new users would still have to verify their email address to activate their account. To make this even tougher, I had attempted to remove all links to the page that allows accounts to be created.

Researching PHP-Nuke

To look for a security hole, let’s say our would-be hackers looked at another site running the same software as ours. For example, http://nukecops.com. Just by looking on the main page, they would see that the link to the account creation function is http://nukecops.com/modules.php?name=Your_Account&op=new_user. The first thing they might try is appending gate.html?name=Your_Account&op=new_user to our domain name.

This would have gotten them to the page they were looking for, but they still would have to be approved by an administrator before being able to activate their account. This has since changed and would forward them to a different page (just in case I’m giving anyone ideas).

While signing up for accounts like this would have been a minor annoyance (since each would have to be deleted), they would not be activated and therefore they could not have even logged in. That being said, let’s do a little more research.

Let’s say our would-be hackers look at the forums for the Nuke Cops site. There is a link at the top titled “Register”, which links to http://nukecops.com/modules.php?name=Forums&file=profile&mode=register. What is important to note here is that this is a different link that goes to a different page with a different registration function. Had they tried appending gate.html?name=Forums&file=profile&mode=register to our domain, they would have found a different registration page that would have let them register without even verifying their email!

Why was this possible?

As I mentioned above, the PHPBB software is embedded in PHP-Nuke but still retains some control. It turns out that buried deep within the administrative area for PHPBB, there is still a setting to allow members to join without validation. Having no idea that there were separate registration pages in the first place, I left this setting when I installed the site because I was letting PHP-Nuke handle all registrations.

Conclusion

This is a mistake I should not have made but nonetheless did. I’m lucky nobody found this because there are a lot of folks who would have made some administrators lives miserable for hours while deleting spam threads and tracking down security holes! I was fortunate that the members who registered because of this security hole did so in complete innocence.

The reason this shouldn’t have happened is that a good administrator would rationalize security in the opposite direction of the way I did. What I mean is that a smarter administrator than myself would have started with all settings set to the maximum security to begin with and then would have slowly backed down as each setting needed lowered. While I was smart enough to check all the default settings, I neglected my responsibility to test the security more thoroughly.

While this may not seem like “real hacking” to do this sort of thing and more like silly HTML tricks, this is a good example of how a lot of hacking is done. The combination of a default security setting left at the minimum, a file present that allowed that setting to be used, and the file permissions set so that said file could be accessed by anyone is a very common problem. The scariest part is how little research and technical knowledge would have been needed to exploit it.

This is an excellent article and thought provoking. Thank you. I'd say this deserves a 5.