ElkArte Community

Elk Development => Bug Reports => Exterminated Bugs => Topic started by: emanuele on May 09, 2013, 10:55:37 am

Title: "Exploit"...
Post by: emanuele on May 09, 2013, 10:55:37 am
...well, sort of.

Recently an exploit for SMF has been reported (I'm pretty sure it affects Elk too, not checked though):
http://exploitsdownload.com/search/smf%202.0.4%20exploit/
http://packetstormsecurity.com/files/121391/SMF-2.0.4-PHP-Code-Injection.html

It works only if the user is an admin, so not really an "exploit", just a matter of save the expected thing instead of hope everything passed by the user is correct (that may be considered an evidence of a not so good practice within SMF code, but that's another point :P), though it's not worse than any other place where an admin can edit a file (themes for example) or do more nasty things.

I don't think I will release a patch for SMF ... well, there is the but reported by Arantor about the mail queue that may be worth patching (but ATM I'm not exactly in he good mood to work on a release), so if the real bug is fixed it may be worth add a fix for that too.
Title: Re: "Exploit"...
Post by: Arantor on May 09, 2013, 03:25:02 pm
That was largely my conclusion as well - and if you haven't modified the language editor in ManageServer it will still be vulnerable (same as the not-validating-language set in ManageServer in 2.0.4)

Tell you what, I'll pull out the changes we did to the mail queue and document them as for SMF. ;)
Title: Re: "Exploit"...
Post by: TE on May 09, 2013, 09:35:51 pm
Elk may probably be affected, yes.. But the Language-Editor is protected via validateToken().. I reckon a stolen admin cookie wouldn't help, the token validation would fail and you'd have to re-enter the password to get a properly initialized admin session.
Title: Re: "Exploit"...
Post by: Arantor on May 09, 2013, 10:41:27 pm
Oh yes, there's the token system, I'd forgotten about that.
Title: Re: "Exploit"...
Post by: emanuele on May 10, 2013, 11:20:04 am
It would be a bit more complex, but if you have an admin session you can just load the page (with the token) and POST the page...no?
Title: Re: "Exploit"...
Post by: TE on May 10, 2013, 04:58:18 pm
It would be a bit more complex, but if you have an admin session you can just load the page (with the token) and POST the page...no?
with a valid admin session probably yes... I'm not that familiar with Session, Token and Cookie handling.
Title: Re: "Exploit"...
Post by: Arantor on May 10, 2013, 07:57:55 pm
See, that to me seems to undermine the token system's effectiveness. You're proving that the person who hit the button to start the page is the same person who is hitting the button the second time, but if the session's already compromised, the hijacker only needs to have the session in order to be able to do their own thing anyway :/
Title: Re: "Exploit"...
Post by: emanuele on May 10, 2013, 09:17:00 pm
I'd say that the token system ensures that the person POSTing something is the same (of course with all due limitations of an insecure http communication) that hit the "save" button.
The token can be summarized on:
* a random (unique) string is created
* the string is placed in an input type=hidden
* the <form> is POSTed
* the string is checked

The tokens were able to avoid the 2.0.3 bug (i.e. POSTing to an admin form from an "anonymous" page), though if the session is compromised the tokens are of no use.
I don't think the tokens were meant to be more than that.
Title: Re: "Exploit"...
Post by: Arantor on May 10, 2013, 10:58:04 pm
Thing is, if they've already compromised the session, it doesn't provide any security that can't be *trivially* worked around.

Yes, you'll prevent posting from an anonymous page (which is what half this exploit does), but if an attacker already has the keys to the kingdom to exploit posting from an anonymous page, he just has to get the page first, read the details then make the new POST.

So I'm really not clear on what the actual security benefits of the token really are. :(
Title: Re: "Exploit"...
Post by: emanuele on May 10, 2013, 11:56:36 pm
Yep, not saying otherwise. ;)
Title: Re: "Exploit"...
Post by: TE on May 11, 2013, 08:44:54 am
Thing is, if they've already compromised the session, it doesn't provide any security that can't be *trivially* worked around.
Agree.. The only benefit of the token: You'd know from which internal form the data is going to be POSTed. It blocks POSTing from anywhere else.

Let's get back on that session hijacking (seems to be the root for most exploits).. As said, I'm not aware of the current implemantion.. Just throwing ideas..

* Would it help to use session_regenerate_id(TRUE) frequently?  
* Would it help to protect the session with an additional key:
- User Agent -> I suppose no, just another key which needs to be "faked"
- Bind to IP -> would probably help but would cause problems for users behind a proxy
* Force admin logout on non-admin pages (-> AdminEndSession()) ? Probably yes, but it would annoy users
* encourage users to use AdminEndSession(): Add a big red warning box (the same, if you haven't deleted install.php) with a text like this: "your're currently in Admin Mode, please end your admin session immediately after you've finished your admin tasks"

Title: Re: "Exploit"...
Post by: emanuele on May 11, 2013, 09:54:38 am
* Would it help to use session_regenerate_id(TRUE) frequently?
Maybe.
You may regenerate the ID on each and every page. Or bind it to a token...dunno.

* Would it help to protect the session with an additional key:
- User Agent -> I suppose no, just another key which needs to be "faked"
- Bind to IP -> would probably help but would cause problems for users behind a proxy
They may create more issues than the problems solved...but that's probably to be evaluated on a case by case.

* Force admin logout on non-admin pages (-> AdminEndSession()) ? Probably yes, but it would annoy users
Please no.
That's more than annoying. There are admin pages that link to non-admin pages (e.g. from many "member-related" to profiles) and that would screw up badly any kind of browsing of those areas unless it is introduced a clear separation between admin and everything else (included page duplication).

* encourage users to use AdminEndSession(): Add a big red warning box (the same, if you haven't deleted install.php) with a text like this: "your're currently in Admin Mode, please end your admin session immediately after you've finished your admin tasks"
It may or may not, from what I've read there are admins that live the forum from the admin panel, so they have more or less always an active admin session, in these cases it would probably become just a piece of the template...
Title: Re: "Exploit"...
Post by: TE on May 11, 2013, 10:50:17 am
Quote
It may or may not, from what I've read there are admins that live the forum from the admin panel, so they have more or less always an active admin session, in these cases it would probably become just a piece of the template...
yeah, but it would probably sensitize some more users, Some will never learn ..

By the way, the "admin end session" button is a great step forward, but we should move it to a prominent position,, e.g. in the top menu and mark it with a shiny color. The current position is IMO far to secret.
Title: Re: "Exploit"...
Post by: TestMonkey on May 11, 2013, 01:49:45 pm
* Would it help to use session_regenerate_id(TRUE) frequently?  
Worth looking into, I'd think.

Quote
* Would it help to protect the session with an additional key:
- Bind to IP -> would probably help but would cause problems for users behind a proxy
... Optional? For the duration of an admin session?
I don't remember Tor behavior, I think you can get out through a different node on any request...
Well, I think too, it will likely create more problems than it solves.

Quote
* encourage users to use AdminEndSession(): Add a big red warning box (the same, if you haven't deleted install.php) with a text like this: "your're currently in Admin Mode, please end your admin session immediately after you've finished your admin tasks"
I'd say yes... It's harmless, and it'd help more.
Title: Re: "Exploit"...
Post by: Arantor on May 11, 2013, 06:53:30 pm
I go away for part of a day and booom, this happens :P

Quote
* Would it help to use session_regenerate_id(TRUE) frequently?  

More than it already is? Possibly. Possibly not. It will increase the risk of session timeout errors.

Quote
* Would it help to protect the session with an additional key:
- User Agent -> I suppose no, just another key which needs to be "faked"

Pretty much. Though I'd argue it could be used at the point of escalating the session from conventional to admin to confirm the referrer if supplied (it sort of is IIRC) and to validate the user agent then since it shouldn't change between the login page and the form receipt. Of course, if a miscreant has your admin password, there's absolutely nothing that can be done about it anyway...

Quote
- Bind to IP -> would probably help but would cause problems for users behind a proxy

As an optional extra, perhaps, but not by default. Mind you, I can see the logic of having a set of whitelisted IP addresses that are allowed into the admin panel and requesting to join from something not whitelisted might be an option. I don't know, I'm wary about this.

Quote
* Force admin logout on non-admin pages (-> AdminEndSession()) ? Probably yes, but it would annoy users

I wouldn't force it, but I'd have a nice big warning at the top of the page.

Quote
* encourage users to use AdminEndSession(): Add a big red warning box (the same, if you haven't deleted install.php) with a text like this: "your're currently in Admin Mode, please end your admin session immediately after you've finished your admin tasks"

This :)

Quote
You may regenerate the ID on each and every page. Or bind it to a token...dunno.

Yes, you could do it every page. Binding it to a token is pretty much what you're doing when you're regenerating.

See, I can think of all kinds of scenarios where this is more problematic than not, e.g. if people are like me and open multiple windows for things...
Title: Re: "Exploit"...
Post by: TE on May 11, 2013, 10:46:04 pm
ok, thank you all...
two more ideas to discuss (a good german beer is sometimes a great inspration  :D )
- remove the checkbox "Disable administration security" from the gui and make it a hidden db setting? It shouldn't be that easy to bypass a critical security related setting.
- make the admin session lifetime configurable via setting and allow values between 5 minutes and 1 hour (current refresh time is 3600) I'd personally prefer a shorter refresh time. (10 minutes?) Except from the maintenance tasks you'd normally need just some minutes to finish the admin task.
Title: Re: "Exploit"...
Post by: Arantor on May 11, 2013, 11:14:57 pm
Quote
- remove the checkbox "Disable administration security" from the gui and make it a hidden db setting? It shouldn't be that easy to bypass a critical security related setting.

I did that a while ago. ;)

Quote
- make the admin session lifetime configurable via setting and allow values between 5 minutes and 1 hour (current refresh time is 3600) I'd personally prefer a shorter refresh time. (10 minutes?) Except from the maintenance tasks you'd normally need just some minutes to finish the admin task.

That's interesting. I can see that if you're doing quick tasks, you probably do only need 10 minutes, but if it's a complex operation it might need longer. I know our plugin uploading would appreciate the longer period especially if you have multiple plugins (because we don't have the same upload process at all now)

And don't forget the 'while I'm here...' mentality, going into the admin panel to do one thing and doing a bunch of others.

One thing I also added that might be useful is to include a message to the user at the top of the admin area to indicate the time remaining in the admin session.
Title: Re: "Exploit"...
Post by: emanuele on May 11, 2013, 11:35:31 pm
Except from the maintenance tasks you'd normally need just some minutes to finish the admin task.
Attachments maintenance may take hours...many hours. And the checkbox to disable admin security becomes handy in that cases (of course is a quite limited scenario, but a real one).
Title: Re: "Exploit"...
Post by: Arantor on May 11, 2013, 11:42:16 pm
You could always deal with that the way MediaWiki does: by making them CLI scripts only. But that doesn't do a lot for those using poor hosts. Mind you, those running poor hosts don't usually get their forums big enough to be up to the 'maintenance taking hours' stage.
Title: Re: "Exploit"...
Post by: TestMonkey on May 12, 2013, 07:59:36 am
You could always deal with that the way MediaWiki does: by making them CLI scripts only.

And many others. Yes, TBH I love this way: CLI scripts with clear defined purposes, for maintenance, upgrade, stuff.

It doesn't need to be exclusive ("this way and only it"), all the rest stands.

We'll see I guess, if there is interest for developing CLI equivalents or maintaining or enhancing existing versions. (upgrade already has)
Title: Re: "Exploit"...
Post by: TE on May 12, 2013, 08:36:49 am
Attachments maintenance may take hours...many hours. And the checkbox to disable admin security becomes handy in that cases (of course is a quite limited scenario, but a real one).
yep, I know at least one forum where it was a real scenario (german forum about photography with "millions" of attachments). It's an edge case, I think. The few ones who would run into such problems could still enable it via phpMyAdmin.  Most will probably disable the admin security because they are to lazy to type their passwords frequently. I still believe we should discourage them from doing that.

Quote from: Arantor
You could always deal with that the way MediaWiki does: by making them CLI scripts only. But that doesn't do a lot for those using poor hosts. Mind you, those running poor hosts don't usually get their forums big enough to be up to the 'maintenance taking hours' stage.
CLI is nice but remote shell access via SSH is an extremely rare feature when it comes to shared hosting.
Title: Re: "Exploit"...
Post by: Arantor on May 12, 2013, 03:23:50 pm
Sure it's a nicety but on the other hand, the forums big enough to actually run into timeouts (because it's > 1 hour), will almost certainly be on VPS type hosting or better anyway.
Title: Re: "Exploit"...
Post by: TE on July 13, 2013, 07:01:24 pm
Was working on this one and believe I should notice this:
If an admin is logging in there's automatically an admin session initialized.

Do we really need an active admin session on login?  Can only speek for myself: I use my account (with admin privileges) permanently but I rarely visit the admin interface..

Title: Re: "Exploit"...
Post by: Antechinus on July 13, 2013, 10:29:58 pm
Yeah it's a tricky one. My 2c is the same as your 2c, but other admins may be different.
Title: Re: "Exploit"...
Post by: emanuele on July 13, 2013, 10:41:37 pm
Well, you have just entered your password... I don't see how not having the admin session initialised would help.
Title: Re: "Exploit"...
Post by: Antechinus on July 13, 2013, 10:43:39 pm
True. Ok, leave it.
Title: Re: "Exploit"...
Post by: TE on July 13, 2013, 10:49:27 pm
I've just entered my password but I don't need admin access right now, so the admin session doesn't need to be initialized.

Example: Maybe someone is stealing my session via XSS.. they still cannot access the admin interface, because there isn't an active admin session. I believe it's a benefit regarding security, a small one, but still a benefit. I personally login at forums several times a day but I rarely visit the admin interface... So there's no need to initialize that session.
Title: Re: "Exploit"...
Post by: Antechinus on July 13, 2013, 10:58:47 pm
I'm easy either way.
Title: Re: "Exploit"...
Post by: emanuele on July 13, 2013, 11:12:49 pm
I very rarely log into any (live) forum, I'm always logged in, and most of the times I login is just for testing on some localhost... lol

From what I read at sm.org, me and you are just a couple of exceptions, most of the admins out there are spending more time in the admin panel than in the forum itself...
Title: Re: "Exploit"...
Post by: TE on July 13, 2013, 11:25:10 pm
hahaha, you're probably right.. I'm paranoid when it comes to security  O:-)

I have to login several time a day, our company internet access for "private use" is designed that way (the web browser is a published application from terminal servers and the user's profile incl. all cookies and temporary internet files on that servers will be deleted once you've closed your browser).

Edit: How about making an option to enable "auto admin session on login" in the admin interface?
Title: Re: "Exploit"...
Post by: TE on July 14, 2013, 10:54:33 am
ok, made it an optional setting in admin..
https://github.com/elkarte/Elkarte/pull/657

The PR is taking care of:
- configurable admin session length (min 5 minutes, max one day)
- warning bar for active admin sessions
- enable / disable automatically initialized admin session during logon.

I think that's all we can do to harden the admin session.

Would be nice if someone with english as their native language can check / validate the language strings:
https://github.com/eurich/Elkarte/commit/abd843e6ea57462233d00e09d0af3d1af2c3e25a