Eval base64_decode php
So, it appears that there are some subtle variants on the site hacked in google and returning viagara or cialus, however those are spelled. But I believe the attack vector is the same and the protection is the same.
On shared hosting, which isn’t completely the culprit by the way, the usernames for the web server and the ftp account are usually the same, which means that the user permissions are shared throughout the site. This is key to allowing an attacker to easily update any of the files in your site. On shared hosting, where the file system is owned by a specific user throughout – this makes it possible to do updates to the code right from in page admin which is desirable.
The real culprit I believe to be unprotected file uploads which allow php code to be uploaded. This can either be via no user/password protection or non-sanitized file uploads. These two should probably exist together, but at a minimum, there should at least be a cleansing process or normalization.
The code that usually gets uploaded first is the injection point which may look something like eval(base64_decode()); attached to some form of data uploading allowing for remote commands. Which effectively becomes a command proxy that can act on any file in the site due to the site wide file permissions.
Discussing with a collegue, I thought, lets disable php execution in any file uploads section, but also I suggested, lets look into overloading eval with a override_function call, and a auto_prepend in php – but first that means there has to be no eval calls in any modules or CMS code. At a minimum, you can rename the original function and replace all of the good eval calls with some secure version ( IE, pass in a special second parameter that the attacker wont be able to use in any random site ). Another method would be to protect file upload directories to the point where it requires php in the middle to do a readfile call on as opposed to direct access preventing php execution. And of course, using .htaccess files or http.conf which disables php in those directories.
The real culprit might be better sanitization of file uploads via php or flash. Most people thus var have tried to validate based on file extension, mime type, size, magic numbers. I am wondering now, if we can’t merely use a preg_match to look for the <?php or <? starting tags which are required by the web server to run php.
Into the Specifics
In one particular instance, I saw every starting php tag in the site replaced with an eval code which, slows things down a bit and redirects your traffic effectively stealing your SEO. The interesting thing is that, when you go directly to the site, the site returns happily and normally with your content.
This can easily be fixed with shell access using a
find . |xargs sed -i
combination that will be specific to your case scenario.
At any rate, I am tired of talking, so if you have any questions, comment. One note should be made about running your own servers with suhosin patch, php safemode on, and disabling php functions such as eval directly.
