Did that. Still, looking into it further, this is possibly done with simple POST data. Everyone is at risk. This is how this attacker found me, from my logs...Came from Google with search string "powered+by+smf+1.1.3". Check your logs.

It's not overreaching at all, I've gone over the logs quite a bit. This attack was managed from two IPs. One to install it. Another to manage it.

The preview feature broke the same time as the hack. The attacking script probably edited something here and there.

c99madShell was installed as Themes\readme.php

I don't have any mods installed, this happened under SMF 1.1.3, and while the attachment option is there, I never set the upload dir or permissions..."An Error Has Occurred!Cannot access attachments upload path!"

There were a few security fixes in 1.1.4, one of them might be related to your problem. We have been unaware of them being used in the wild, but one of our developers might be able to determine more once they go through the security report.

Logged

Motoko-chanDirector, Simple Machines

Just because it's pouring down doesn't mean we're gonna drown. There's a time when all you can say is let it rain - Mat Kearney (Let It Rain)

Of course, you should have allow_url_fopen turned off unless there is a specific need for it, then enable only for that script or directory. That will pretty much stop server-side remote inclusion attacks in general.

Logged

Motoko-chanDirector, Simple Machines

Just because it's pouring down doesn't mean we're gonna drown. There's a time when all you can say is let it rain - Mat Kearney (Let It Rain)

I'm not up and up on the subject, but from what I understand the issue here is with the attacker being able to call 'wget' or something similar from the shell to download a script. Like 'shell_exec(wget(...))', which gets around allow_url_fopen.

I checked the six SMF forums (4 I admin, 2 I'm a member) that I keep an eye on, and none of them have been affected in this way (despite at least two running an old version for a bit longer than they should have).

Logged

Motoko-chanDirector, Simple Machines

Just because it's pouring down doesn't mean we're gonna drown. There's a time when all you can say is let it rain - Mat Kearney (Let It Rain)

Though unless this attack is specific to v1.1.3, chances are the previous versions are susceptible to this also that run on a host that do not have the mentioned php functions disabled.

Asa far as I know, we have not looked at all the releases we have put out in the past.

Regardless, there is a reason we emphasize keeping updated so heavily. It is much harder to update to 1.1.4 when you are still on one of the 1.1 RC releases. Likewise for the 1.0 line as well. It might cause a little pain now, but being able to keep up with the latest fixes is much more important, especially with the security fixes added since 1.1 RC3.

« Last Edit: September 30, 2007, 05:08:25 PM by Motoko-chan »

Logged

Motoko-chanDirector, Simple Machines

Just because it's pouring down doesn't mean we're gonna drown. There's a time when all you can say is let it rain - Mat Kearney (Let It Rain)

This should prevent most scripted attacks, but you still have functions like...proc_open,popen,curl_exec,ini_alter/set,parse_ini_file

Except for SMF, I use only very basic PHP commands on my site, and so could disable quite a few without breaking anything. I did automated searches of the SMF 1.1.4 code to try to discover which functions could safely be disabled without breaking SMF's functionality.

Of the functions you mentioned, shell_exec and ini_set appear to be used, so they probably shouldn't be disabled.

I wound up with this tentative line for php.ini. To all the functions you mentioned, I added some more.

Of the functions you mentioned, shell_exec and ini_set appear to be used, so they probably shouldn't be disabled.

I believe we only use shell_exec for DNS lookups. If you disable hostname lookups, you should be okay disabling that function as well. Of course, I haven't studied the code all that closely lately, so there might be something else using it as well.

The webhost I'm at doesn't allow the use of wget. That's one protection.

Anyone who hosts from their own PC could (?) move the wget executable to a directory that isn't in the search path so it can only be run by someone who knows exactly where it is.

Don't forget curl. It is designed to be easier to program, anyway. Heck, libcurl can even be in PHP if enabled (and some hosts enable it as some payment gateways use it). There is also lynx, too. If all else fails, if perl is on the system (it almost always is, many system commands need it) that can be used and there is a bonus if LWP is installed. Note that these are just the ways I thought of off the top of my head. Moving executables is pointless when there are so many ways to get around missing one. The best protection in this case is vigilance.

« Last Edit: October 01, 2007, 02:26:10 AM by Motoko-chan »

Logged

Motoko-chanDirector, Simple Machines

Just because it's pouring down doesn't mean we're gonna drown. There's a time when all you can say is let it rain - Mat Kearney (Let It Rain)

I believe we only use shell_exec for DNS lookups. If you disable hostname lookups, you should be okay disabling that function as well. Of course, I haven't studied the code all that closely lately, so there might be something else using it as well.

You're right. I just checked. Only 3 uses of it, all in one function, host_from_ip($ip).

Revised php.ini line. I tested a variation of this. Browsing through forum pages and in the Admin area produced no errors:

I think I've seen an injection attack script that used ftp to retrieve the remote shell script, so the whole slew of ftp_ commands could be added to the list, too. However, ftp_ functions are used extensively by SMF's install.php and the Package Manager, so you'd have to remember to enable them before using those functions.

Basically, you just have to keep attackers out so they can't get to the "import a remote file" stage of the attack. The first "import a remote script" is often done by injection of a URL in a query string, so allow_url_fopen = Off will usually prevent them from getting to the second stage. Also blocking libwww-perl in .htaccess will help, as it is the most common User-Agent used (actually the only one I've seen used so far).

Once they're in, allow_url_fopen = Off won't prevent them from using the ftp_ functions. (I realized that just now: the Package Manager upgrade from 1.1.3 to 1.1.4 a couple days ago was successful even though allow_url_fopen was Off in php.ini.)

There is also one called 'links', but I think last I saw that was RH7.3.

PHP runs as the apache child process user. So you could just remove the execute bit for everyone else but root:root with chmod 754. But I'm not sure if that could break something like yum, apt-get, etc.

But then you have scp, ftp, and so many other ways to d/l something...