Possible Vulnerability

[masodo]

I am currently running 2 instances of Geeklog CMS 2.2.2 in a php 8.2.28 environment.

I have been debugging along the way due to several incompatibilities and have been having great success running these websites.

Today I noticed that both of these websites were hacked with identical attacks that created a ".html" file in the sites' root folders.

The pages themselves are pretty innocuous but do represent do be an "0wn3d" situation. I am running several other NON-Geeklog sites on the same server which are not victims, so I feel confident in saying that something in Geeklog might be facilitating the hack.

Not sure if this is the place to begin digging-in to the trouble. but am wondering if anyone has any idea what might be the root of the problem?

I have read about possible trouble in admin/trackback.php and am not happy with permissions for the GUS plugin so am starting my investigations there. Is anyone else running Geeklog and getting hit with this likely "Transversal" hack/attack?

[hostellerie]

I wanted to come back to this issue, as it has remained without a response for about a year.

This report actually encouraged me to take a closer look at the current Geeklog 2.2.2 codebase and search for possible areas that could facilitate this kind of compromise.

I have not found evidence that identifies the exact cause of the attacks described here, so I do not want to imply that the following component was responsible.

However, during this review I became particularly concerned about the legacy file management stack included with Geeklog, especially the amount of third-party and older file upload/file management code that is exposed within public_html/filemanager/.

That investigation led me to look more closely at RichFileManager and its dependencies, and eventually to consider whether Geeklog would be better served by having a small native Media Library instead of continuing to depend on this legacy stack.

I have now opened a draft PR implementing this approach:

#1173

The proposal replaces the legacy file manager with a Geeklog-native Media Library and centralizes the sensitive operations involved in file management, including:

• Geeklog authentication and permissions
• CSRF protection
• path validation
• MIME and extension validation
• upload validation
• filesystem operations
• restrictions on accessible directories

It also removes the exposed legacy PHP connector and Blueimp demo backend from the current file manager stack.

Again, I am not saying that the existing file manager caused the compromise reported in this issue. Without server logs, uploaded files, request traces or another reproducible attack path, that conclusion would not be justified.

But this issue was the reason I started reviewing these parts of Geeklog more closely, and I think reducing the amount of legacy file-management code exposed to the web is worthwhile from a security and maintainability perspective regardless of whether it turns out to be related to this specific incident.

If @masodo still has any logs, timestamps, filenames, request records or other information from the original attacks, they could also be useful for comparing them with the areas currently being reviewed.

[masodo]

Thanks for the consideration @hostellerie - I have always been a bit leery about the included file manager and in fact have never required the use of it in the way I manage my blogs.

After the abatement of a rather persistent hack on my Geeklog sites that that included the creation of a .jpg file that was in fact obfuscated code and the creation of nested same name folders and overwriting .htaccess, robots.txt. and index.php I recall the logs showed excessive hits on the /public_html/trackback.php file, I decided to see how that script might be hardened. I gave the file to Claude.AI for evaluation and was provided with a presumably safer alternative. [https://github.com/masodo/geeklog/blob/master/public_html/trackback.php] I have not suffered any breaches of security since replacing that file, so hopefully that was the vector (although I cannot fathom how that was so.)

I did a review of my activities from back then to see if I could come up with specific logs and/or other information on the attack and can tell my focus turned out to be on the trackback.php file but don't find anything useful for those dates.

I second the motion that reducing legacy file management code in favor of a more manageable alternative only makes sense. Your proposal addresses a number of issues relevant to today's security foci.

[hostellerie]

Thanks for the additional details. This is very useful context.

The fact that you saw excessive requests to /public_html/trackback.php during the attacks, and that the compromises stopped after replacing that file, definitely makes the public Trackback endpoint worth a closer review.

One thing I noticed while comparing your replacement file with the current Geeklog code is that the replacement appears to be based more closely on the administrative admin/trackback.php code rather than the public Trackback receiver.

The public trackback.php normally accepts anonymous Trackback POST requests and eventually calls TRB_handleTrackbackPing(). Your replacement, on the other hand, includes auth.inc.php and requires story.ping permissions.

So it is possible that replacing the file effectively disabled or restricted the public Trackback endpoint rather than fixing one specific vulnerability in it.

That does not make your observation less important. In fact, it gives us a useful direction to investigate.

I think it would be worth reviewing separately:

• public_html/trackback.php
• TRB_handleTrackbackPing() and the functions it calls
• PLG_handlePingComment() callbacks
• any remote URL processing involved in Trackbacks/Pingbacks
• whether Trackbacks should still be enabled by default in a modern Geeklog installation

At this point I still would not say that Trackbacks were definitely the original attack vector, since we do not have the original logs or a reproducible exploit path. The high request volume could also have been automated scanning or another part of the attack.

However, your experience is enough that I think this deserves a focused security review.

I would prefer to keep that work separate from #1173 so that the Media Library PR remains focused on replacing the legacy file manager.

Thanks again for going back through your old notes and for sharing the replacement file. It gives us a much better lead than we had before.