[wp-hackers] protecting wp-content/plugins ?

Otto otto at ottodestruct.com
Wed Aug 29 16:32:56 GMT 2007


On 8/23/07, Tom Barta <tbarta at gmail.com> wrote:
> Sure it does.  If I have a PHP script that is vulnerable when executed
> directly, but then I move it out of the document root, it can no longer be
> executed directly (via HTTP requests) and therefore is no longer a real
> vulnerability (assuming it's secure as a library).

No, it doesn't. Any plugin that you can exploit directly can also be
exploited indirectly as well. Plugins are include'd into WordPress.
They even get globals. Examine wp-settings.php to understand how
plugins work.

> Obviously, you can't take scripts that are meant to be directly executed and
> remove them from the document root like this.  But if what someone in the
> thread said earlier is true (80-90% of plugins are pure library code), that
> means 80-90% of the plugins can be moved outside of the document root,
> thereby reducing the likelihood that a newly-discovered exploit is actually
> usable.

This sort of trickery does prevent you from exploiting it directly,
but not from exploiting it indirectly, through WordPress. So this
*does nothing to help* as far as preventing you from getting exploited
goes. It doesn't fix the exploit. It doesn't prevent the exploit. It
is, in fact, totally useless.

On 8/25/07, Omry Yadan <omry at yadan.net> wrote:
> the main argument against this is:
> attackers don't care, they just run all the existing exploits against
> random sites.
>
> you making the assumption that all attackers are script kiddies.

No, I'm telling you that exploiting a site involves making HTTP
requests. Scanning a site for exploits actually involves making HTTP
requests as well. So, why bother to scan at all? Simply try the
exploit. It's the same amount of overhead, there's no reason to *scan*
for anything.

> what about an real hacker (cracker, whatever)  that wants to screw a
> specific site?
> he will first try existing scripts, and when this fails he will start to
> really learn the site.

True, however knowledge of what plugins somebody is running doesn't
help him unless the plugins are exploitable.

Assume I have a site with an exploitable plugin. Assume I've taken
steps to hide the plugins from direct access like mentioned in this
thread.
a) Plugins often announce themselves by their actions. If you know
WordPress and themes pretty well, you can usually look at the source
to a site and tell several plugins that they are running. Then you can
look for exploits for those.
b) You can look for generic exploits for WordPress and plugins and try them all.

Eventually, one of these two is going to pay off. Finding an unknown
exploit in a plugin *is not trivial*. If the guy is good enough to do
that, he's probably good enough to not bother trying and to instead
try to hack the password or social engineer the hosting services.

Also, assuming you've disabled directory listing, he's going to have
to "scan" for plugins by name to know what plugins you're running, if
they're not obvious. Meaning that he'll have to know the names.
Meaning that he'll look for known vulnerabilities and see if you have
those. What else can he do? Download random plugins, find unknown
vulnerabilities in them, then check to see if you have them? Makes no
sense at all.

What I'm saying is that the having somebody know that you are running
some specific plugin doesn't put you at any sort of extra risk
whatsoever. Disable Directory Indexing to stop search engines from
seeing them, and then get on with life. Going to extreme amounts of
effort by adding PHP code to plugins, like in this thread, is useless.
Worse than useless, because it's false security: You think you're
safer when you're actually not.


More information about the wp-hackers mailing list