Unfortunately it's very likely that your installation has been hacked. If that's the case, then it's unsafe to trust any of the PHP code on your system; the safest thing to do is:
- Determine the means of attack. Vulnerable file permissions are a common cause; find out what username your server runs PHP scripts under and see if those files were writable by that account. If so, until you can change permissions to something safe, don't bother trying to fix it. For web-based attacks (the most common case), you can often correlate the last modified dates of modified files against the server's access log to identify the attack request.
- Use a standard tool like "diff" to compare everything in your installation to the stock version that should be there. This will identify both your own patches and the attacker code; ensure that all that's left is original code and your patches. (The recursive option to diff is useful for this.)
- Once you're sure that you've closed the vulnerability, and you've cleaned all attack code out by comparing it comprehensively to the original release, put the site back online.
If your server runs mod_php, then all scripts on the server will run under a common user account (typically "apache"). If any scripts are writable by that account, a single vulnerability anywhere on the server (e.g. someone's unmaintained install of Drupal) will be sufficient to launch an automated attack. This is very common. For this reason, we recommend using FastCGI rather than mod_php and configuring it to run each application under a different user account.
Public Knowledge Project Team