Dizkus

Hello

Ok, first some info. I had even with the Subject of this thread some problems, how to name the problem i will now describe. So, this text is a bit long but its a complex topic and i want describe it detailed as possible.

To give an overview:

I will describe and show with an working prototype and working example site why and how the Account Data (aka user name, email and password) should be parted (in an own module) from the Profile Data.

I will show and describe why that it needed, which security problems appear when its not parted and how a site will become more secure when it is parted.

2nd part is how to present profile (for other and for the owner), control panel and account managment. I have there also an example for it.

So - why i write this. Well, the things i will describe are needed for our site.

I am the project founder of http://www.daimonin.net . As you can see, we have there an MMORPG project. Daimonin is both - a open source project and a game with server and community. The site is the connection between our sourceforge dev project and the gaming community.

ATM we have around 150k user. Thats alot, but not that much as it will become. After a release and when i do some advertisement we have normally 250 new users which register on the website. But: They don't need to register ATM. You can download the client and play without using the website. We will change that - i am on the way to install a login server, using the website account as master accounts for the game server. The game server will mirror gaming data back to the website too. In that way we can then install a full game site like wow homesite and such, presenting there clan overviews, event statistic and such.

We will have then around 750-1500 new users per day (that sounds alot but its realistic when we change to 3d - ATM we have around 500-1000 downloads at sourceforge and shareware sites per day) - the needed registering will make it rise.

We already have an item shop where you can buy items. We will connect that also direct to the game server.

For that we need of course one thing: Security.

For some reasons: We will have masses of users. Which is hard to control. Every problem we have to manage by hand will steal us the most valuable part of an open source project: time. Even ATM the website is eating time. Its very, very important that i setup the website as automatically as possible. The item shop will deal with real money which also needs all security you can get.

PostNuke did here on source level a great job. That must be said, thanks for it.

So, whats the problems.

I will now describe the problems which PostNuke has in security things on a "meta level". Means not the code is insecure by nature but how it manages and control the users data.

Please: This is not a PostNuke bashing and also not a PostNuke exclusive problem. Except Typo4 (when i remember right), all other competitors of PN have the same vulnerabilites. When not all then for sure one of two. Joomla have them, Drupal and also the other "phpnuke class" CMS.

Only community focused project like for example the SMF forum handles it right.
Why. I think because CMS are "content" managment system and not "community" managment system. But they are going to be that. My view of this.

Problems
--------

1.) The email security check vulnerability

Lets point it out: How many valid emails need a bot or hacker to install 100.000 faked user accounts? Answer: One. How?

You register with a valid, normal email from a valid hoster. Lets say "hacker@yahoo...". After you are registered you did this: Going to edit proile, changing the email to "markwest@postnuke..." .... And hit ok. Then you register another account using again "hacker@yahoo...".

Now the website owner have a big, big problem. First, its nearly impossible to check which of both emails is valid or not. We don't have any history data. Even when we would need to check and control it... which needs time. We can't ban domains, except you want ban *all* free email accounts.

Imagine how many faked accounts a handful bots can create in short time using this vulnerability. Its even better and more evil as an DoS attack.

Why is that possible? Because ATM the changed email is not checked - no activation is needed. You can change them as normal profile data. But an email is not a profile data - its an account data which is needed to identify the user. Also the website needs to communicate with the user through it. The email is a password class like data and should be handled like that.

2.) The password/email can be changed without sanity check

Szenario: User Carl is sitting in an internet cafe. He is going to get a coffee and leaves the computer for a moment, not locking the screen. Bad idea, of course. But happens pretty often.

ATM, a hacker can then quick go in the profile and change the password and email. One click, going back - Carl with the coffee is notice nothing. He is just going on, then logging out after and leaving.

But his account is now owned by the hacker and it will become VERY, VERY hard for Carl and the website owner to get the account back and to verify that he is the real owner.

How to avoid it?

Simple: Don't allow account class data changing without saniy check. The sanity check should be the old password - at last.

This szenario sounds on the first view pretty obscure and construced. But it is not. I thought so too in the past - but for my surprise this is pretty common. We had like 50 acocunt hacks in the last 3 years. Around 80% (!) was related to this problem. The user was playing in an open internet place or by friends and the data was stolen in this or an similiar way.

3.) The password/email can be changed by direct URL

Changing vulnerability 1. and 2. with an external module will not help, because in profile/pnuser.hp and in the API module the interfaces to change it are still open and accessable.

Whatever you do with the current PostNuke code to fix it - you always have to hard patch the code in /profile to avoid direct URL access by bots. Which is an increasing and comming security problem at all (direct URL access from bots to not shown but not closed/disabled functions).

4.) The described problems are reached through to other modules

If you plan to install other modules of functions like an fully integrated shop or forum then this modules will inherit the vulnerabilites. Even more evil: As more and deeper the modules are integrated as more they suffer. For forums this is already a problem, for our website accounts its very evil.

Every site using PostNuke (and again: most other current CMS) for payment, important hidden data or something, the current way to deal with it through the profile interface will make it vulnerable.

Solution
--------

So, how to fix it? In fact, the problems described are simple to fix.

First: moving the account data away from profile module.
Second: Allow changes to account data only with sanity password check
Third: Allow email changes only with activation check

Please look at my example site, where i had installed the core of the new www.daimonin.net site.

http://static.88-198-46-59.clients.your-server.de/

I used the pnEmailVerification module, which did it nearly right. The module was not ready for 0.8, i changed that and also it don't checked ALWAYS the old password, only for password changes.

Please register and then hit "Your account".

As you can see, i merged also the Profile View for your own profile with the control panel - which is now much more important because it the user interface for the splited profile and account data.

In this new way we need 2-3 click less to make our way through your account.
It needed a small change in the profile_main function. I need add there the profile_view code so its listing the profile data.

Please play around a bit. You should get the feeling that this way to handle the profile and account data is very "natural".

Please ignore the SMF forum - its a new kind of bridge and integration i did and i will describe it just after i wrote this in a different thread.

Please also checkout the Members_list you find under "Profiles". You will find that i removed the edit and "go to control panel" buttons from your own profile only view. Thats done by purpose because the view in the control panel is for you but the Profile view itself is for public. There is no need to have a cross link there - it even will confuse the user a bit.


Conclusions
-----------

As i described the vulnerabilites are they "by design" - invoked by 3 facts:
That they are part of the profile which is wrong because they are not "just info" and in no way for the public. Second, that there is no sanity control through password checks and no verification of the email.

3rd, and pretty important: There is no way to fix this, or at last it will be an open danger, by using 3rd party modules - you have to patch the open API in the profile module where you originally changed the data without control. ATM this can only be done by patching.

I suggest, even the code is frozen for RCs, to include the pnEmailVerification as an own Account module to the .8 release or, at last, merging the functionality to the user module.

Security is one of the main brands of PostNuke and an pretty important part of its functionality portfolio. Also, it wants, as i understand, moving to the enterprise sector of the CMS. For both, the described problems are important.

The profile code changes should be run under bug fixes but still we need the email verification. Whatever you do - its important that you can clean close the standard interfaces to avoid the direct URL vulnerability.

I have for my own my working solution, so i am on the "safe side". I can release the changes to pnEmailVerification too, but its still some handwork in the profile templates and a few patch lines in the code - thats sounds always bad for a "good solution".

I would really hear now some opinions.

Please: What i described is the work and analyzing of many month - as i developed a list of things i needed for Daimonin and how and where i can reach it. I stumpled about this general problem of CMS really by chance. If you have an better idea or a better solution - don't be shy to tell. I have done a working solution which i also think its pretty perfect - but if you have a better way i really interested in it.




edited by: michtoen, Oct 04, 2007 - 08:10 PM

First off congratulations on a very impressive PN community.
Second, I agree with all of your points and I have to say this is one of, if not THE best posts I have seen on these forums.



--
Zikula Themes

I have read your whole post now. Very interesting.

I really wouldn't leave my laptop unattended.. but your points are valid.

I will make sure that the appropriate people read this.

Thanks for your comments, suggestions and solutions...

I have started getting some feedback from above.. I will try to get a 'official' response to this, or have someone respond 'officially'.

Thanks







edited by: AmmoDump, Oct 04, 2007 - 06:23 PM

--
David Pahl
Zikula Support Team

Well, i'm agree in the sanity check when you want to change your password (a little change is required), and have an historial, or a new field with the email used in the registration (that is a big change, alter table)...
Email is important, but there is sites where it isn't

about the direct URL password/email change, i doubt about it.
The authkey is applied to almost all the API functions, and sensible GUIs.
You did it?
i'll review it, but the edit profile form have an authkey.

Very nice post michtoen!
Read you later!

--
- Mateo T. -
Mis principios... son mis fines

Thank you very much, well, i hope can give with my work some back to PostNuke.
Beside the fact that i have to do it - i can't escape.

Please notice this thread now for the SMF bridge - even its not 100% related to
this topic: http://community.postnuke.com/index.php?module=Forum&func=viewtopic&topic=53332

@nestormateo:

The authkey is no problem for the bots. You can simulate with curl or wget and sed and grep a perfect working browser and user. I have some experience in it because i did for other web work automatic access checks with that. That for example the easy bots like the german "Hausarzt" shows as agent perl is pretty stupid. You can simulate everything with good scripts without that you have a chance to notice it on the server side. You have valid cookies with wget, a valid session and also keys you need. With curl even more - because these tools are designed to make valid accessess to your site.

The bot will simply calling the "edit profile" page. There he will get any authkey and such. Then he is calling the interface. The email setting is perhaps hidden in the formular - but thats nothing what the authkey checks. The bot simply adds the email part to the postdata - and voila: a valid call, a valid key - all is fine. Except that you never showed the user or bot a email setting entry. But that don't knows your profile interface... And when you look at the code then you know its set.

Only when the setting function checks the incoming data and knows that password and email
is forbidden - then you have a chance. But thats exactly problem. If we add all that then
we nearly at that what i described in my thread.

Direct URL means in this context that the bot "creates" the URL and postdata. If he needs
a authkey or something then he login first or does the right page call before. The current
bots are pretty stupid, that right. But expect in near future "smart" bots, analyzing the
output text and acting alot smarter.

I, for example, don't think that the register question will help very much for a longer time.
The possible questions and answers are not that much as people think. If you did it to smart,
then you will lose user which are confused by it. And to do some logic to analzye a '+' or
the words "write" or "type" are easily be done.




edited by: michtoen, Oct 05, 2007 - 03:11 AM

smf don't liked the zip file - so i remove it.
I had to post the code part for the bridge in the forum thread.




edited by: michtoen, Oct 05, 2007 - 08:07 AM

Thank you for your input. We are currently discussing your points on the developer's mailing list.

--
best regards from Kiel, sailing city

Steffen Voss

Member of the PostNuke Steering Committee
Read The Zikulan's Blog