Vague Security bug? In SMF

!wooha · March 15, 2009, 12:25:07 AM

The other day while doing a AJAX security review, I saw what seemed to be a weird security behavior.

The SMF session is stored in the html to support the collapse header function.

Quote
      function shrinkHeader(mode)
      {
         smf_setThemeOption("collapse_header", mode ? 1 : 0, null, "3fe3ce94567008e4fa8d479c0b69423b");
         document.getElementById("upshrinkHeader").style.display = mode ? "none" : "";
         current_header = mode;
         setInnerHTML(document.getElementById("upshrinkText") , mode ? "[More]" : "[Less]");
   }

So if your can get the innerHTML of the document <HEAD>, you can parse out the session id.

What good is this?
Well, the session id is used to PROVE that a request to DO something is actually coming from YOU, so having this value compromised is a BAD THING.
If you have javascripts loaded externally, and I suppose Flash as well, they may be able to Cross site script you into all kinds of hitherto safe actions.

To play it safe, I edited out this functionality from my templates, but there is a risk that other code may do this too ( exposing session variables via Javascript.)
The attack surface may seem to be small (since an included script - otherwise trusted would do the deed) but Javascript may be called from Flash, which I see enabled by a lot of sites...

heavyccasey · March 15, 2009, 06:59:19 AM

Well, it's also stored in HTML in the karma links and many other places. Like:

<a href="index.php?action=modifykarma;sa=applaud;sesc=3fe3ce94567008e4fa8d479c0b69423b">applaud</a>

That's probably even easier to parse out.

!wooha · March 15, 2009, 01:08:04 PM

ugh...dammit..

never thought of those obvious locations.

using 'Divbodyarea' I was able to get it real easy with Jquery/Mootools and then craft a request for a non-existing jpeg with the session id as the name of the file (in order to communicate the session ID)

(and I suppose it wouldnt be too hard then to urlencode a flash command to do the same, tho I'm not really a .FLA /ActionScript person).

Playing it paranoid, I've disabled flash embedding for admins and moderators, and checked to make sure none of my mods or any open source code references anything from anywhere other than the folders on my server.
That should be enough, I hope

karlbenson · March 15, 2009, 02:32:43 PM

This sort of hack is EXACTLY the sort of reason why flash is disabled in smf by default.
Flash is a security risk in other ways too.

metallica48423 · March 15, 2009, 03:51:12 PM

Do remember that SMF does it's best to prevent attacks based on session fixation, even if it can be parsed.

In certain php setups it's possible to use the phpsessid to access a certain session. SMF prevents this from happening. SMF 2.0 actually goes a step farther than that in it's session by randomly changing the variable it's looking for in the session check. That is, the generic "sesc" or "sc" is now more dynamic and much more difficult to predict.

Keep in mind that removing these calls will break the functionality which depends on a session check before anything is done.

!wooha · March 15, 2009, 04:29:59 PM

I'm not sure if what you said makes sense, or it would even matter if it did

That's cause we are basically looking at the 'trusted employee gone bad' situation as we are at risk from code we allow into the page (outside of SMF) ... I am not even sure if switching to a NONCE type code ( http://en.wikipedia.org/wiki/Cryptographic_nonce ) would work
since it's not really an initialization issue...

how else would we implement session authentication other than how SMF is doing it already?
I am at a loss

...in the more horror dept.
I also took a look at the threat tools like Firebug, GreaseMonkey etc. are to your AJAX driven sites.
While that isnt a big problem with SMF really, that fact is, with those tools you can easily edit the page and basically rewrite your site from the inside.

My solution to that is to encrypt most Javascript, and embed some information in the parameters (to detect if they had been tampered with)

I did find that there are some settings you can make to embedded flash that prevent its communication with Javascript, that should do it for us I think?

SleePy · March 15, 2009, 04:41:24 PM

If they can run the innerHTML javascript function, then they could just as easily run document.cookie as well.

There is something called crossdomain.xml that you could look into using. I haven't looked at it to much, but remember thinking about using it years ago for a gaming site I ran.

karlbenson · March 15, 2009, 04:42:05 PM

Encryption would be about as useful as protecting it as anti-copying protections on dvds.
Won't stop a thing.

SMF does set AllowScriptAccess to NEVER. But last time I read, there are some flash apps which can override it.

Theres always going to be risk. Elimination is impossible, only minimising them.

Fustrate · March 15, 2009, 04:52:01 PM

To make SMF ultra secure and amazingly un-hackable, go into Settings.php and find

Code Select

$maintenance = 0;
and replace it with

Code Select

$maintenance = 2;

Aleksi "Lex" Kilpinen · March 15, 2009, 04:55:07 PM

Quote from: Fustrate on March 15, 2009, 04:52:01 PM
To make SMF ultra secure and amazingly un-hackable, go into Settings.php and find
Code Select Expand
$maintenance = 0;
and replace it with
Code Select Expand
$maintenance = 2;

ROFL - I'll go do that right away - Great advice, thank's!

Tristan Perry · March 15, 2009, 05:44:07 PM

Quote from: Fustrate on March 15, 2009, 04:52:01 PM
To make SMF ultra secure and amazingly un-hackable, go into Settings.php and find
Code Select Expand
$maintenance = 0;
and replace it with
Code Select Expand
$maintenance = 2;

For any newbies, don't take this advise

Fustrate · March 15, 2009, 05:45:21 PM

You can't deny that it makes your forum impenetrable...

SleePy · March 15, 2009, 06:55:29 PM

That change is like locking your front door and leaving the back door open. There are still other things such as FTP, SSH and direct server access which will let them into your SMF files.

Fustrate · March 15, 2009, 07:01:07 PM

We're only talking about the forum here... if you can get FTP/SSH/etc. access, would you really bother going through the forum to wreak havoc? I wouldn't

!wooha · March 16, 2009, 12:14:37 AM

Quote from: Fustrate on March 15, 2009, 07:01:07 PM
We're only talking about the forum here... if you can get FTP/SSH/etc. access, would you really bother going through the forum to wreak havoc? I wouldn't

once you have direct access, going through the forum would be the best way - there is a lot of activity there (even on a smallish forum) so the crook would be able to operate undetected.
I *HAVE* found something really interesting, if you look at ALL the browser/server variables (instead of just remote_addr, refferrer, user_agent, there is a virtual smorgasbord of sweet extra information! )

Some browsers, (like IE) ALWAYS send some certain variables which is useful if, a hacker changes their useragent string to look like they are using a different browser, but IE7 always sends [XUA_CPU] as a variable. If a browser comes with Ie7 useragent, and dont have the special data I mentioned, I blok it =permanently.

Fustrate · March 16, 2009, 01:29:02 AM

-_-... disabling security on a forum to get exposure amongst the users is like smashing a bulldozer through the walls of a house just so you can open the front door from the inside. Why not just put whatever code you need into index.template.php once you gain FTP access?

IMHO, you're getting really worked up over stuff that the devs have absolutely no control over, and frankly nobody would bother trying to use against a site. Refer to my bulldozer analogy.

!wooha · March 16, 2009, 05:03:23 PM

oh no!

not talking about disabling ANY security!

we were just talking about making the way the session code is stored in the html (and thus available for theft by a rouge script) less risky.

At first, it seemed to be a matter of doing away with the "collapse header" function, which I really dont care about: that functionality could easy be a client side cookie or even just for the current browser session. but then it was pointed out to me that that functionality is used all over (i.e. for the Karma +/-) and of course mods will use it too.

Of course, the only exposure you have would be from programmable elements that you yourself host on the page!

that falls into several types, i think.

1) user supplied content: posts, signatures,PM's.
disable active content or sandbox it like mySpace does

2) Javascript, other Active Content like Flash, Silverlight etc. that you hotlink from other sites or copy and host on to your own site w/o knowing the full behavior of the code.
Sanitize it, dont hotlink JS from any site - including SMF

Actually, this is a wee bit odd.
SMF has a latest news bit "http://www.simplemachines.org/smf/latest-news.js" which is injected into the current scope of your admin page.
I really dont see a need to include or use Javascript for this basic function, it could easily have been an RSS feed or IFRAME ...so technically, the only people who can PWN your smf forum is SMF! lol, it would be easy to make a IP or cookie based substitution and serve a crafty .JS file instead of just plain news, and they would have access to the site (cross site scripting wise) because the script is pulled in within the context of an ADMIN USER.

(Not that SMF would ever do any bad, of course.. ..but the power is still there..to be used wisely, I'm sure!

Fustrate · March 16, 2009, 05:10:27 PM

but there are easter eggs that rely on the JS from SMF!

cflforum · March 27, 2009, 03:05:20 PM

Is this scenario really possible?

can anyone shed further light on this?

karlbenson · March 27, 2009, 05:29:03 PM

Theres always risk in anything.
SMF has done pretty much all it can to reduce the risk as much as possible.

cflforum · March 27, 2009, 05:56:04 PM

Quote from: regularexpression on March 27, 2009, 05:29:03 PM
Theres always risk in anything.
SMF has done pretty much all it can to reduce the risk as much as possible.

I apologize as obviously I didnt ask a proper question to which you could reply.
I guess what I should ask is, the scenario described above, where an injected script either from SMF or embedded Javascript/Flash, parse out the session code and use it for anything useful or is it one of those hypotethical risks?

I understand that the session code protects functions by 'proving' the originator of a request -if that value is not secret, then actions can be taken that are otherwise rejected.

I ask this because there is often a lot of FUD on these 'security' reports - most are conceptual and unworkable. I just wanted to know if this was a 'real' possibility or not, thanks. I see that your title is 'developer' so I guess you are the best qualified to speak to this?

thanks for your time.

karlbenson · March 27, 2009, 06:41:07 PM

As you'll note from the humorous responses above, there isn't much else that can done which wouldn't reduce functionality of a forum. (eg going back to the dark days of static html pages with no functionality/interactivity)

aldo · March 28, 2009, 12:11:33 AM

I thought SMF also hashed your session id as well? As in the session id SMF outputs on the page isn't really your true session... So even if someone were to get a hold of it, they would need to unhash it, which I think SMF hashes it with SHA-1

A moderately practical idea to prevent someone from stealing your session would be doing something such as before allowing the use of the session data, you check the cookie information against what is in the session data. Basically, get the cookies information which would contain the member id and the password (hashed and what not), and compare it to the member id and the password inside the session data... if its the same, let them use it, if its not, don't

It works, I do it sometimes. It makes sense... even if someone were to steal your PHPSESSID, they would need to have your member id (easy to get) and your hashed password (probably not so easy to get), and practically put an end to session stealing because you might as well just try to get their password XD.

News:

Vague Security bug? In SMF