Increase security on next version(s) IPB 2.1.x

[aymelek]

I think that since version 1.3 i am applying third party patches to enhance security on the forum software.
Some are simple sollutions and some require a bit more. Therefore i would like to make the following suggestions and comments..

First of all , the greatest danger to IPB is the board admin him or herself.
It easy to be sloppy on security and post your password or sent admin passwords in PM sytem to new
admins for example or post the FTP codes in admin lounge, After all it was postedn in a PM or posted in an
adminlounge so who can see? You could be suprised who sees :) Treat your search engine bots as admins and u can read back on google...or else.
Also many many admins use very simple passwords for security. I have seen from 3 letters to repeats of their name as password. Yes i know it's handy to be able to remember your password so u can login instead of pasting a 20 digit random code like this: 2@b2w3wuwuPr-9eguhen
But the last example is so much safer as it is much more harder to crack/break.
Since IPB 2.0 it became very difficult to break the password from IPB then for example in comparence to 1.3 as that was easier.
So enhanced security starts with yourself. Admins and moderators should use good passwords based on above example, especially when you have problems with people breaking in your forum-software and deleting or playing pranks with you.

NB. i have been on many boards of various version(s) either to help admins install something or correct a problem. Above are a collection of my experiences on that and do reflect reality.

Now to continue, lets say that you apply a good password and your staff as well. Then what is the next danger? Well still the person is the weakest link when you start sharing it with others, so change regulary to something new. So after this the most dangerous , even when you apply the best passwords, is XSS scripting or the so called cookiehijack.
When someone cookihijacks your account they are YOU! with the difference that they do not know your password. But the board recognizes the cookie value and therefore sees you as?..you. The only time it asks for verification is when you want to goto acp.
And yes the most damage can off course be done in acp but dont forget the mod functions admins have on a forum... as you can see here below:

Forum Options.
Show All Invisible Topics
Show All Topics With Invisible Posts
Resynchronize Forum
Prune / Mass Move
Forum Options
Mark forum as read and return
Mark forum as read and return to board index
Subscribe to this forum

The most dangerous i made red. So on cookiehijack i can execute that red option and delete forum after forum or mass move forum to forum and mix all the posts.
Now imagine all the effort of staff and members ...destroyed or mixed up in a few moments.
Why? People do that for various reasons and we can all come up together with 1001 reasons maybe, but the point why is this possible. Simply ...this function does NOT have password verfication. The board thinks its you ..the admin ... but it someone else. Can this be stopped? Yes.
All IPB has to do that when executing those functions it asks for the function's executor his or her boardpassword. After entering that in the pop up box the board continues to execute the function.
The following link is a limited attempt to limit that damage a bit. Limited because it was converted from IPB 2 to IPB 2.1 and was based in IPB 2 on the danger of those little boxes behind each topic in a forum, and where in IPB 2.1.3 (current version) with the forum options dropdown box, this mod doesnt cover password validation yet on THAT function.

So resistance is futile for the moment ...it is a current weakpoint as where IPB 1.3 had a mod on IZE where you had to enter your password inorder to use modfunctions.
I plead for the incorporation of a password validation before executing massfunctions on the newer and current versions of IPB 2.1.x.
It only needs to be applied to mod, g.mods & admins.

My suggestion on top of that is that the PM box / my controls is password protected as well. Damage can be done by simply reading all PM's and not everybody archives his PM's.

My honorable friend Fusoya made a mod for 2.1.x and previous versions.
http://mods.invisionize.com/db/index.php/f/5549

Allows you to control the permissions on which groups and/or members can access the various sections of the UserCP (My Controls). You can control their access to each individual section, including signatures, avatars, profiles, etc. You can control these permissions on a group by group basic, and also set individual member permissions as well.

So i use that in reverse on staff. Therefore admins cant do passwordrecovery, nor emailchange nor change password via my controls. Why over my controls as where admins can do over acp anyway???

So close as many intrusion options as there are. Now if this existed then the boards would already be a bit safer.
The next danger lies in the modifications.
Affliates, tutorial mod and for example view who downloaded and off course Arcade for IPB 2.0.x give access entries for malicious code to be executed. On some easier as on others but overall possible and done already.
Many many exploits area available on the net, ranging form executing a code that drops all permission masks for all groups to revealing hashed pass of admins.
But there also exploits that are private written and shared in very selective groups and not shared on the net. What is created by man can be broken by man.
Gaining cookie hijack admin access is less then 2 minutes.

ACP
I wish you would include the the second password (security password) as a standard future in future releases as well.

Lest say this is part 1, and we continue the discussion from here :)
Better safe then sorry i say, secondly i ahve read numerous topics , i have been hacked, my forums destroyed etc, so it is a reality ranging from family boards to xxx boards.
At one point , everyone is confronted with something in his boardlife. Ranging from simple to extreme cases as where i am convinced that writing the code for protecting those massfunctions is such an easy enhancement for Matt or Brandon, that they could do it with their left hand and eyes closed.

It is suggestion from my side, it is in no way to be taken as a bashing of the product , otherwise i would not of written this. I want a honest discussion if it is possible and i have asked already Fusoya to code this as a paied modification.
Again better be safe then sorry and why not? All major software companies release security enhancments all the time. After all we live in a world where people take pleasure in destroying other peoples work and doing backups and restoring them is not the sollution but reparing after something was done, it didnt prevent it from happening................. <_<









In addition......cookiehijack :)
http://bfarber.com/index.php?showtopic=8858

And Brandon is aware of this, we discussed privatly about this .

[Coastie]

In addition......cookiehijack :)

http://bfarber.com/index.php?showtopic=8858

And Brandon is aware of this, we discussed privatly about this .

:blink: :blink: Well that sure is not good!! :blink: :blink:

[Coastie]

forgot to mention, I really like the idea of a 2nd password required to log into the ACP

[Logan]

The "cookie hijack" is the little perl script floating around which uses a vulnerability in version IPB 2.0.3 and below to grab a password hash then you simply edit your cookie to include the userid and their password hash, newer versions aren't affected.

[TCWT]

The "cookie hijack" is the little perl script floating around which uses a vulnerability in version IPB 2.0.3 and below to grab a password hash then you simply edit your cookie to include the userid and their password hash, newer versions aren't affected.

Hmm, wonder if that vulnerability have something to do with THIS. :unsure:

[aymelek]

The "cookie hijack" is the little perl script floating around which uses a vulnerability in version IPB 2.0.3 and below to grab a password hash then you simply edit your cookie to include the userid and their password hash, newer versions aren't affected.

newer versions are affected...

[rct2·com]

We use built-in server security (.htaccess/.htpasswd) to protect admin.php. It's an extra level outside ipb which does help.

I think there are 2 different threads to this topic here. How to protect your board from hackers, and how much you want to trust the admins/moderators you have chosen to help run your board.

I'm comfortable with the latter.

[bfarber]

A lot of these suggestions I feel should at least be considered. That's why I asked the poster outside of this site to submit this topic. :) I will talk with Matt about it as we make plans for the next release.

Perhaps an ACP option "Require password for all moderator actions" or something and then anytime an action that is limited to moderator-permissions is attempted the password is requested?

[Coastie]

sounds like a good start

[beeman]

A lot of these suggestions I feel should at least be considered. That's why I asked the poster outside of this site to submit this topic. :) I will talk with Matt about it as we make plans for the next release.

Perhaps an ACP option "Require password for all moderator actions" or something and then anytime an action that is limited to moderator-permissions is attempted the password is requested?

i think that should be seperated into (dropdown box style)

Require password for ALL moderation actions
Require password for MASS moderation actions
Dont require passwords

(i woulnt like to have to add in a password eachtime i delete a double post etc, but would like the added secority of proventing mass actions without confirmation, and the settings could be upgraded in the event of the site being "under attack")

[TCWT]

Require your email address for password reset.

[Guest Exiled]

We use built-in server security (.htaccess/.htpasswd) to protect admin.php. It's an extra level outside ipb which does help.

Do I understand correctly that you have a double-login to your ACP?

It's a good idea, and I think my Admins will go for it, especially if we use a non-MD5 crypt() option for htpasswd. They aren't crazy about having the same password for the board and ACP

[TCWT]

The "cookie hijack" is the little perl script floating around which uses a vulnerability in version IPB 2.0.3 and below to grab a password hash then you simply edit your cookie to include the userid and their password hash, newer versions aren't affected.

Newer versions are indeed affected, I was one of the victims of such an attack. >_< My version is 2.0.4

[tranceandy]

forgot to mention, I really like the idea of a 2nd password required to log into the ACP

Agreed, really good suggestion by OP :D

newer versions are affected...

Does anyone know if 2.1.3 is affected?

[marcele]

Here are some suggestions for admins:

1. Never login to your ACP on an unknown PC (You don't know if the PC has a keylogger or spyware installed)
2. Use a password manager program like access manager (Use generated 20+ char combos) Its a free program http://www.accessmanager.co.uk/
3. Never give full admin access to anyone you don't absolutely trust.
4. If your community is your business then I don't recommend hosting in a shared hosting enviornment (You don't want your server to be affected by other users hosted on the same server (Both from malicious use or server resources). If a dedicated server is too much money then at least look to a VPS solution.


Here are some suggestions on what IPB should implement to improve security for their product:

1. Account bruteforce protection by default (no mod required)
2. Auto logout (this has to be done via javascript as php sessions aren't automatically removed)
3. ACP filename should be able to be renamed with the var stored in the conf_global.php file (not the db)
4. SSL support for logins (or at least javascript hash) .. so logins aren't sent clear text.

So many of these board hacks could be prevented if the ACP would be able to be renamed. If you don't know what the filename is then
a. You can't run bruteforce attacks on it (even if the admin has a weak password)
b. Even if the hacker gains the admin session or password they can't login to do damage.

And if anyone tells me that "security through obscurity" is bad practice .. I'll set up a test board (with the ACP page renamed and I'll GIVE YOU THE ADMIN PASSWORD .. and you see if you can hack it ok?

[.John.]

Does anyone know if 2.1.3 is affected?

No, it is not.

[tranceandy]

No, it is not.

Thanks :thumbsup:

[aymelek]

I beg to differ.

Passwordhash is pulled via a script and then entered in a program that is built for that ( i own a copy) and login is established as that member i d you pulled.

[.Cameron]

On the insecure passwords issue, you could have an option in the ACP (or mandatory for super moderators and admins) that prevents users from using an insecure password (like with cPanel).

[aymelek]

Thats a nice idea also
some messengers have that also

[aymelek]

Nice going by releasing the security update :)

[PC-fre@k]

Now how to update 2.0.4 with that patch manually? I waited to upgrade to 2.1.4 cause not all mods were ready, but I like to keep my board as it is for now without any security issues!

Thanks :)

[.John.]

The edits are around here somewhere...

:)