2.0.4 is being hacked

[antler]

Evidently there is a hole in SMF 2.0.4, Index.php that allows hackers access. I will have some more details for you soon.

Are you already of this and working on a patch?

[Arantor]

Without more details it's impossible to know whether the bug you think is being exploited is being exploited or not.

Of course, it's more likely - given all the history of hacking reports that's been around - that you left it writable after a mod install and someone else on the server injected code into your files.

The team does respond quickly to security issues, and gets appropriate patches out (having been involved in helping with these patches in the past) but without details, there's absolutely nothing that can be done.

[NanoSector]

Please use the following form if you think you found a security issue:
http://www.simplemachines.org/about/smf/security.php

[YogiBear]

Ironically, many of those hack sites are viewable by members only. There are a number of claims around the net but how many are true and how many scare stories is another matter...

Cheers, Yoshi, I'll use that.

[Arantor]

There is one vulnerability I know of currently in SMF (that I learned of this afternoon), however I'm not entirely sure 1) it's the same vulnerability or 2) that it's entirely valid (yes, there's unsanitised input not being dealt with, but at the same time it's also the case that it requires admin details to be able to pull off and if you can access admin sessions, you can already do other things that are more blatantly dangerous anyway, like install mods and other backdoors)

* Arantor will be curious to know what this vuln is, if it is valid.

[YogiBear]

Will send info by PM. Arantor.

[Arantor]

Thanks

EDIT: Yes, the vulnerability YogiBear mentions is the same one I've seen. Yes, the team have been made aware of that. Yes, it is exploitable but *only* if you have already managed to hijack an admin session which sort of minimises the exposure and danger of that *specific* vuln.

[wynnyelle]

If you've got admin powers on the forum can't you just delete the whole forum if you wanted to? Seems like it'd be easier than "hacking" it since you're kind of already in. XD Maybe I'm missing something?

[Arantor]

If you've got admin powers on the forum can't you just delete the whole forum if you wanted to?

Exactly my point. Abusing admin powers to perform a side hack is basically a waste of effort, which is what the vuln I have seen does.

It may or may not be the same one antler is talking about.

[Arantor]

If it's the same one as I looked at, there is not really a lot you can do but also there is not really a vulnerability that can be exploited without other issues being at stake.

I don't think there's any panic here. Certainly we're not panicked by it - concerned, as we should be, but not panicked by it because there is a flaw but the requirements to exploit it mean it is not a significant issue.

Does your flaw involve extra code being added to index.php?

[Arantor]

If you answered my question, you might get more information yourself about fixing this. So far all the symptoms you've described do not fit in with a conventional 'hack' to SMF but the result of a server-side hack on a shared host because of poor security practices on your part. (As in, you left it insecure after a mod install and someone else on the server hacked your files because of it.)

[Arantor]

So yes it is the one I've seen.

And everything I said applies:

// to successfully exploit smf 2.0.4 we need correct admin's cookie:

So unless they already managed to brute force your account, or hijack your session... you don't have a problem in that regard.

Also, the vulnerability is not in index.php (everything runs through index.php), it's actually in ManageServer.php

So we're back to what I already told you in terms of being hacked; if you got hacked, it's still very likely the result of improper configuration (this hack only works if index.english.php is writable in the first place, which if after a proper mod install... it shouldn't be!)

[NanoSector]

I shot a copy of the post to the private discussion board for further investigation, and have removed the code from the post, even though it most likely is not dangerous.

[Arantor]

but what is dangerous in your opinion can be viewed as a playdown on your Product.

I was all in favour of it being fixed, but I think you're missing my point. This is just as 'dangerous' as some of the areas of the admin panel that *actively* let you touch arbitrary code.

To give you a meaningful analogy of the comparative risks: think of SMF as a car. This vulnerability is like someone altering the steering mechanism. Sure, it's a problem, but they have to get inside the car first and once they've done that, why would they bother altering the steering mechanism when they could just drive off with it?

In a practical sense, the exact same "vulnerability" exists in the area where you can customise the theme code directly, because you can edit the code directly and if you have the keys to the kingdom (which this ALSO REQUIRES), you can do it.

What's the difference? It's still a weak spot. It can still be exploited remotely. But would you argue that should be removed as a vulnerability?

[NanoSector]

I'm not saying it is dangerous, but better be safe than sorry. As Arantor said it is not a huge hole anyone can access, but we are going to take it as seriously as an issue of that level.

[Kindred]

we will fix it... but those sort of reports are nothing but scare tactics.

As Arantor pointed out - if they have access to your admin, then they can access theme files and make code edits directly.
they could access the package manager and upload anything they felt like...

Seriously, (it will be fixed) but why would anyone bother with this if they alreayd have access to every file on your site?

[RustyBarnacle]

So yes it is the one I've seen.

And everything I said applies:

// to successfully exploit smf 2.0.4 we need correct admin's cookie:

So unless they already managed to brute force your account, or hijack your session... you don't have a problem in that regard.

Also, the vulnerability is not in index.php (everything runs through index.php), it's actually in ManageServer.php

So we're back to what I already told you in terms of being hacked; if you got hacked, it's still very likely the result of improper configuration (this hack only works if index.english.php is writable in the first place, which if after a proper mod install... it shouldn't be!)

While we're on the subject of file permissions, earlier you said that some mods don't change their permissions, should they all be 644?  I've checked mine after seeing this thread and see a lot of mod files especially are 666.  I did search the site and saw a page in the FAQ saying even 777 isn't all that bad but then I see this and thought I'd double check.

[Arantor]

earlier you said that some mods don't change their permissions, should they all be 644?

NONE of them will. There is nothing in the package manager that will automatically revert permissions.

Yes, they should generally be 644 or similar; the idea is that then it's only writable by the file's owner. But if the file's owner is www-data or nobody or apache (configuration depending), then even 644 is a risk and 444 should be used instead.

777 (or 666) is not inherently a risk if there's nothing else on the server, or the server is properly configured for such. Trouble is most servers are shared, and most servers are not set up for such things, in which case you are responsible for keeping file permissions as low as possible - that means after a mod installation, reverting the permissions that you previously made writable.

* Arantor spent a long time figuring out an entirely new installation process that bypasses all this - but doesn't allow for modifying files (but that's fine in my case, no plugins are permitted to carry out file changes anyway)

[NanoSector]

we will fix it... but those sort of reports are nothing but scare tactics.

As Arantor pointed out - if they have access to your admin, then they can access theme files and make code edits directly.
they could access the package manager and upload anything they felt like...

Seriously, (it will be fixed) but why would anyone bother with this if they alreayd have access to every file on your site?

It needs to be fixed, even in the admin panel there should be no security issues. It's not like you can say "Oh, this is the ACP, now lets slack off and ignore security reports".

[Arantor]

Then you still do not see the point I was making.

We both agree that this is a flaw in the language handler.

However, would you please explain to me why you're not classifying the 'edit template file' to be EXACTLY THE SAME VULNERABILITY?

Substitute the URL for action=admin;area=theme;th=1;sa=edit and supply content for filename and entire_file[] to $_POST and you can completely nuke index.template.php. Yes, EVEN THE DEFAULT THEME.

Are you going to tell me that's not a vulnerability? If not, why not? What's the difference?

Both allow you to make direct code edits remotely if you can hijack the admin account. Both require the admin session details, both require the target files to be writable, both accept arbitrary code.

The only difference is that one shouldn't be allowing raw code, granted. But that doesn't remove the fact that the other one DOES. And don't even get me started about the package manager.