"Exploit"... May 09, 2013, 04: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.htmlIt 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 ), 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.
Re: "Exploit"... Reply #1 – May 09, 2013, 09:25:02 am 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.
Re: "Exploit"... Reply #2 – May 09, 2013, 03: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.
Re: "Exploit"... Reply #3 – May 09, 2013, 04:41:27 pm Oh yes, there's the token system, I'd forgotten about that.
Re: "Exploit"... Reply #4 – May 10, 2013, 05: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?
Re: "Exploit"... Reply #5 – May 10, 2013, 10:58:18 am Quote from: emanuele – May 10, 2013, 05:20:04 amIt 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.
Re: "Exploit"... Reply #6 – May 10, 2013, 01: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 :/
Re: "Exploit"... Reply #7 – May 10, 2013, 03: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 checkedThe 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.
Re: "Exploit"... Reply #8 – May 10, 2013, 04: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.
Re: "Exploit"... Reply #10 – May 11, 2013, 02:44:54 am Quote from: Arantor – May 10, 2013, 04:58:04 pmThing 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"
Re: "Exploit"... Reply #11 – May 11, 2013, 03:54:38 am Quote from: TE – May 11, 2013, 02:44:54 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.Quote from: TE – May 11, 2013, 02:44:54 am* 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 proxyThey may create more issues than the problems solved...but that's probably to be evaluated on a case by case.Quote from: TE – May 11, 2013, 02:44:54 am* Force admin logout on non-admin pages (-> AdminEndSession()) ? Probably yes, but it would annoy usersPlease 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).Quote from: TE – May 11, 2013, 02:44:54 am* 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...
Re: "Exploit"... Reply #12 – May 11, 2013, 04:50:17 am QuoteIt 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.
Re: "Exploit"... Reply #13 – May 11, 2013, 07:49:45 am Quote from: TE – May 11, 2013, 02:44:54 am* 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.
Re: "Exploit"... Reply #14 – May 11, 2013, 12:53:30 pm I go away for part of a day and booom, this happens 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 proxyAs 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 usersI 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 QuoteYou 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...