Tinfoil Security - Cross-site request forgery vulnerability - 42 found

Started by DeveloperMcD, March 26, 2017, 04:54:37 PM

Previous topic - Next topic

DeveloperMcD

First, I want to say that I don't believe in all the scare-mongering put out by security companies, SSL companies, etc. I think most of it is a way to sell SSL certificates, security software and other security services.

Like Orkin, the computer security industry operates on the advertising technique, "Play on Fear".

That having been said, it would be nice to know how I would go about telling people this is rubbish. I ran a security scan on my SMF 2.0.13 forum, and I got 42 instances of this "vulnerability":

QuoteA unique token that guarantees freshness of submitted data must be added to all web application elements that can affect business logic.

I'm guessing SMF has some other way to maintain integrity -- perhaps it doesn't matter if someone posts to these forms from another website. Anyhow, I'm sure there's a good explanation.

Can anyone offer some insight on this?

I am smart enough to not get panicked, but not everyone is me.

Kindred

Well, as far as we know, there are no vulnerabilities in SMF 2.0.13 except some reported and fixed hardening in the admin section for 2.0.14.
(* and, if someone has access to the admin, they alreayd can pretty much do anything they want, with the package manager and theme manager anyway)

However, without more detail on these "reported vulnerabilities" we really can't address them, except to say that whatever scan is running is probably full of bull-crap.
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Arantor

There's CSRF protection, it's just not done in the way that report says, and there is no way for the report to know that what SMF doing does the same job.

Colin

CSRF (Cross site request forgery) is an incredibly valid concern and one that many sites are vulnerable to. As Arantor said, SMF 2.0 does implement CSRF protections by instead of passing a unique token validated on form submission it passes the session ID (either via the URL or POSTed form data) which is validated. It is hard for these generic automated tests to detect this, but you are safe :) Thanks for inquiring.
"If everybody is thinking alike, then somebody is not thinking." - Gen. George S. Patton Jr.

Colin

ShaneWilton

I'm an engineer at Tinfoil Security, and I came across your post, so I wanted to jump in and see if I could help somehow. I'm not sure what site you scanned, but if you wouldn't mind emailing me at either [email protected] or [email protected], I'd be happy to take a detailed look at the report and see what went wrong.

We very much do not want to play on fear, so if something in the report is inaccurate, I'd love to either look into what went wrong with our scanning process, or help track down exactly what the exploitation steps would be so that we could get a proper bug report out to SMF.

It's very possible that Kindred is right, and that these are false positives, but if that's the case, I'd love to get that fixed up so that we're not fearmongering :)

Arantor

Hi :) I'll just jump in here as a former member of the dev team and how this applies here.

So, of course we have the session token that goes request to request - it's not a one-use token, but the general auth token. There is also an additional value going on here that is stored primarily on the server side, used to obfuscate the variable name.

Now, the way this plays out, for all POST requests and data-changing GET requests (some do exist, e.g. the logout link), we pass in the variable name and the token in the GET/POST body and this is of course expected to match the cookie.

For example, the logout link is something like http://www.simplemachines.org/community/index.php?action=logout;ba12bc14f0=f8e3692c47c2e8461df68c42b4a42c7b

It isn't the kind of hardened CSRF that your tool assesses for, so it isn't a false positive as such, but it does mitigate the casual kinds of drive-by attack that you'd normally be able to achieve with general CSRF style of attack, because even if you manipulate the user's request to submit something with the correct cookie, a third party wouldn't have the values required to match the cookie/session.

SMF 2.1 does implement one-time CSRF tokens though.

ShaneWilton

That makes sense! Thanks for the detailed explanation. Our tool is specifically looking for one-time CSRF tokens, which is why we detected these "issues". Your approach is similar to a lot of techniques we see for mitigating CSRF, and sounds alright to me for the cases you're concerned with. SMF 2.1 does sound like an improvement though :)

Edit: Just to clarify though, while your technique does mitigate against casual drive-by attacks, it technically does still expose users to more targeted attacks. The most naive example being a phishing attack where an attacker asks their target for their logout link (contrived, I know, but you get the point).

Arantor

True, true, it's an area we're aware of - hence the move to proper one-time tokens, but we haven't actually seen any evidence of such phishing attacks that I'm aware of (otherwise we'd have stepped it up before now)

ShaneWilton

Yeah, it isn't something I'd be concerned about. Thanks for talking through it with me :) This will be a helpful discussion to reference as we improve the granularity of our CSRF detection for cases like this.

DeveloperMcD -- if you run into trouble with the report, feel free to direct your manager / whomever to me. I'd be happy to walk them through the results and help convince them the sky isn't falling.

Advertisement: