I am running a Joombah site (not listed as a vulnerable extension: http://docs.joomla.org/Vulnerable_Extensions_List) that was recently hacked. The hacker registered as a job seeker, then proceeded to upload files using the resumé upload feature. In my case the hacker uploaded a PHP script, using a JPG extension for the script, that he was then able to exploit using the PHP interpreter. My host has informed me that this is possible using other file extensions as well (.doc, .docx, etc), depending on how rewrite is implemented in htaccess (the htaccess file that was in place at time of attack is attached).

Edit: The hacker did upload a php script with a JPG extension, but that is not the complete story of how he did the hack. For security reasons, I am not going to post more about the actual exploit.

It appears that the hacker was then able to upload a separate PHP script that he used to send out spam.

I was running Joombah 1.3.3 and, admittedly, Joomla 2.5.4 (which I have since updated to 2.5.8). I have PM'd the Admin of the Joombah forums (approx 15 hours ago) and posted on their forums but still have not received a response.

looking at your fpa results (please repost with extensions viewable) i was concerned over the use of the 775 folders - why?the extension is two versions behind, assuming you are using the proper un nulled version.the dev may need to include a htaccess similar to checklist 7 that prevents scripts running in folders

mandville - thank you for the reply. I really appreciate the help. I've created a new directory to work on an upgrade of this extension and I have run an FPA on the latest release. I will post that in the next response.Here's an FPA without restrictions (only my domain changed).

Update regarding Joombah Version: 1.3.5 RC (and v 1.3.3)No MIME Type check seems to be occurring. I was able to upload a PHP script with both a .doc & .jpg file extension without any difficulty using the Joombah Resumé upload feature.

Zaki here from JoomBah.com, may I get some more information how vulnerability is occuring. Any files that are uploaded are not runnable so if you can forward us any information on this I would greatly appreciate it.

Zaki-I just emailed you a link with additional information (the initial email notification from my host and the chat log for the support ticket that I opened after I was notified of the hack). Perhaps this will help.

Mandville: please let me know if you would like this information sent to you as well.

I can upload the jpg and doc file. But how is it that you were able to upload the php file. The upload feature in joombah jobs only allows certain extensions that are configured from the backend and this only happens if you allow the php file extension.

The extension of the file is .jpg, so the script couldn't be executed as a PHP file. However, with the right rewrite rules in the .htaccess file, .jpg files can be handled by the PHP interpreter, so having such a file in your account is not recommended.

Note: I use the stock Joomla .htaccess file and the recommended PHP settings.

I could be wrong, but it would appear that this is why the Joomla Media Manager checks MIME Types with mime_magic or fileinfo. From the Joomla Docs on Global Configuration and the Media Manager: http://docs.joomla.org/Global_configuration

Restrict Uploads. If set to “Yes” (the default and recommended setting) Joomla will restrict uploads to image file formats only. This restriction applies only to uploads by users with permission levels below Manager. The restriction only applies if the web server does not have installed either of the PHP modules Fileinfo or mime_magic. These modules are used to detect the type of a file independently of its name extension. They are used in Joomla – if available – to enhance site security by confirming that any uploads are not a file format that could be used for malicious purposes.

So even your host has recommended that you not use this rewrite rules that is able to handle jpg as if its a php file. JoomBah Jobs has no such file or .htaccess that can do this.

Again let us mentioned back that JoomBah Jobs has the upload feature that only allows certain extensions that are configured from the backend and the php file could only be uploaded if you allow the php file extension.

First: Understand that I am not a security expert, nor am I a programmer.

Second, regarding this:

So even your host has recommended that you not use this rewrite rules that is able to handle jpg as if its a php file.

As previously mentioned, I am not implementing anything other than the standard joomla .htaccess file and the suggested Joomla server configurations.

At this point, it seems pointless for us to keep going on about this. I cannot with authority say that Joombah is or is not secure. You seem upset, rightfully so, and you seem to want to blame me for this. Again, that is understandable. Please note, however, that I have posted my FPAs & htaccess file above for everyone to scrutinize. Given this, unless you need me to provide additional information I won't be responding to these tit-for-tat postings. I'll let you sort this out with mandville.

mandville wrote:Please screenshot your media upload settings page .Did you say that a file.php.doc was uploaded and run? What were the full file names of the malicious uploads

What Zaki (Joombah) has posted is the same as my configuration, except that since the hack I have removed the ability to upload image files from the Job Seeker Resume/CV configuration. Prior to this hack I saw no reason to change these settings, let alone to allow PHP scripts to be uploaded.

Regarding the uploads, I should clarify something: My host did delete 2 files from my site that were found in the Joombah Resume/CV upload folder.../home/WEBSITE/www/www/jobs/images/jbjobs/pf/wp mail.php/home/WEBSITE/www/www/jobs/images/jbjobs/pf/p_259_1351908403.php

While reviewing my site (after the hack) I found an additional PHP file, masquerading as an image file:/home/WEBSITE/www/www/jobs/images/jbjobs/pf/p_259_1351908388.jpg

mandville,About 9 hours ago I sent Zaki a link to download the initial notification from my host and the subsequent tech support chat, that may have more information that you would be interested in. I can also send you a link for the fake image file. Please let me know if you would like me to PM you this information.

Matt

Last edited by robertsm on Mon Nov 19, 2012 12:18 am, edited 1 time in total.

Question: globally speaking, if the Media Manager blocks PHP scripts that are disguised as image files (such as by changing the file extension), wouldn't it be best practice for 3rd party extensions to do the same the same MIME Type check?

Whilst the fake image file was found on your server and in the location of a joombah jobs directory I am still unable to repeat your findings. Uploading a php file onto the resume upload section is not possible nor will it be run if the extension is renamed to an allowed extension. The link to the fake image, will only be downloaded by a user (in this case the employer) or if someone knows the link. The image produced will be a broken link for Chrome and Mozilla. For Internet Explorer we have found that it shows the php text file but does not run it.

To our disadvantage I cannot prove that your joombah jobs upload configuration was not modified beforehand to allow php due to whatever reason that may have cause to allow someone access to your joomla admin site.

Thank you for your detailed report and for your host report, but unless we can repeat this or at least be shown how the upload (php file) was able to be uploaded with the joombah jobs upload configuration allowable list which does not include a php extension, we cannot deemed this to be a bug.

To be clear, a php file cannot be uploaded due to the allowed settings as per shown in the attachment. Nor can a fake image or document file can be made runnable on the server (it will only be downloadable).

That's good! It's tough with Joomla, extensions, etc. too many wheels in motion...there's only so much you can do with a server so it's up to developers to address security issues and stay ahead of the curve.

I do believe there's security extensions in Joomla aimed at providing some added layers of protection which is nice. I also do all I can on our end to screen out as much as possible to at least limit threats to humans. But again, bad php code the humans will get right in there!

I understand locking the topic during investigation and to prevent unnecessary comments being posted during this time, but I feel the following issue has been ignored in the topic to this point and it is important enough to warrant an additional posting at this time.

An issue in this topic that I think has been ignored is the issue of the file permissions.

I have not seen where the OP has addressed the insecure 775 file permissions on the site(s). The existing permissions are practicality wide open to hackers. This may have been a side effect result (the hacker changed the permissions) of the reported insecurity that is being investigated. I suspect the permissions may have been set this way for some time. Regardless of how the permissions got this way, the permissions issue needs to be addressed properly or you will continue to have issues with the site. Incorrect file permissions may also skew any "tests" performed on the site providing incorrect results.

Giving execute permission to other is just about as good as being wide open (777) as it allows for execution of scripts placed within directories such as the one discussed.

Giving full (777) permissions to Group is just as bad if not worse.

Here is the number system in unix

r w x 4 2 1

This is what the OP site has for file permissions

775 = rwx rwx r-xOwner has Read, Write and ExecuteGroup has Read, Write and ExecuteOther has Read and Execute only

The permissions on files should be:

644 = rw- r-- r--Owner has Read and WriteGroup has Read onlyOther has Read only

Permissions on directories should be:

755 = rwx r-x r-xOwner has Read, Write and ExecuteGroup has Read and Execute onlyOther has Read and Execute only

I of course would also recommend to the OP that the site be cleaned and repaired properly following the documentation posted here: viewtopic.php?f=621&t=582854

PhilD -- Unrequested PM's and/or emails may not get a response.Security Moderator

PhilD wrote:An issue in this topic that I think has been ignored is the issue of the file permissions.

I have not seen where the OP has addressed the insecure 775 file permissions on the site(s). The existing permissions are practicality wide open to hackers. This may have been a side effect result (the hacker changed the permissions) of the reported insecurity that is being investigated. I suspect the permissions may have been set this way for some time. Regardless of how the permissions got this way, the permissions issue needs to be addressed properly or you will continue to have issues with the site. Incorrect file permissions may also skew any "tests" performed on the site providing incorrect results.

PhilD wrote:I of course would also recommend to the OP that the site be cleaned and repaired properly following the documentation posted here: viewtopic.php?f=621&t=582854

PhilD,Thank you for this. Yes, this is an issue that needs to be addressed. When it first came up I thought it might be a Joombah installation issue, but I just installed a test/clean install of Joomla 2.5.8 with current release of Joombah. I then ran the FPA on this test install and I received no report of any elevated permissions. It would be exceedingly stupid of me to have set those permissions manually (there would be no reason to and I assure you I did not), so I'm left to assume that it is left over from the hacker.

Regarding the Security Checklist: I have gone over them, but obviously not addressed the file permissions. I did not change those items prior to running the FPA because I wanted to show as close as possible what the system environment was at the time of the hack (with the exception that I did upgrade Joomla ASAP after the event). Post-event I have also been working with my hosting tech support (ICDSoft) and they have been wonderful at assisting with the scanning & clean up.

Mea Culpa for the above. Those were my issues and not the developers.

Now to the meat & potatoes of the issue: Approximately 35 hours ago (9:30PM CST on Nov 16, 2012) the dev & I exchanged emails regarding this issue, on which vel@joomla.org was CC'd. Have you seen or reviewed those emails? They are relevant to this issue.

I do disagree completely indeed so good you retracted the Joombah finger pointing. Class!. We have multiple sites with Joombah on our owned servers and that extension has not been hacked. (I have send this morning a PMB to Mandville btw related to another huge attack on all Joomla sites).

This described particular hack attempt we see on hourly basis to all servers and it is a very well known exploit (php.hide). We have mechanism in place that intercepts these attempts and quarantines these exploits before they even reach the server.

Simple fact is that if you have the frontdoor wide open and you go out for shopping do not be amazed that the house is empty upon return. Still though with a good hosting setup even with 755-permissions it would not have reached the server if your host would have proper security in place. Phil is 100% right here btw.