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

[Otto]

Mmmmm... I think I didn't get my point across well here...

Knowing whether the plugin exists on the site or not is irrelevant
unless the pluign has a security hole. They're not going to "scan" for
plugins that don't have known exploitable holes. So we can discount
all plugins that do basic stuff like defining functions and using
hooks. This is 80-90% of all plugins. Whether you know they are there
or not, if they're not exploitable, it makes absolutely zero
difference if the attacker knows of it.

So, if a plugin does have a directly exploitable hole, then it must
execute code when called directly. Just defining functions and adding
hooks cannot be exploited directly.

Now, if the plugin executes actual code when called directly, then it's either:
a) Incredibly poorly written, or
b) Designed specifically to do exactly that.

Example of B: A plugin adds an "img src" link that points to itself
into the body of a post. Then when called directly, it returns a
binary image file to display on the webpage. Handy way of getting the
plugin and associated images all into one file for ease of
installation, perhaps. I've used this trick before myself.

Anyway, so you suggested checking to be sure it's not being called
directly and quitting if it is...
-For case A, this is fine, but it may not actually solve the bug if
the plugin is that poorly written, because the same code is still
executed at the plugin include time and there's quite likely an
exploitable vector there.
-For case B, your method simply breaks the operation of the plugin entirely.

So what I'm saying here is that this idea, while sound, falls apart in
actual use. It doesn't add anything except somewhat useless overhead.
Okay, so somebody can't find out what plugins you use. Big deal, if
your plugins are not exploitable, then it doesn't matter, and if they
are exploitable, it's unlikely that this will fix them. A hidden bit
of exploitable code can still be exploited by simply spamming the
exploit on every WordPress site you find. They don't *need* to scan
for holes in the code, they just have to attempt to use them. Scanning
for what plugins you have is *useless* to a site hacker.

-Otto



On 8/21/07, Sam Bauers <sam at viveka.net.au> wrote:
> You are absolutely right that using a properly made plugin is the
> best security technique. But the point of the method I wrote up was
> to hide the files existence to stop it from being detected by some
> sort of scanning technique. Returning a 404 is the way to do this,
> the good plugin coding practices you mention will secure any direct
> exploit (if one might exist) from calling the file directly, but it
> will still return an HTTP status of 200, so if I'm an attacker, I
> know it is there. This *may* be helpful down the track, when a
> seemingly well written and secure plugin becomes insecure for some
> reason. So appending that conditional to the start of a plugin will
> help in that it will slow down an attackers detection of available
> exploits. It is also a lot easier than auditing the code in every
> plugin you install.
>
> Sam
>
> On 22/08/2007, at 4:23 AM, Otto wrote:
>
> > So the utility of a method like yours (check for ABSPATH) is limited
> > in scope, since a properly made plugin would never need such a check
> > in the first place. It's generally a fine way to partially secure a
> > plugin after the fact, by the end user though.
>
> --------------------------------------------------------------
>   Sam Bauers
>
>   sam at viveka.net.au
> --------------------------------------------------------------
>
>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>