2

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

3
  • might be better of on stackoverflow.com
    – Patrick R
    Aug 11, 2010 at 20:11
  • @Patrick They'd only send it back here.
    – Andrew
    Aug 11, 2010 at 23:51
  • Or maybe security.stackexchange.com.
    – Ladadadada
    Nov 16, 2011 at 18:46

6 Answers 6

3

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.
1
  • 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, 2010 at 17:12
3

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

1
  • 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, 2013 at 12:08
2

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).
2

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.

1
  • eval is language constructor, so it cannot be disabled via disable_functions
    – Guntis
    Sep 10, 2013 at 7:23
1

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.

-1

Here’s a six step guide on Cleaning php eval(base64_decode()) hack from a WordPress site and how to prevent it from occurring again?, which i found recently, and they have jotted down some nicely written things which you may want to have a look at . https://secure.wphackedhelp.com/blog/eval-base64-decode-hack-wordpress/

(key-points of the article being)

What is eval base64 decode?
What does eval base64 decode code do?
How does php eval(base64_decode works?
How to identify & get rid of eval-base64_decode like PHP virus? [Various tools to decode base64 string]
Tips for Staying Safe in the Future

Apart from this, they have also shown an example decoding of how a malicious code such as eval would work in an infected site

1
  • Please state the details of the solution here, so your answer will still be useful when the linked article goes away. Mar 22, 2018 at 14:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .