[Plugin: W3 Total Cache] W3 total cache and security

None of that is due to w3tc. Your SERVER is compromised. Talk to your host.

lincolnthree – I deleted EIGHT of your posts about this.

Nothing you pointed at is a problem with the plugin. That .htaccess is 100% correct and as it should be. By putting up so many posts, you’re tripping the spam filter, so I need you to stop that ??

Contact your webhost for support, and if you want to, send the info via the Support link in the plugin (go to the plugin settings page, there’s a tab there for it).

Hello Ipstenu,

May I make some friendly suggestions?

First. You obviously have several people experiencing the same problem manifesting itself in what appears to be the same way. Telling them to go somewhere else is not exactly a great response. Why not encourage them to work out the issue so that future people who stumble upon this (until now) helpful or related post, might have a chance to figure out how to fix the issue. No matter the cause.

Second. May I suggest that instead of deleting the posts that I made in good faith, and took a good deal of time to research, that you let anyone who wishes to attempt to help with this issue do so. There was no reason to remove my content. Now people who read this will simply wonder what you deleted and have no more idea of how to get to the root cause than they did before. “Too many actually related posts in an attempt to help” does not seem to warrant being censored.

Third. I understand that you wish to make the point that W3TC is not the source of this hack, but until you can prove that it is not, or someone can prove that something else *was*, I find your actions to be inhibiting the issue resolution process.

Thanks for your “help.” I’m sure you meant well, but that’s not what it seems to have turned out to be. You deleted the most useful of my posts and left the single one that looks like it supports your perspective.

-Lincoln

PS. Still problem free after deleting W3TC.

Hello,
I initially start this post.

I’ve deactivated and deleted the plugin from that date and curiously i do not have any problems anymore. No more Hack, no more curious files, etc…

I remember that if I activate the plugin, I was infected less than 24 hours later.

It was just to share.

Dimitri

Are you sure you followed all of the installation instructions? Because they tell you how to close your permissions back down after the installation. There would be an enormous number of issues if this was commonplace.

Yes, i’m sure. Sorry, but i know what i am doing. I know what security means.
I do not trust this plugin. I saw other website infected using your plugin.
You should really admit that you have a serious security issue and try to search and find a solution.
With that kind of security hole, I can not believe that your plugin is still downloadable on WordPress plugins.

Please believe users testimonials on this post.

Regards
Dimitri

Who is doubting you? Why do you think I’m replying? I’m asking simple questions and you’re telling me that I don’t believe you. So far you have given no steps to be able to duplicate or investigate and you’ve told anyone that questions you that they are wrong.

Plugins that write files or that are mis-configured can be targeted by hackers and hosts can operate their servers insecurely. I don’t think I should have to make the point again, that if the issue was widespread, this post and others would be more active.

So can you provide any useful information for finding the issue? Or are you here only to question my judgement and integrity?

Do you know how to use git? Can you check to see what other files have been modified on your server making them inconsistent with the distributed version of WP, it’s themes, plugins or any third party plugins from www.ads-software.com or the vendors that made them?

Hey,

I found this topic after looking if W3 is possibly injected with code ?? I am getting these errors when running exploit scan:

plugins/w3-total-cache/lib/Microsoft/WindowsAzure/Credentials/CredentialsAbstract.php:111

$this->_accountKey = base64_decode($accountKey);

plugins/w3-total-cache/lib/Microsoft/WindowsAzure/Credentials/CredentialsAbstract.php:135

$this->_accountKey = base64_decode($value);

plugins/w3-total-cache/lib/Microsoft/WindowsAzure/Storage/Queue.php:467

base64_decode((string)$xmlMessages[$i]->MessageText)

plugins/w3-total-cache/lib/Microsoft/WindowsAzure/SessionHandler.php:150

return base64_decode($sessionRecord->serializedData);

plugins/w3-total-cache/lib/Minify/FirePHP.php:1035

* Javascript, and can be directly eval()’ed with no further parsing

plugins/w3-total-cache/lib/Nusoap/class.soapclient.php:711

eval($evalStr);

plugins/w3-total-cache/lib/Nusoap/nusoap.php:7020

return base64_decode($value);

I found this topic after looking for

Frederick could you please let me know if this is safe code or not?? Or is it safe to delete these lines?

That code is part of the Windows Azure distribution / library. Just like Minify or other libraries W3TC uses, it’s from a 3rd party and being that it’s open source, i trust that it’s as secure as other code on the web.

I’m beginning to point to W3TC as having caused or allowed some kind of intrusion on my site as well. I’ll start from the beginning.

Site A. This site had never had a cache plugin installed. It had been running for about 12 months and I decided to optimize and speed it up. I installed W3 total cache and went through the configuration. When I deployed, the site instantly was infected with a redirect injection.

Site B. I actually set this site up a month or so back. Last night I decided to actually deploy the W3 plugin on this site as well. Same thing – although this one took about a minute before it was seen on the live site. Same injection code.

Site C. Same basic story as A and B – working with W3 – instant infection and only when I am logged in an making changes to W3. Again – infection was instant while I was configuring.

In both cases I also had FileZilla open – which I haven’t ruled out as the problem. But I can say I have FileZilla open most of the day and don’t see problems with sites. But…. with the combination of having FileZilla open and working with W3 causes an instant infection.

Could it be something that gets easy access to the .htaccess file through W3 while FileZilla is open?

We haven’t seen any vulnerability reports (public or private) against W3 Total Cache.

A number of intrusions disguise themselves as files of WordPress core, Akismet, and other plugins. Given how widely used W3 Total Cache is, it is likely being targeted in similar ways. Akismet, WordPress, and W3TC aren’t necessarily the problem (and are very likely not the problem) — they are just being used as camouflage.

I would take a much closer look at your server, and especially your access logs. (Or enlist the help of guys like Sucuri.) Once you have an entry point narrowed down, you’ll have a better idea of what is really going on.

I do subscribe to Sucuri and they have cleaned the site up for me. I responded to their support ticket to see if I could get a little help with the server logs or identifying an entry point.

I’ll post an update with what I find.

I’m certain that if the securi guys were seeing lots of reports related to W3TC they would notify me offline and an update would be made post-haste otherwise the www.ads-software.com team would pull the plugin from the repository to help the community.

can we use this plugin as script optimiser

Yes, if I understand you correctly, that is exactly the intent.