I know I can't be the only one facing this challenge lately.
We are seeing dozens of info.php files peppered all of a few of our servers lately in almost any directory that has permissions allowing the webserver to write to it. The file is used to send spam. The problem is easy enough to clean up, but what I am having issues with is the mechanism that is used to place it there.
Some additional information:
open_basedir = on
apache is run as nobody.
The files are almost always placed around/near the same time and always owned by nobody.
And please, save the cookie cutter suggestions for someone else. Don't tell me to install firewalls, do port scans, disable lynx/wget/curl. I know this stuff already, what I am looking for is someone with firsthand knowledge of the mechanism someone is using to deposit this payload.
Best bet is to look at the logs at around the time it was done. Compare the timestamps of the files to that time in your server logs and look for connections. Chances are it's remotely scripted or working through some script on the box/account. The logs should help determine that.
Having problems, or maybe questions about WHT? Head over to the help desk!
You might be able to match the mod time on the info.php files to a script that was run around that time; that's about all you can do unfortunately as you are obviously running PHP as nobody. Good for performance if you really really need it, very very bad for security.
Some things you could do:
Run mod_security and block info.php. This may help you find the exploiting IP as when the block is hit, you can check the mod_security log and find the IP that triggered it and then go look in your logs for what scripts that IP was hitting.
Switch to suphp. This will prevent the exploit from being useful in the first place as user .php files will run under the user account and won't have access to write to other accounts and to see other account's files. Any exploit files left lying around will help you track the exploit as they'll have the ownership of the compromised account. Any .php files they write won't be able to be run by other accounts (as suphp prevents it if the ownership is wrong). This will solve your problem here forever as you'll be able to remove write from all globally writable directories (it's no longer needed).
It's quite likely all the sql passwords that were in .php files have been compromised since they're readable to rogue processes when you don't run under suphp. If you find other exploits happening, go change all the cpanel passwords that match sql passwords, then change the sql passwords. Ugly, and a lot of work -- good luck!
Something that will make it harder for the bad guys is for you to install CSF. This teams up well with mod_security; any IP caught repeatedly probing script security (with the patterns you load into mod_security) will be blocked which severely restricts the ability of the bad guys to probe for vulnerable scripts. Sorry to give you firewall advice but it's part of the right answer!! Good security consists of multiple layers.
As a general note - there are lots of exploits this could come from. It depends on the range of installed software tremendously so it's unlikely anyone can say anything specific to help (although a regular google for info.php won't hurt anything!). For instance, as just one example, there is a vulnerability in many versions of Mambo/Joomla that allows download of arbitrary code via a register_globals hole coupled with mosConfig_absolute_path. One easy way to trap much of this is to prevent http:// in HTTP request variables - works a treat and don't think we've hit anything it's broken here.
To build on what bear had to say, a simple option doable by hand (also agree with brianoz's excellent advice) -
1. Look up timestamps on the info.php. A skilled person would have modified the timestamp, but these seem like cookie cutter breakins
2. Look at all scripts accessed in the 3 minutes or so preceding that timestamp [Apache logs]. Specifically look for POST requests - they are more likely to be the ones used
3. Narrow it down to a list of say 5 or 10 or 20 scripts. In each script, add a new include that just logs as much as possible - raw HTTP request would be good, but if not, atleast the POST data + Cookie. Since different scripts use different input, you need to record as much of the input as possible.
4. Check the log file every 24-48 hours for the info.php and other suspicious data posted
5. Once you've built a list of 2-3 scripts that look like they may have issues, check for updates if they are public scripts. If you dont find updates, get somebody experienced with security auditing to audit and fix them. There may be more than one hole.
Thanks for the replies so far. But what really baffles me is the fact that with open_basedir bad php scripts shouldn't be able to drop off copies in other directories. But from the volume and times of the files, it is obvious that it is some process that is dropping them all off.
Does open_basedir handle system, exec, or similar functions? From the reference it seems to apply only to functions that operate directly on files. If it doesnt apply to those, then you can just exec shell commands that create the first file. Then from the first shell, create the others.
(1) From the PHP Manual comments page - seems as if exec/system/similar is sneaking through
open_basedir only restricts file operations to files and directories under a specified directory, but you can still user system ("vi /home/somedir/somefile"), so safe_mode still has a place here as it is much more restrictive then open_basedir.
(2) The user could just write a php shell script under the open_basedir. Then use that to spread to other folders. I'm not sure if you have covered that possibility.