User Functions


There are no upcoming events

What's New

Stories last 2 weeks

No new stories

Comments last 2 weeks

No new comments

Trackbacks last 2 weeks

No new trackback comments

Links last 2 weeks

No recent new links

Downloads last 2 weeks

No new files

Welcome to Geeklog Friday, October 28 2016 @ 08:01 am EDT

So-called Geeklog "exploit" posted

  • Contributed by:
  • Views:

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.


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
RewriteRule .* - [L,F]

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


Trackback URL for this entry:

The following comments are owned by whomever posted them. This site is not responsible for what they say.

  • So-called Geeklog "exploit" posted
  • Authored by:andyofne on Friday, June 30 2006 @ 12:34 am EDT
Okay, well, it's not a so-called Geeklog exploit. I was hit with it today.

Unfortunately, my host doesn't allow me to create directories outside of the htdocs directory. I didn't think to protect the directories surrounding geeklog.

Fortunately, my database was not touched but I have no doubt that my passwords have been compromised as, according to my web server logs, ever file on the website was accessed and searched for passwords.

My index.php file was replaced with one of those ubiquitous 'you've been hacked' pages.

A file was placed on the system that searches for passwords and when I downloaded it Symantec A/V got pissed and tagged it as a trojan.

Only a few files were edited / created and the person wasn't sophisticated enough to destroy the logs so I'm assuming it was a 'script kiddie" though his 'hacked by' page warned me not to under estimate his skillz.

  • So-called Geeklog "exploit" posted
  • Authored by:kingsley on Friday, June 30 2006 @ 10:09 am EDT
Just wondering about your host. Do they allow you to map your domain to a subdirectory of your root htdocs folder? If they do you could move the domain and you files to a subdirectory and put the other Geeklog files in an unreachable subdirectory in the root.

Of course if you host doesn't let you map you domain this is all moot anyway.
  • So-called Geeklog "exploit" posted
  • Authored by:socalledsoftware on Saturday, July 01 2006 @ 05:55 am EDT
You know, the fact that this is being downplayed as a "so-called" exploit really shows your ego and arrogance. If it's a "so-called" exploit, why was it "fixed"? It's anything but "so-called", exploits do in fact exist for numerous php files (the ones I'm referring to are the SpamX plugin related vulnerable php files. The ones that are easily exploitable).

Now, I hear you saying you are relying on the user to follow through with the guidelines in the documentation for where to place the files (outside of their webroot). If a user were to follow these instructions, then gee ok garsh you win, it's not exploitable, because the files can't be accessed remotely. However, as a software developer, it is frightening to know that your stance is that vulnerable code isn't a threat, because 100% of the time 100% of the users will follow 100% of the documentation.

Don't be fooled by a "so-called" exploit, it is quite real, and is actively being used to compromise servers. The only thing "so-called" here is the quality of any PHP scripts that have remote include vulnerabilities such as the ones contained in the numerous files that are part of the SpamX plugin. What year is this? 2006? And people are STILL making this stupid coding mistake? And on top of that trying to downplay the threat? Suck it up - the code sucked, the QAing of the code (if any even took place) sucked, and the labeling of a vulnerability that uses such an old class of bugs as anything other than critical sucks.

It's disheartening to see such arrogance, and even moreso to think that people are going to be getting owned because Geeklog said it was only a "so-called" exploit. Vulnerable code is vulnerable code, period. You make it sound as if it would be perfectly acceptable for vulnerable code to be put into use as long as it's not remotely accessible. You are not thinking like a user, just a crappy software developer whos pride just took a fat punch in the nose. Get over it, it happens.
  • So-called Geeklog "exploit" posted
  • Authored by:casper on Saturday, July 01 2006 @ 06:48 am EDT
If a user dont install even proper code the way it was intended to be used, even this could be "potentialy" dangerous.
If the user socalledsoftware had NOT been a script-kiddie (you can se it by the arrogant way he expresses himself), but a software developer as he claims he had known what "outside webroot" means. Thats where that script are supposed to be placed. And am I the only one who have noticed all warnings about unsecure site if all dirs are placed within the webroot? I dont think so..
Please dont mention "novice users", if you dont know what you are doing, even drinking a glass of cold milk will kill you.

LAMP? Mine is -> WIMP
  • So-called Geeklog "exploit" posted
  • Authored by:Dirk on Saturday, July 01 2006 @ 03:30 pm EDT

It certainly was sloppy QA, considering that we already had these checks in some other places. But then again, they are only there to somehow protect those from themselves that didn't follow the installation instructions.

I still refuse to call it an exploit, though. It's an "exploit" in pretty much the same way that it's an "exploit" when your PC is hacked because you didn't activate your firewall.

bye, Dirk

  • So-called Geeklog "exploit" posted
  • Authored by:andyofne on Sunday, July 02 2006 @ 02:36 am EDT
I have to admit that, at least in my case, I did not follow the instructions from day one and every time I re-installed or updated GL I did it wrong. I choose to modify the way I did the install and I paid the price for not following the directions. Quoted below is the part I ignored. I put the files in the web root and did not protect them.

[b]Basically, a Geeklog installation consists of two parts: The part that is visible "to the world" - which is everything in the public_html directory. "public_html" is a popular name for the world-accessible directory that can be found on a webserver ("htdocs" and "www" are other popular names). So if you have such a directory, just copy everything from Geeklog's public_html directory into that directory on your webserver. Then you only need to set up $_CONF['path_html'] (in config.php) to point to that directory.[/b]
  • So-called Geeklog "exploit" posted
  • Authored by:AA6QN on Sunday, October 21 2007 @ 09:04 am EDT
I would like a sanity check here. First off nothing is in my public access root that should not be. Second I have employed directory authentication to area's in my public access root where I want to restrict access using AllowOverride AuthConfig in the httpd.conf file.

In my httpd.conf file I have added:

<Directory "/">
Options -All +FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all

<Directory "/my/web/root/htdocs">
Options -All +FollowSymLinks +ExecCGI
AllowOverride Options FileInfo AuthConfig Limit
Order allow,deny
Allow from all

AccessFileName .htaccess
<FilesMatch "^\.ht">
Order allow,deny
Deny from all

The .htaccess in my public access root directory is:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^Morfeus
RewriteRule ^.*$ - [F]

Redirect 403 /plugins

RewriteEngine On
RewriteRule .* - [L,F]

Since AllowOverride defaults to ALL, I did not add it to the httpd.conf. I hope that is correct? I hope my .htaccess file is correct. I did get a Morfeus scan once upon a time and this is what was recommended.

So, am I hopefully close with the configurations?
Thank you in advance, JohnF
  • So-called Geeklog "exploit" posted
  • Authored by:Dirk on Sunday, October 21 2007 @ 04:22 pm EDT

Well, if you don't have anything in your webroot that shouldn't be there, then you won't have this problem anyway. The above issue mostly affects sites that used installers like Fantastico (and, in retrospect, I had no idea how widespread its usage was when I wrote the that article).

bye, Dirk

  • So-called Geeklog "exploit" posted
  • Authored by:AA6QN on Monday, October 22 2007 @ 07:44 am EDT
Thank you, Just for grins, my logwatch reports daily attempts:

Requests with error response codes
403 Forbidden
//plugins/spamx/ ... 2 Time(s)
/forum//plugins/spamx/ ... 2 Time(s)
/plugins/links/[path]=h ... 1 Time(s)
/plugins/spamx/DeleteComment.Action.class. ... 00/cmdhtml.txt?: 2 Time(s)
/plugins/spamx/MassDelete.Admin.class.php? ... 1 Time(s)

The offending IP will end up in a ipblock statement on a firewall. No Snort signatures for this yet. I am glad you did write the article as it gave deffinintion as to what was going on.
Thank you once again, JohnF