I had a virus attack on my website: malicious code had been added to different zenphoto index.php files.
any idea to detect and correct all the infected files ?
thanks for help
The same happened to me today, my htaccess files got edited and put in som redirections, see part of the redirects below
ErrorDocument 400 http://network....
ErrorDocument 401 http://network...
ErrorDocument 403 http://network...
ErrorDocument 404 http://network...
ErrorDocument 500 http://network...
ADMINISTRATOR NOTE: Code example editied because it seems to alert virus scanners
Hello, i've also been hacked recently but i've found where the problem was thanks to the log :
92.63.104.34 - - [08/Nov/2011:19:49:50 +0100] "POST /zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager/inc/class.images.php?truecss=1 HTTP/1.1" 200 53 "-" "User-Agent: Mozilla/5.0 (Windows; u; Windows nt 5.1; en-us; rv:1.9.1.5) gecko/20091102 firefox/3.5.5 gtb5"
It was an old problem detected in tinymce File Ajax manager, it seems that the hacker has the ability to upload desired files on the server and also replace .htaccess files in order to redirect to some malware site. I have deleted this plugin because i have no use of it but update tinymce or zenphoto should be a good alternative. Also check the last modified date of your files, you will easily find out the concerned files.
The uploaded file was a file called class.images.php and index.php, the last one is empty but the class file contain this code :
`
Array
(
[d] =>
Seems to be a pretty new bug http://www.devilscafe.in/2011/10/tinymce-ajaxfilemanager-remote-file.html
Have you actually tried this on your zenphoto installation? Just wondering, because of two things:
First, the search that web page suggests is pretty useless. Too many legitimate results to sift through.
Second, If I do manage to browse to the filemanager script I can get it to load the page, but it is locked into the "uploaded" folder and anyway I could not get an upload to actually work.
i didn't try it, but it seems you already fixed it in the current version http://www.zenphoto.org/trac/ticket/2005
Maybe you can warn your users to avoid further damages.
It doesnt work like that, a pretty easy script is hosted on a server with a post to various websites, those websites can easily be crawled by bots if they know what to look for, as an example a comment like or something else. To me zenphoto could have been spotted as a potential hackable cms, I hope im wrong, but the real problem is in ajaxfilemanager.php, it must be updated to avoid these hack.
Hi,
I also had an attack on some of my websites working on an old release of ZP (I know I should update them).
I fixed ajax_create_folder.php refering to http://www.zenphoto.org/trac/ticket/2005
Then I've deleted ajaxfilemanager/inc/class.images.php and removed the content of ajaxfilemanager/inc/data.php
The script was creating .htaccess in my folders trying to redirect to some russian adresses.
Check if a bot called "MaMa CaSpEr" crawled you site.
@peacepostman : what did you change in ajaxfilemanager.php ?
@Lithium: The ajax file manager issue is actually fixed in 1.4.1.5 already. We alway urge to upgrade as we don't do these updates for no reason. Note that the ajax file manager is actually a 3rd party tool we just use (see the ticket edouardito linked). and its developer had been informed by the reporter of ticket #2005.
Recently a lot of these security reports flooded twitter (these sites tend to copy from each other anyway) and they all address 1.4.1.4. Of course if anyone finds other potential security issues feel free to let us know via the forum, bugtracker or even for security reasons via our contact form.
If any file has been replace it might be a good idea to check permissions and the server configuration. If that is too loose Zenphoto is not even involved. Also inform your host about it as it is also possible that someone got into the server itself (happen a few weeks ago to a quite big German hoster).
Does anyone know what this hack did.
We had the same problem and had to reupload all php files
I worried about what the hack actually did.
It injected this code to all our php zen files.
global $sessdt_o; if(!.... }
ADMINISTRATOR NOTE: Code example editied because it seems to alert virus scanners
Sorry that you have been hacked. See for more discussion: http://www.zenphoto.org/support/topic.php?id=9942&replies=21#post-58257
If you lost descriptions on an upgrade you did something wrong, sorry to say that. If you keep the zp-data folder and its config file intact (e.g. the same database credentials) nothing will be lost. Also a good idea is to use the database backup tool before upgrading so you always can revert.
@darkufo: The hack seems to set a cookie via Javascript and then is able to execute code that has been passed via POST. What exactly I cannot see.
There is an url and if I google that it seems that is some film related site. Either this is a very bad and illegal way of selfpromotion or they have been expoited as well.
Sad to say I also experienced an attack on my Zenphoto installation. It was flagged to me by my hosting company as "Malware" on http:......./zenphoto/zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager/ajax_create_folder.php
I have updated my installation to 1.4.1.5(8326) (from 1.4.1.4), disabled tiny_mce and deleted its folder in /zenphoto/zp-core/zp-extensions. Hopefully that will shut the door on any other attacks.
Interestingly following this thread I checked my cookies and found several with a .ru domain name extension! Logging out of Firefox and back in they had all disappeared (I have the option set to accept all cookies but delete them when I log off).
One other query if I may: I have Sitewatch (sitewat.ch) enabled on my site and it has flagged an XSS vulnerability on /zenphoto/page/search/ using the input:
alert(123)
It comes up as no matches found, of course, but is it something about which I should worry?
Mowgli
That code would presumably have displayed a javascript alert: 123 had the exploit worked.
Anyway, Search parameters are sanitized when retrieved and html encoded when displayed so that code fails to execute.
[edit] Well, at least standard themes do the html encoding. I cannot guarantee that third party thems do the same. If not there could be a vulnerability.