After deleting the ajaxfilemanager folder in my installation, following the guidelines in this thread, I searched all files under the zenphoto tree for the strings "lb11" and "eval(base64" and found no instances. I also found no tmp* files in the tree. In addition, the only objects bearing the date of the attack (11/15/2011) were the bogus class.base.php file and the inc folder under ajaxfilemanager. .htaccess also does not appear to have been modified. It would appear that I was spared the full assault that some have experienced.
Did anyone find evidence of damage beyond your zenphoto structure?
I recently updated zenphoto to the version 1.4.2.3 because I changed my hosts. After I updated it I noticed I was getting a lot of error messages because the file relating to this virus attack is trying to be accessed. /zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager/inc/data.php
Before I did the upgrade I did not receive any error messages that something was trying to access this file, after I did the upgrade I have been getting hundreds of attempts from many different ip's. Basically every couple of minutes something was trying to access this file.
After reading this thread I trashed the ajaxfilemanager plugin even though the upgrade fixes the problem.
Because I was getting tired of receiving 404 error message emails I ended out redirecting /zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager/inc/data.php to my homepage through my .htaccess file. Can this redirection cause a problem? If this virus does not find what it is looking for will it stop trying to access the file eventually?
Due to my lack of diligence in maintaining Zenphoto on my install I missed updating it. The site was hacked and I have spent the last week resetting permissions on files all over the server and every .htaccess file was modified with every image pointing to some .ru site. Deleted the site for now and will install the back up and check that for damage - if its damaged may just opt for a clean install.
We actually choose to have only the troubleeshooting guide as a collector article (done automatically and not the individual troubleshooting articles because that would clutter tthe user guide a little (29 vs 98 articles). But maybe we rethink that.
Sorry to bring this up again but I need some advice. I am trying to install the latest download of zenphoto (1.4.4)onto my web server. This is a shared webserver not dedicated. I have removed everything that I have access to from the server so is as 'clean' as I can get it. However, once the .htaccess file is created when I go to setup.php, I get the redirection to networkteaser appearing. I tried removing the ajax plugin as stuggested in the threads but the problem still occurs. Is it feasible that the problem could be with the server or am I missing something?
Try clearing your webspace again en re-install Zenhoto WITHOUT having setup create the .htaccess. You won't be able to use mod_rewrite then but it might shed some light on you issue.
Btw. the ajaxfilemanager should be safe now.
EDIT: Easier is to first just delete the .htaccess file.
Comments
Did anyone find evidence of damage beyond your zenphoto structure?
Before I did the upgrade I did not receive any error messages that something was trying to access this file, after I did the upgrade I have been getting hundreds of attempts from many different ip's. Basically every couple of minutes something was trying to access this file.
After reading this thread I trashed the ajaxfilemanager plugin even though the upgrade fixes the problem.
Because I was getting tired of receiving 404 error message emails I ended out redirecting /zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager/inc/data.php to my homepage through my .htaccess file. Can this redirection cause a problem? If this virus does not find what it is looking for will it stop trying to access the file eventually?
Many thanks,
James
You won't be able to use mod_rewrite then but it might shed some light on you issue.
Btw. the ajaxfilemanager should be safe now.
EDIT: Easier is to first just delete the .htaccess file.