POST exploit ?

[jmelson]

I am still using 2.0.3 RC4, I haven't had time to set up a new store under 2.2, but I have tried to perform all the security changes that have been recommended.

In the last couple days, I have observed my mail server sending out a bunch of spam, and finally traced it to somebody using an http POST transfer to .../catalog/images/yahoo/index.php

My quick fix was to rename the yahoo directory to a random string, as I don't use the Yahoo interface. Eventually, the spammer will figure out another php script that he can pull the same stunt on.

Does anyone know exactly what is going on here, and how to prevent POST operations from being performed like this? I assume I have a security weakness somewhere in my system, but I'm not an expert in this stuff.

Thanks,

Jon

[michael_s]

There is no such version 2.0.3 RC4 of osCMax.

You are either running 2.0 RC4 or 2.0.3 Stable. Please confirm the version you are actually running.

If RC4 there are exploits that need to be fixed. The images/yahoo folder is NOT part of osCMax, so delete it.

Next, look for any other php files in your images folder and delete them. They are not part of osCMax.

[jmelson]

Originally Posted by michael_s

There is no such version 2.0.3 RC4 of osCMax.

Well, server information says 2.0.3, but I distinctly remember using a special version that allowed you to run with register_globals off. I am running with register_globals off, but maybe I updated to 2.0.3 because it also could run with that setting off.

Anyway, I *THINK* I have found the problem, not osCMax at all except that the only reason I have php is for the web store. There is another php setting, allow_url_fopen that was on by default. it appears to not be required by osCMax, and permits users to inject arbitrary external files into php scripts when they are called up. I have set this to off, but can't tell for sure whether this has fixed the problem as the spammers are still trying to use the now deleted files.
Anyway, this appears to be a pretty dangerous option to have on by default.

Thanks for the info,

Jon

[michael_s]

Well, server information says 2.0.3, but I distinctly remember using a special version that allowed you to run with register_globals off. I am running with register_globals off, but maybe I updated to 2.0.3 because it also could run with that setting off.

2.0.3 has no issues running with globals off. Now, was this a clean install or did you upgrade a live site from a previous version?

Check to see if you have this in your admin/includes/application_top.php:
r169 - oscmax2 - Project Hosting on Google Code

[jmelson]

I must have had 2.0, then went to the RC4 version so I could turn register_globals off, and then must have upgraded to 2.0.3
So, I'm pretty sure it was an upgrade, not a clean install. I certainly did not re-build the store manually.
Yes, I have that version of application_top.php, at least judging from the time stamp at the beginning of the file.

Anyway, the hackers are not accomplishing anything now, as all their POST commands are pinting to files that don't exist. I don't know when, or if, they will catch on to this.

Thanks,

Jon