New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
W3 Total Cache Remote Exploit - Wordpress
http://seclists.org/fulldisclosure/2012/Dec/242
SecFilter "dbcache"
Comments
thanks
Nifty. Uggh. More Word-de-press.
People are going to come back after the holidays to some surprises from that.
I m glad to use the thing with fewer plugins possible. Thanks for the warning
thank you for this!
Seems like that would only be impacted if
1) You're using file-based caching for dbcache (opcode is preferred).
2) You're allowing outside access to the wp-content/w3tc/dbcache folder.
Also the comment bout not being in .htaccess, should not be heavily relied upon, primarily since not everyone uses apache.
in Nginx could have something like:
Since only php would be accessing it (not the web), and that's assuming of course the cache files aren't using something like txt, or php extension which may be caught by a regular expression block (in which case location ^~ /wp-content/w3tc/dbcache would override any possible regular expression blocks).
It's kind of the same sense of not allowing executables to run from your wp-uploads folder, which isn't normally blocked in the htaccess anyways.
By default folder listings are not done in nginx (you have to tell it to explicitly).
Seems like W3TC should have maybe a 'tweak' to move content aside from page/minify caching outside of the public root (kinda like how WHMCS does, well least they have documentation on how to do so and the commands to place into configuration).
But seems like this is yet another reason not to use the default table prefix. Because even if a plugin is exploitable, it's a bit harder if they don't know what to look for.
The author's URL was a bit off, in terms of the google search, there seems to be a good amount of results.
https://www.google.com/search?q=inurl:/wp-content/w3tc/dbcache
By default outside access is allowed, unless there's an htaccess or mod_security rule disallowing it.
Typically as most people keep directory indexes on by default.
Um... duh.
I mentioned both points as obvious as they may be it gives people some ideas what to avoid access to.
And I mentioned it's default because you list it as if it's not a common or default condition.
That's why this is an exploit.
Just because it doesn't have the tweak built in doesn't necessarily call it an exploit, and exploit is well "exploiting" that weakness. Basically you hype it up a bit, and I point out the not-so-seriousness of it if you're not using disk-based caching for the dbcache. If using opcode, this isn't even an issue, and even less so if you deny access to that location to begin with.
Wordpress out of the box is inherently insecure, I wouldn't expect much more of plugins it employs, so the rest of it is on you to prevent the more-or-less common holes.
I bet most of the people who meet with such surprises didn't even change their db prefix let alone the default salt hashes in wp-config.
You minimize it, and make it sound like you have to hop through loops to make this work, citing nginx as part of the reason why it's not such a big deal.
If you select disk based caching, you're in trouble, and your admin password can be cracked from public files due to the architecture of one of the most used WordPress plugins.
I'd call it an exploit. To each their own.
I'm not saying it's not an exploit. I'm just wondering why even when I make a comment initially you seem to attack it as non-related or non-relavant. Particularly when I even mention here in the thread possible ways to avoid the exploit. (you just posted it, you didn't contribute to fixing it).
Thread un-derail: GO GO GO GO !!
Thanks for the information!
Maybe you didn't see that.
Your replies are often very long with little information. You mentioned it's not a big fact because of nginx and mentioned how to fix (in nginx). I gave a quick mod security filter, covers Apache.
Besides getting your signature / URL spammed up as much as possible, or just to de-rail the thread.. I don't see the reason of half of your responses.
All you're doing is downplaying when I mentioned an exploit.
For someone who said "Duh" - How about disabling the plugin? It's a caching plugin. I also mentioned a Mod Security rule to stop the exploit.
Some people may need/want the cache, if it's only that then avoid the path of exploitation.
Far as SecFilter, makes sense if you're familiar to ModSecurity, otherwise it doesn't make sense (and what exactly does secfilter do for it? just the generic setup of what may be considered harmful).
I am not downplaying, I only mentioned a few simple fixes from my side of the lake so to speak.
facepalm and now you're on the attack, against other speculations, if you don't understand half of what I said that not my problem (I suspect mostly a language barrier issue if that's the case).
Russian in my signature doesn't mean I'm not english. Your posts are often long (worthless) without much information.
I understand what you said, my logic is why you're still trying to de-rail my thread with an argument.
To warn people using it, you idiot.
It's a unique rule that will block the attack. You probably don't understand with your nginx background.
Some will know & use the rule, others might simply disable the plugin.
Some will say it's not an issue because not everyone uses Apache.
Thank you. I've never had to defend giving a heads up / mod_security rule for an exploit.
I got that much, but why attack my solutions?
I mentioned 2 points that makes the exploit possible, you mentioned two responses that were somewhat pointless (ie: mentioning google results... which would not have happened if directory listings were disabled to begin with, and the fact that inbound access is allowed by default... which is already known).
You were preaching to the choir until a point.
And then when I even mentioned how w3tc could be made better, you just HAD to follow up with a last word about how you called it an exploit (what does that even have to do with my suggestion?)
Anyways I'm out of this thread, you're too quick to attack/analyze a response that's not a simple "thanks" or "omg this is gona suck'.
At no time was I attacking your "heads up" only your response to my responses.
maybe we shuld use APC, xCache, varnish and then remove w3 total cache.
besides, these PHP cachers are not limited to wordpress
Anyway, Wordpress has plenty of exploits ever since its making, you just have to try hard enough to find it.
But yea, I'm still using Wordpress unless anyone could suggest a safer and better alternative.
That's the obvious problem, shown in the video. The exploit is that content such as dbcache files are in the public root, within the wp-content folder.
That's not something that would make w3tc better, it's sort of crucial / necessary at this point, as this exploit has to do with public dbcache files being stored within wp-content.
It has everything to do with your suggestion.
Thanks for the warning!
As an alternative you could try GetSimple CMS!
Thanks for the warning. Will fix.
Somebody notify @joepie91 but in his own words, if his website is hacked through a Wordpress third party plugin it's not an "elite hack" even though the index page is overwritten.
You could use minimal Wordpress plugins. Someone look up how many remote code execution holes that came from a default Wordpress install and I'll say you have a point but 99% of the Wordpress security issues come from noob plugin developers and website owners who have 20 plugins plus cannot understand UPDATE NOW
That's because Only Noobs Use WordPress™