Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We recently had a website hacked, where some PHP code was injected into the index.php file that looked something like:

eval (gzinflate(base64_decode('s127ezsS/...bA236UA1')));

The code was causing another php file (cnfg.php) to be included, which was causing some pharmaceutical-related spam to be displayed (but only visible to googlebot et al). This looks like the pharma hack for wordpress, except we're not running said software. The code has since been removed, but I'd like to prevent such occurrences from happening in the future.

I realize this is a pretty broad problem and there could be a myriad of security holes which could be responsible, but thought I'd put this out there in case anyone has had experience with such a problem in the past.

What are some potential security holes that would allow these php files to be uploaded? And what can I do to prevent this from happening in the future?

Cheers

share|improve this question
    
might be better of on stackoverflow.com –  Patrick R Aug 11 '10 at 20:11
    
@Patrick They'd only send it back here. –  Andrew Aug 11 '10 at 23:51
    
Or maybe security.stackexchange.com. –  Ladadadada Nov 16 '11 at 18:46
add comment

5 Answers

up vote 3 down vote accepted

You need to find out how that got there.

  • Did the attacker have access to the filesystem through sftp/scp?
    • If this happened you need to lock down your remote access methods
  • Did the attacker use some uploader script or some bug in an existing script that allowed them to modify files?
    • Fix the script, change the permissions on your scripts and web content so that the web server process cannot change them. The web server should be limited to modifying files in a data directory somewhere. Your scripts and files should generally not be owned or write-able by the web server.
  • Did the script come as part of some malicious software you isntalled?
    • I have seen things like that included as part of wordpress templates. An unsuspecting user downloaded templates from some random site. Those templates included the a function to run code off an external web server. This combined with poor permission settings allowed the attacker to modify other things.
share|improve this answer
    
We are pretty confident that it ended up being a vulnerability in phpMyAdmin. The setup script was left in there from when the sysadmin deployed it. We've since removed and hardened phpMyAdmin, so hopefully this doesn't happen again. Thanks! –  1nsane Aug 12 '10 at 17:12
add comment

There's a huge realm of possibilities of how this could have gotten in. One piece of information that helps limit this down is what type of hosting you have (shared, dedicated, virtual), and who your host is. Some potential entry points are

  • Compromise of admin account
  • Compromise of your ftp/ssh/web console/etc account with your provider. If you ever send your password via an unencrypted protocol (like FTP), stop doing that.
  • Compromise of your own local development machine
  • Vulnerability it any of the server software on the server, like Apache or any of its modules.
  • Application-level vulnerability in the PHP on your site:

    • Are you using third party software, and if so is it all up to date?
    • Have you written a significant amount of your own programming on the site? If so, there's a million ways you could have written a hole. Check any method that touches data originating from user input (REQUEST/GET/POST/COOKIES/FILES). If you allow file uploads, do you save those files unfiltered to a web-viewable directory? If so, someone could upload a .php script and then just view it. include/require statements are especially hot targets if you use a templating solution like:

    <?php include $_GET['page'] . '.php'; ?>

How to prevent it from recurring?

  • Make sure you absolutely trust the security of your host. Call them up and grill them on their security policies, how fast they patch their services when vulnerabilities come out, etc.
  • Skip cheapo shared hosting and pay up for dedicated or virtual-dedicated. Less people using the server means less vectors to attack
  • Keep your own third party applications/libraries up to date. Get on their mailing list, RSS feeds, or anything to stay up to date with their releases.
  • Audit your own code. If you aren't experienced enough for this, find someone that is an pay for it.
  • Keep your site in version control like git or subversion. Keep your production directory as a working copy so you can easily detect changes from your code base (but make sure to block access to metadata like .git and .svn dirs).
share|improve this answer
add comment

You will need to find the vulnerability that allowed this code to be uploaded.

I have experienced a similar hack and it was identified as being uploaded by a third party Joomla extension that allows FTP uploads.

In my case I removed the Joomla extension and told the web developer not to install it again.

Depending on your circumstances you may want to disable eval, base64_decode and gzinflate.

You can do this in php.ini by looking for the line

disable_functions = 

and set it to

disable_functions = eval, base64_decode, gzinflate

You will need to restart your web server for the changes to take effect.

It is also worth mentioning that when I scanned the infected file with clamscan it was identified as being malware. I am running ClamAV version 0.96.1

I do not have my notes to hand right now so cannot tell you the exact result.

If it is practical to do so, you could schedule a job to run clamscan against your code at regular intervals (perhaps hourly) to watch for future infections.

share|improve this answer
    
eval is language constructor, so it cannot be disabled via disable_functions –  Guntis Sep 10 '13 at 7:23
add comment

Just a warning.

If you are using FileZilla as your FTP client, there is malware out there that will grab your FTP credentials from the Filezilla PLAIN TEXT FILE (yikes! ) and use that information to insert that malware code (indicated by the #b58b6f# type of code around a "gzinflate(base64_decode)" command. That is how your files will get attacked/compromised.

Look in your %APPDATA%/Roaming/Filezilla folder. One of the XML files in there has all your FTP web site credential (user/password/etc) in PLAIN TEXT! And the FileZilla people refuse to fix that obvious security hole.

My recommendation: delete FileZilla from your computer (and you have to manually delete the folder in your APPDATA folder).

If you need a secure FTP client, use WinSCP (www .winscp .net ), where you can set a master password and all of your site credentials are encrypted.

Just a warning....Rick...J

share|improve this answer
    
This is probably exactly what happened to my client and freelancer's work. Backdoors got installed via leaked FTP access. Thank you for this helpful answer. –  Maurice Jun 6 '13 at 12:08
add comment

You may wish to try http://www.hardened-php.net/suhosin/ which, among other things, could have disabled eval(). If cnfg.php was hosted remotely it could have prevented it from being included as well.

If possible do not grant the user the web server is running as write access to the the php files.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.