• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

Site hacked by post to com_fabrik/helpers/string.php

remico

Member
We had a hacked site used by spammers and after studying the Apache logs we did see a post to com_fabrik/helpers/string.php. Sadly I can not seed contents of the post, only that someone posted directly tot the file.

Seconds after this post a file (/plugins/fabrik_form/salesforce/files.php) was created and called (GET)!

Using Fabrik 3.1 on a 3.3.3 Joomla
 
There was a missing define or die in string.php that I added in commit 7e78214760ff5246675ec553e6117373dd869adb in August 2013. This commit was a general update to add these where they were missing, and was not because this security hole had been identified.

So I guess this is the first report that there is this security hole in an older version than the current, but since this has already been fixed for more than a year, I guess there is not much more that Rob / Hugh can do except inform people and recommend that they keep up to date with a later version of Fabrik.
 
We had a hacked site used by spammers and after studying the Apache logs we did see a post to com_fabrik/helpers/string.php. Sadly I can not seed contents of the post, only that someone posted directly tot the file.

Seconds after this post a file (/plugins/fabrik_form/salesforce/files.php) was created and called (GET)!

Using Fabrik 3.1 on a 3.3.3 Joomla

As Sophist said, this was fixed about over a year ago. Also, if the web server was able to create a file on your system, your file permissions need fixing. Having your file system wide open for write by the web server process is a big security hole.

Thanks for the report though, we will send another one of our periodic reminders to keep up to date.

-- hugh
 
Sorry for my late reaction, but this site was running on a github version not older than 3 months. I removed Fabrik from this site because it was not used.

Not quite agreeing to the security statement though :) All the folders have 755 permission (files 644) setting and I think that is that is the default for a standard J install. Normally files/scripts should not be able to create files by posts from the big bad world...
 
Actually, as far as I can tell, the string helper has always had the _JEXEC or die in it, Sophist's commit just added a die() message.

https://github.com/Fabrik/fabrik/commit/7e78214760ff5246675ec553e6117373dd869adb

So I don't think any attempt to access that file directly would ever have worked. Here's the original commit when we forked 3.x and moved it from the Unfuddle SVN repo in 2011:

https://github.com/Fabrik/fabrik/bl...a42e/components/com_fabrik/helpers/string.php

PHP:
Not quite agreeing to the security statement though :) All the folders have 755 permission (files 644) setting and I think that is that is the default for a standard J install. Normally files/scripts should not be able to create files by posts from the big bad world...

But are the folders owned by the httpd user? I know it's not as convenient, but the only secure way to run J! is to make sure nothing except the absolutely necessary folders (like cache) are writeable by the httpd user, and use the ftp layer.

Do you still have the logs?

-- hugh
 
Hi Hugh,

Thanks for your quick reply.

I have many Fabrik sites running and this is the first time I had a hack related to Fabrik3 so no worries. I don't have logs anymore, but the only log I had was the Apache usage log showing a direct POST to the file and later a GET to the created file. And then sending a lot of mail... this is when the server firewall kicked in.

I'm a bit confused though and maybe I'm wrong, but many applications need write access to many different folders. For example gallery tools that need thumbnail generation, Akeeba backup for creating backups, Virtuemart for product images and invoices... if I'm not mistaking even Fabrik is placing uploaded CSV files in the media folder...

Also only making certain folders writable does not solve the problem. The files would then be created in those folders... again the php script should never create a file based on a outside POST only...

I agree it would be best to secure all folders, but this is not really workable for many customers. Using reliable and secure components within J should be better and enough I think.

Our Apache server is using mod_ruid2 and we have very little security issues. The only issues we have are with crapy coded components within J! but other then that we have no real problems at all...

I'm a huge Fabrik fan and using it for many years (from version 1...) and again this is the first time it happened so no biggie. I'll keep an close eye on the Apache logs on some other sites and if there is something interesting to tell I'll get back to this thread with more details.
 
I have a carefully researched .htaccess file which (amongst a lot of other security things) stops any calls to php files other than index.php and /administrator/index.php. I also run two extensions - one a straight-forward IP blocker for front- and back-end to which I add spammers and anyone attempting to hack, the other a black-list based blocker which I use only on the back-end.

Happy to share my .htaccess file.
 
Also, I can't see any code in /components/com_fabrik/helpers/string.php which would actually do anything with a post to create a /plugins/fabrik_form/salesforce/files.php file.

Are you sure that the files.php file was not created by an earlier web site call? Does the files.php timestamp correlate?
 
Hi Sophist,

Yes the files.php time-stamp (created) matched the POST time-stamp. I'll keep a close eye on other installations when I see the same POST again on a Fabrik install I'll start monitoring closely and gather as many data as I can.

Would love to take a look at your .access file. Always interested in good and manageable security solutions. Also using Akeeba Admin Tools pro on every site.
 
I'm a bit confused though and maybe I'm wrong, but many applications need write access to many different folders. For example gallery tools that need thumbnail generation, Akeeba backup for creating backups, Virtuemart for product images and invoices... if I'm not mistaking even Fabrik is placing uploaded CSV files in the media folder...

Correct. And the J! JFile and JFolder API's handle all that. They will use either direct access (native PHP file functions) or the ftp layer, seamlessly, depending on your server config. The only issues you will ever run across are with poorly written code that doesn't use JFile / JFolder, with calls like JFile::create(), and instead access the file system directly with native PHP functions like fopen(). And you don't want to be running code like that anyway.

It may be a tad slower, but using the FTP layer, with your J! folder structure owned by a user other than the one the httpd runs as, is way more secure. Pretty much by definition, allowing the httpd to write to the web root is a Bad Thing <tm>, as you found out. Unfortunately, it seems to have become the de facto standard, as it takes a small amount of effort to do it the Right Way <tm>, and some poorly written code will fail.

Obviously using the ftp layer isn't a cure all, as applications can still introduce vulnerabilities by not policing their uploads. Fabrik had a nasty bug a while back, where we weren't always deleting CSV uploads (if the import process failed), and someone found out they could upload a PHP file masquerading as a CSV file, then run it. Of course we fixed that as soon as we were made aware of it a few years ago. But it's still an order of magnitude safer.

-- hugh
 
I still believe that the best starting point is to use .htaccess to allow only pre-defined URLs through i.e. like a firewall best to deny any call which doesn't match an allow rule rather than to allow all calls (possibly except where you have explicitly denied them).

That said, it does mean that you need to tweak the rules e.g. (real life examples I have had to deal with)

a. when you have a user agent which has been banned by accident (e.g. facebook).

b. when an extension inserts links in the HTML (for images, css, js etc.) to new parts of the file system.

Obviously you can also change the permissions, but you are then likely to have similar issues of having to adjust permissions on specific directories. On balance I think the .htaccess route is easier.

I will send my .htaccess to remico privately.
 
Just to give a current example, I just happened to be looking at my server logs for this morning and between 06:07:53 and 07:28:47 GMT I had one IP address make 13,160 hacking attempts. To put this in perspective, that is 13,160 calls in 80 minutes out of 14,173 total log lines between 22:00 last night and 14:06 this afternoon.

Most of these were attack strings that my htaccess file handled, giving them a 403 response and not even getting as far as running Joomla code - and that number of attempts would have brought my server to its knees if it got as far as running php code.
 
hmm - I just looked up the IP address and it was a web-security checker that I subscribe to doing its weekly security check. LOL

However, the principle is the same.
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top