Skip to main content
Topic: "Exploit"... (Read 4741 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

"Exploit"...

...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.
Bugs creator.
Features destroyer.
Template killer.

Re: "Exploit"...

Reply #1
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
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.
Thorsten "TE" Eurich
------------------------

Re: "Exploit"...

Reply #3
Oh yes, there's the token system, I'd forgotten about that.

Re: "Exploit"...

Reply #4
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?
Bugs creator.
Features destroyer.
Template killer.

Re: "Exploit"...

Reply #5
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.
Thorsten "TE" Eurich
------------------------

Re: "Exploit"...

Reply #6
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
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.
Bugs creator.
Features destroyer.
Template killer.

Re: "Exploit"...

Reply #8
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 #9
Yep, not saying otherwise. ;)
Bugs creator.
Features destroyer.
Template killer.

Re: "Exploit"...

Reply #10
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"

Thorsten "TE" Eurich
------------------------

Re: "Exploit"...

Reply #11
* 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...
Bugs creator.
Features destroyer.
Template killer.

Re: "Exploit"...

Reply #12
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.
Thorsten "TE" Eurich
------------------------

Re: "Exploit"...

Reply #13
* 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.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: "Exploit"...

Reply #14
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...