Well, it is not that Zenphoto is the first and surely not hte last CMS this happens. And it is actually not our fault if it is the file manager only - we surely cannot check every 3rd party tool we use...
I love the simplicity and elegance of Zenphoto but if something goes wrong, whether directly due to Zenphoto or not as in this case, it's great to see prompt support and the news being put out there
I've been hacked too Thanks to my ISP I have cleared the .htaccess files , they were present in the zp-core , zpextensions and the tinymce folders.
The .htaccess files created files called thumbsdata.php
Here is the code inside one of the htaccess files: RewriteRule !thumbsdata.php <editied by moderator)/ext/?r=%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
The hack also created .htaccess and thumbsupdata.php in my root directory (above my public_html folder) and it was causing redirection in other folders not just the zenphoto folder
So, if you have zenphoto in a sub directory of your server, reinstalling zenphoto is only part of the solution, check the folders above it.
addendum i have a load of php scripts across all of my other folders infected with the piece of bad code as above. So i'm having to reinstall everything... sigh
Well it seems something is afoot with my site now, as well. I was running 1.4.2. It was working a day or so ago. I have made no changes or updates, and now it is demanding the setup scripts again.
I haven't found any malicious looking code, yet. Still searching.
This script seems to be having a lot of troubles lately...
NOt having troubles. Zenphoto will want to run setup if its environment has changed. So if you get the setup scripts missing message then something has changed on your site that Zenphoto thinks needs attention. Maybe something that your provider has done?
My host hasn't changed anything. There's a suspicious timestamp on the zp-core directory, but I can't find anything modified within. Looks like whatever was done was deleted afterwards, but I will keep searching.
I've seen you guys respond to posts of this nature with "Well, you must have upgraded or something" even when the user posting insists they haven't. This kind of attitude is NOT helpful. It comes across as "LA LA LA I CAN'T HEAR YOU - NO PROBLEMS HERE".
If the script is being modified by an outside source, it is definitely having problems with security. If you'd stop denying that, it might be possible to track down and fix.
Well, we do respond that way as that is why this message could come up only. Setup only tries to run if it discovers a change like when you upgraded.
This kind of attitude is NOT helpful. It comes across as "LA LA LA I CAN'T HEAR YOU - NO PROBLEMS HERE".
Please think about if this is the right attitude to get help from volunteers over here...
If the script is being modified by an outside source, it is definitely having problems with security. If you'd stop denying that, it might be possible to track down and fix.
Ok, then how about helping us to find out? It is your server and not ours. So for the start check the permissions.
By reporting it, for starters. Be grateful instead of snippy.
You know, nevermind. I've seen how you two carry on here. You provide the most hostile and unprofessional "support" I've seen in quite awhile. I'm not sure why you even bother going through the motions.
I'll be actively recommending against the use of this potentially unsafe and surely buggy script whenever I see it come up in future.
Sorry, you started by shouting and accusing us actually. We have replied (numerous times on other topics) with what we know about this issue. If somethings got access to your files it must not be Zenphoto's faults (It can but until we know all is guessing). Wrong server permissions, especially if Setup cannot set them on installing is a server matter!
So could we get back on topic and behave adequately now? We appreciate that you reported and we appreciate anything. But as said we don't know of any occurrence that could lead to what you and others encounter. Except the ones we noted. I personally did never encounter this and I run several sites using locally and on several live servers using Zenphoto including our own website.
So I have no idea what could cause this on your server. So you need to help us to find what could have been and if it was Zenphoto or something else (severs itself can have security issues as well) it as only you can investigate that on your server. If there is a security hole left (which always can be, nothing is 100% secure), we surely do everything to fix it.
And if you look around you surely will see that we provide much more support with a much smaller team than other projects with many satisfied users.
I didn't start by shouting anything. If you somehow managed to read shouting in the last line of my initial post about this script having problems, then your level of hypersensitivity is beyond the scope of something I can help you with!
What we have here are multiple users with the same issue. Setup scripts missing, it wants to update, when the user made no changes. A couple of those are explained by obvious hacks, others are not (including mine).
If you really require me to do your thinking for you, a logical first step to identify the issue with something like this would be to output the reason it wants to update the database instead of just a cryptic "setup scripts missing" message. What conditions does it look for? The script version in my database matched my files. The files themselves appear unchanged. It would be simple to add this information. For actual upgrades have it output something like "Version X detected, we need the setup scripts to update from version Y" Where version isn't the issue, output an error based on the condition that was detected. You know what those conditions are better than I do (I hope).
It boils down to one of two things. Something in the script screwed up, a bug, that caused an incorrect upgrade request, or an exploit. You can't just blame every exploit that happens on other server conditions. Many people who have had problems with your script had those problems contained to just your script when they were also running others (which doesn't rule out an exploit elsewhere but does tend to indicate where it may be).
The same goes with your excuses about permissions. Sure, some users may make mistakes with this. Others don't, and you just come across as patronizing if you take it any further than "Did you check permissions". In my case, they were and are all standard for the type of server I'm on, the vast majority being 755 for directories, 644 for files. Attempting to use a 777 on anything will trigger an error 500. It's not a case of screwed up permissions.
Finally, I reported the issue not because I really expected you to do anything about it, based on your previous responses, but because it's the right thing to do for other users that may encounter it. I made no demands. I didn't scream "FIX IT NOW". Your attitude on this board is abhorrent and uncalled for.
Well, I quoted the line I was referring to (And you "accused" that we would not care. We do). Capital letters is synonymous for shouting. Anyway, written text on the net easily is understood wrong. And I admit English is not my first language, so I am not free from this and I was caught on the wrong foot. So apologies for that.
Anyway, since we are back to proper discussion: So let us assume there is a bug somewhere, we need to identify it and that is easier if it is reproducable for us. Which it isn't so far for me. To my knowledge setup checks the core files (number and which) as well. My colleage wrote that script so I cannot answer in detail what all it checks. He surely will join in again later.
I did mention the permissions as I don't know you as you are a newer forum member. Also your profile link shows you as a photographer which not necessarily means to me you have detailed web stuff knowledge. So we respectivlyI start with the basics as you did not post that much details as we have a lot of users that are not so used to that. Often we assume things we should not which turns out one page later. To avoid that we repeat often. Apparently I did you wrong by doing that so apology again and I also don't claim to know everything.
So now we can rule out permissions. Great. So be assured that we don't want setup to run unnecessarily, want to fix any bugs or security issues.
Zenphoto checks the "signature" of your installation each and every time a script runs. It compares this with the signature generated at the time setup was run. If they do not match it wants to re-run setup.
The items checked are:
The Zenphoto release The "Server Software" reported by your server The size of the functions.php script The host path to the zenphoto folder
If by this you mean it compares the version in the zp-core/version.php file to the version number in the database, I can say this matched when it decided it wanted to spontaneously upgrade.
The "Server Software" reported by your server
I haven't found any changes, if there's anything here it would be extremely minor. How are you defining server software? php and MySQL versions?
This still seems like the most likely trigger, but perhaps it needs revising so as not to take down the site for minor changes. We can't all be mashing F5 for the life of our site to make sure it's still visible to the public.
Why not just put a big bold warning in the admin side saying that "X change is detected, please run setup scripts to upgrade" instead of disabling the entire script?
The size of the functions.php script
Unchanged in a byte by byte comparison with the local copy I had uploaded to the server.
On a bit of a tangent, this seems like a poor criteria. There is no good reason that I can see to force a database upgrade should a user tweak or add to this file.
The host path to the zenphoto folder
Without a doubt, unchanged.
Are there any other criteria?
I still think it would be best to output the reason Why the requested upgrade is necessary instead of just "Setup scripts missing".
Well, we simply run setup to decide what has really changed. Really without doing that there is no way of knowing--unless of course you want to have the setup system check overhead each and every time you start a script!
Really now, why do you not simply load the setup scripts and run them? Or is this really a rant post with no real intent to resolve someting?
BTW, what makes you say
There is no good reason that I can see to force a database upgrade should a user tweak or add to this file.
? You perhaps know more about the criticality of this file than we do?
Anyway, this topic is closed. Bottom line is that Zenphoto makes some basic tests to see if there is any need to investigate further. These tests are kept as quick as possible to reduce overhead. It is better that they detect false positives than false negatives. The result of the former is that you re-run setup and nothing needs be fixed. The result of the latter is that there is a burried error that may be next to impossible to diagnose.
Comments
But it seems that Zen is currently on the spammers/hackers radar.
It there anyway you could make an announcement etc to warn people to upgrade to 1.4.1.5 or warn them in some other way.
Do you have a Newsletter or Twitter account etc that you could post to?
I love the simplicity and elegance of Zenphoto but if something goes wrong, whether directly due to Zenphoto or not as in this case, it's great to see prompt support and the news being put out there
I didn't know about this vulnerability, my version was 1.4 (6467)
Thanks to backup tools I restored easily my web sites.
Permissions were loose. Now they are strict on every folder. Less convenient but safer.
Thanks to my ISP I have cleared the .htaccess files , they were present in the zp-core , zpextensions and the tinymce folders.
The .htaccess files created files called thumbsdata.php
Here is the code inside one of the htaccess files:
RewriteRule !thumbsdata.php <editied by moderator)/ext/?r=%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
The hack also created .htaccess and thumbsupdata.php in my root directory (above my public_html folder) and it was causing redirection in other folders not just the zenphoto folder
So, if you have zenphoto in a sub directory of your server, reinstalling zenphoto is only part of the solution, check the folders above it.
You will probably find these 2 rogue files.
My ISP found other insertions of bad code of referring malware due to the hack.
Here is their feedback if it is of help.
MY ISP's REPORT...
Here is the list of files affected by this.
turnitupnow is the malware_domain
==================
root@cleopatra [/home/kingofpo/www/zenphoto]# grep -rli "http://[malware_domain].net/" ./
./dev-tools/trouble.php
./dev-tools/plugins/pseudomail.php
./dev-tools/plugins/zenphoto_package.php
./dev-tools/plugins/zenphoto_package/zenphoto_package_generator.php
./dev-tools/plugins/FilterDoc.php
./dev-tools/plugins/createTSarticles.php
./dev-tools/plugins/PluginNews.php
./dev-tools/plugins/test_deprecated.php
./source.php
./themes/zpgalleriffic_v1.4.1/contact.php
./themes/zpgalleriffic_v1.4.1/news.php
./themes/zpgalleriffic_v1.4.1/index.php
./themes/zpgalleriffic_v1.4.1/archive.php
./themes/zpgalleriffic_v1.4.1/pages.php
./themes/zpgalleriffic_v1.4.1/search.php
./themes/zpgalleriffic_v1.4.1/comment_form/comment_form.php
./themes/zpgalleriffic_v1.4.1/album.php
./themes/zpgalleriffic_v1.4.1/gallery.php
./themes/zpgalleriffic_v1.4.1/image.php
./themes/zpgalleriffic_v1.4.1/password.php
./themes/zpgalleriffic_v1.4.1/404.php
./themes/zpgalleriffic_v1.4.1/themeoptions.php
./themes/zpgalleriffic_v1.4.1/footer.php
./themes/zpgalleriffic_v1.4.1/header.php
./themes/zpgalleriffic_v1.4.1/login.php
./themes/zpgalleriffic_v1.4.1/theme_description.php
./themes/zpgalleriffic_v1.4.1/register.php
./themes/garland/contact.php
./themes/garland/news.php
./themes/garland/index.php
./themes/garland/archive.php
./themes/garland/pages.php
./themes/garland/search.php
./themes/garland/album.php
./themes/garland/gallery.php
./themes/garland/image.php
./themes/garland/password.php
./themes/garland/404.php
./themes/garland/themeoptions.php
./themes/garland/sidebar.php
./themes/garland/main.php
./themes/garland/contact_form/form.php
./themes/garland/theme_description.php
./themes/garland/functions.php
./themes/garland/slideshow.php
./themes/garland/register.php
./themes/stopdesign/contact.php
./themes/stopdesign/index.php
./themes/stopdesign/search.php
./themes/stopdesign/comment_form/comment_form.php
./themes/stopdesign/album.php
./themes/stopdesign/gallery.php
./themes/stopdesign/image.php
./themes/stopdesign/password.php
./themes/stopdesign/404.php
./themes/stopdesign/themeoptions.php
./themes/stopdesign/normalizer.php
./themes/stopdesign/contact_form/form.php
./themes/stopdesign/theme_description.php
./themes/stopdesign/comment.php
./themes/stopdesign/slideshow.php
./themes/stopdesign/register.php
./themes/default/contact.php
./themes/default/index.php
./themes/default/archive.php
./themes/default/search.php
./themes/default/album.php
./themes/default/image.php
./themes/default/password.php
./themes/default/404.php
./themes/default/themeoptions.php
./themes/default/theme_description.php
./themes/default/slideshow.php
./themes/default/register.php
./themes/zenpage/contact.php
./themes/zenpage/news.php
./themes/zenpage/index.php
./themes/zenpage/archive.php
./themes/zenpage/pages.php
./themes/zenpage/search.php
./themes/zenpage/album.php
./themes/zenpage/gallery.php
./themes/zenpage/image.php
./themes/zenpage/password.php
./themes/zenpage/404.php
./themes/zenpage/themeoptions.php
./themes/zenpage/footer.php
./themes/zenpage/sidebar.php
./themes/zenpage/theme_description.php
./themes/zenpage/functions.php
./themes/zenpage/slideshow.php
./themes/zenpage/register.php
./themes/effervescence_plus/contact.php
./themes/effervescence_plus/news.php
./themes/effervescence_plus/index.php
./themes/effervescence_plus/archive.php
./themes/effervescence_plus/pages.php
./themes/effervescence_plus/search.php
./themes/effervescence_plus/album.php
./themes/effervescence_plus/gallery.php
./themes/effervescence_plus/indexpage.php
./themes/effervescence_plus/image.php
./themes/effervescence_plus/password.php
./themes/effervescence_plus/404.php
./themes/effervescence_plus/themeoptions.php
./themes/effervescence_plus/sidebar.php
./themes/effervescence_plus/theme_description.php
./themes/effervescence_plus/functions.php
./themes/effervescence_plus/slideshow.php
./themes/effervescence_plus/register.php
./zp-data/zp-config.php
===============================
i have a load of php scripts across all of my other folders infected with the piece of bad code as above. So i'm having to reinstall everything... sigh
find . -name .htaccess -exec rm -rf {} \;
find . -name lmdex.php -exec rm -rf {} \;
I haven't found any malicious looking code, yet. Still searching.
This script seems to be having a lot of troubles lately...
I've seen you guys respond to posts of this nature with "Well, you must have upgraded or something" even when the user posting insists they haven't. This kind of attitude is NOT helpful. It comes across as "LA LA LA I CAN'T HEAR YOU - NO PROBLEMS HERE".
If the script is being modified by an outside source, it is definitely having problems with security. If you'd stop denying that, it might be possible to track down and fix.
You know, nevermind. I've seen how you two carry on here. You provide the most hostile and unprofessional "support" I've seen in quite awhile. I'm not sure why you even bother going through the motions.
I'll be actively recommending against the use of this potentially unsafe and surely buggy script whenever I see it come up in future.
So could we get back on topic and behave adequately now? We appreciate that you reported and we appreciate anything. But as said we don't know of any occurrence that could lead to what you and others encounter. Except the ones we noted. I personally did never encounter this and I run several sites using locally and on several live servers using Zenphoto including our own website.
So I have no idea what could cause this on your server. So you need to help us to find what could have been and if it was Zenphoto or something else (severs itself can have security issues as well) it as only you can investigate that on your server. If there is a security hole left (which always can be, nothing is 100% secure), we surely do everything to fix it.
And if you look around you surely will see that we provide much more support with a much smaller team than other projects with many satisfied users.
What we have here are multiple users with the same issue. Setup scripts missing, it wants to update, when the user made no changes. A couple of those are explained by obvious hacks, others are not (including mine).
If you really require me to do your thinking for you, a logical first step to identify the issue with something like this would be to output the reason it wants to update the database instead of just a cryptic "setup scripts missing" message. What conditions does it look for? The script version in my database matched my files. The files themselves appear unchanged. It would be simple to add this information. For actual upgrades have it output something like "Version X detected, we need the setup scripts to update from version Y" Where version isn't the issue, output an error based on the condition that was detected. You know what those conditions are better than I do (I hope).
It boils down to one of two things. Something in the script screwed up, a bug, that caused an incorrect upgrade request, or an exploit. You can't just blame every exploit that happens on other server conditions. Many people who have had problems with your script had those problems contained to just your script when they were also running others (which doesn't rule out an exploit elsewhere but does tend to indicate where it may be).
The same goes with your excuses about permissions. Sure, some users may make mistakes with this. Others don't, and you just come across as patronizing if you take it any further than "Did you check permissions". In my case, they were and are all standard for the type of server I'm on, the vast majority being 755 for directories, 644 for files. Attempting to use a 777 on anything will trigger an error 500. It's not a case of screwed up permissions.
Finally, I reported the issue not because I really expected you to do anything about it, based on your previous responses, but because it's the right thing to do for other users that may encounter it. I made no demands. I didn't scream "FIX IT NOW". Your attitude on this board is abhorrent and uncalled for.
Anyway, since we are back to proper discussion: So let us assume there is a bug somewhere, we need to identify it and that is easier if it is reproducable for us. Which it isn't so far for me. To my knowledge setup checks the core files (number and which) as well. My colleage wrote that script so I cannot answer in detail what all it checks. He surely will join in again later.
I did mention the permissions as I don't know you as you are a newer forum member. Also your profile link shows you as a photographer which not necessarily means to me you have detailed web stuff knowledge. So we respectivlyI start with the basics as you did not post that much details as we have a lot of users that are not so used to that. Often we assume things we should not which turns out one page later. To avoid that we repeat often. Apparently I did you wrong by doing that so apology again and I also don't claim to know everything.
So now we can rule out permissions. Great. So be assured that we don't want setup to run unnecessarily, want to fix any bugs or security issues.
The items checked are:
The Zenphoto release
The "Server Software" reported by your server
The size of the functions.php script
The host path to the zenphoto folder
This still seems like the most likely trigger, but perhaps it needs revising so as not to take down the site for minor changes. We can't all be mashing F5 for the life of our site to make sure it's still visible to the public.
Why not just put a big bold warning in the admin side saying that "X change is detected, please run setup scripts to upgrade" instead of disabling the entire script? Unchanged in a byte by byte comparison with the local copy I had uploaded to the server.
On a bit of a tangent, this seems like a poor criteria. There is no good reason that I can see to force a database upgrade should a user tweak or add to this file. Without a doubt, unchanged.
Are there any other criteria?
I still think it would be best to output the reason Why the requested upgrade is necessary instead of just "Setup scripts missing".
Really now, why do you not simply load the setup scripts and run them? Or is this really a rant post with no real intent to resolve someting?
BTW, what makes you say ? You perhaps know more about the criticality of this file than we do?
Anyway, this topic is closed. Bottom line is that Zenphoto makes some basic tests to see if there is any need to investigate further. These tests are kept as quick as possible to reduce overhead. It is better that they detect false positives than false negatives. The result of the former is that you re-run setup and nothing needs be fixed. The result of the latter is that there is a burried error that may be next to impossible to diagnose.