So-called Geeklog "exploit" posted

In case you've been wondering about the increased amount of people trying to access a 'plugins' directory on your Geeklog site: Someone has posted a so-called "exploit" for Geeklog and all the script kiddies are now rushing to try it out without really understanding what it does and most importantly why it doesn't work on most of the Geeklog sites out there anyway.

So what is all this about? As is being pointed out in the installation instructions, everything that resides outside of Geeklog's 'public_html' directory should not be accessible via a URL. In other words, those files and directories should reside outside of your webroot. This applies to the config.php file, the 'plugins' directory, and everything else that resides there. The so-called "exploit" can only do harm on sites that have those inside the webroot, so that they can be accessed via a URL. And even then those that installed Geeklog that way but password-protected those directories (as explained in the FAQ) are also save.

Background

What the "exploit" does is demonstrating how to include files from a remote location so that they are executed on your Geeklog site (for which it uses files located in the 'plugins' directory). Obviously, this is not a good thing. We've actually already identified and fixed those issues (in CVS) a while ago during our ongoing security and code review for the next Geeklog release.

Fixing your installation

So what can you do when your site is installed such that it would be vulnerable? The obvious solution would be to password-protect all the sensitive directories (all the directories that reside outside of 'public_html'), as explained in the FAQ (see above).

If you can't use password protection, then now would be a good time to fix your installation. Either re-install Geeklog properly or, at the very least, move those directories outside of your webroot. As explained in the installation instructions, you can separate the public and the non-public portions of Geeklog and have them in two independent locations (that only requires a few adjustments to the path settings in the config files).

Tips and Tricks

Depending on how hard your site is being hit with those fruitless attempts, it may make sense to add a few rules to your .htaccess file to block them and ease the server's load somewhat:

Redirect 403 /plugins

Even if you don't have a 'plugins' directory in your webroot, any request to it will cause a 404 error and if you're using Geeklog's 404.php, that would even create a session for the attacker and put load on the database server. So giving them a 403 ("Access denied") message would create less load.

Since we're dealing with people who don't know what they're doing, you may even see completely non-sensical requests like for '/index.php/plugins' and things like that - add .htaccess rules for those as necessary. And if you don't care about people who may try to search your site for "_CONF", you could also block all requests that contain that string:

RewriteEngine On
RewriteCond %{QUERY_STRING} _CONF
RewriteRule .* - [L,F]

We will probably be seeing these sorts of requests for a long time ...