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.

[Kindred]

yoshi,

I am certain that it will be fixed...   but it is NOT the "security issue" that the report would have you believe.
You need to already have admin access in order to trigger this.  If you have admin access, you already have access to edit every theme file directly in the admin tools and acess to add, edit or delete every single file on the site, through the package manager (and those two things rae intentional!)

[NanoSector]

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.

Geez, I'm sorry, I just try to do an extra task at trying to provide help in these kind of topics... If not appreciated, tell me, I'll stop.

yoshi,

I am certain that it will be fixed...   but it is NOT the "security issue" that the report would have you believe.
You need to already have admin access in order to trigger this.  If you have admin access, you already have access to edit every theme file directly in the admin tools and acess to add, edit or delete every single file on the site, through the package manager (and those two things rae intentional!)

It is not a huge vulnerability, no. But since it is an issue of some kind it needs to be fixed, especially since it can be done through URLs.
But hey, I'm no developer, so if I'm unwanted, tell me, and I'll be gone.

[Arantor]

Geez, I'm sorry, I just try to do an extra task at trying to provide help in these kind of topics... If not appreciated, tell me, I'll stop.

It's not that it's not appreciated. It's that it's well meaning but ultimately a little disingenuous.

The question stands: Assuming this is a vulnerability, why should we not fix the other things that do EXACTLY THE SAME THING?

But since it is an issue of some kind it needs to be fixed, especially since it can be done through URLs.

So can editing theme files. So can uploading packages. Both of these can be done with a very similar file to the one demonstrated for this vulnerability.

So, the question stands: why should we fix this but not these other things?

(For those playing along at home, it should by now have occurred that I didn't just rewrite the package manager on a whim. I wrote it specifically to take into account this specific avenue of vulnerabilities)

[NanoSector]

Nevermind, this is not my business anyway. Got other things to do.

[Kindred]

antler...

I doubt that anyone used this method to hack your site.
As we already stated, they would need to have access to your admin account in order to do it in the first place.

[TheListener]

Keep up the good work. I would be pleased if you would lock this topic or delete it completely

If you feel the topic is solved please click on the Mark topic as solved tab at the lower left of the topic.

[Arantor]

This hack let's them gather admin information according to my pro..... I believe in them and was just trying to pass it on to you SMF Pros. Please feel free to discount it or whatever you feel appropriate. My problem is solved but other users are still susceptible.

Keep up the good work. I would be pleased if you would lock this topic or delete it completely

Funny, they're wrong.

The hack quite specifically says that it requires an admin session, which means another vulnerability or something else, to have been breached to make it work.

If you were hacked, it WAS NOT BECAUSE OF THIS ISSUE BY ITSELF. YOU HAVE OTHER ISSUES. IN FACT, IF YOU WERE HACKED AT ALL, YOU HAVE OTHER ISSUES.

I would be pleased if you would listen to the fact that you are almost certainly still vulnerable to issues.


EDIT: To clarify. In order for this vulnerability to actually do anything, the following conditions must be true:
1. Your account must already have been compromised or your session while logged in must have been compromised by a third party.
2. Themes/default/languages/index.english.php must have been left writable by anything on the server. This is not the state of SMF installation when installed via FTP in the conventional fashion.

I would be extremely surprised if either of these were the case given the symptoms you were describing, which amounts to injections into the template to serve nasty JavaScript, which is likely an injection into your current theme's index.template.php.

You may still have nastiness present in your files and unless someone competent reviews every file to tell you otherwise, there is absolutely no guarantee that you have it secured. In fact, I'm willing to bet you don't have it currently secured.

[Arantor]

*shrug* When you get hacked again, don't ask for help.