In Japan, a XOOPS site in sourceforge has been cracked by weakness of Agenda-X.
This was also taken up in the "slash dot news".

wjue knows Agenda-X 1.2.1 has a security hole, and he released 1.2.2.
But I've just found the fixes are no use.
Thus there is still a serious security hole in XOOPS sites using Agenda-X 1.2.2 or 2.0.0 beta2.

Deacivate and remove all of Agenda-X files from your XOOPS site now.
Only deactivating module has non-sense, because the security hole caused by files.

REMOVE THEM RIGHT NOW.


This is a summary of XOOPS Japan's news posted by onokazu
----------------------------------------------------
From XOOPS Japan Team

The weakness to be able to execute an arbitrary external file by "Agenda-X" module was discovered.

This bug : to the distribution package of the main body of XOOPS and XOOPS because it is not included module weak. It is not necessary to correspond especially on the site not included in following "Site where the action is necessary".

There are roughly separately two reasons taken up as a news story this time.

The first reason was to have done the cracking attack which pierced the weakness of this module on a domestic major site.

The second reason is of my wanting XOOPS users to understand the adoption of the module made by the third party should be ascertained enough.

It is important that there is no weakness of the module included in the main body of XOOPS and the distribution package.
----------------------------------------------------
(sorry for bad auto-translator)

Arrgh! My Agenda-X 1.2 is excluded from the Anonymous and Registered user group. Only trusted site accounts are granted access to it.

Will I still need to deactivate Agenda-x?

God damnit. Agenda-X is a good functioning module but it has too many security holes. What gives? I just upgraded 1.2.1 to 1.2.2 yesterday... grrrr...

Quote:
Deactivating module has non-sense.
Crackers can attack the defective files directly.
You have to REMOVE all of Agenda-X files from your site.

Check the request to the following files from your site log
so that you may find signs of the cracking.

- modules/agendax/addevent.inc.php
- modules/agendax/i18n.php
- modules/agendax/config.inc.php
- modules/agendax/admin/admin_header.php

If the request remains in the log, you may think the some crackings have been done.
Because the HTTP request is not necessary for these files, it doesn't usually remain in the log.

The looseness of the server setting for PHP became the factor of the expansion in this case, too.
Please reconfirm the setting of your site once now.
http://www.php.net/manual/en/features.safe-mode.php
- safe_mode
- safe_mode_include_dir
- safe_mode_exec_dir

Hmmm, I had a few requests for addevent.... grrrr.

Would this help in the emergency??:

.htaccess (in the /modules/agendax directory)


Order Deny,Allow
Deny from all



Order Deny,Allow
Deny from all



Order Deny,Allow
Deny from all



Order Deny,Allow
Deny from all

Some early looks at the logs and sure enough there are crack attempts. Appears at least one used google to find servers to attack. They check OS versions and do things like create, delete, upload root kits.

I've found one server being used to wget root kits. I got right in and can see all the tools being used.

So far it seems they didn't get in.
but
This is not good....

Quote:

This is my favorite response lol. I too am about to dump it from one of my sites.

This explains why the author's own site has been down for a few days.

I think I had enough security behind XOOPS to thwarte the kiddies. The security at the kiddie's sites is far worse. I could browse one site and see all his tools, test code, irc logs, porn, etc, even the guy's picture and id. A freakin pgp key for fsck sakes. But I won't touch anything or retaliate. Just lock my doors.

I added some traps to disallow improper urls in agenda-x. register_globals has been off all along. I have a similar rule for mainfile.php and had one attempt to download it.

So caution to all and not just agenda-x. Evil lurks is funny places.

I don't want to loose my data (sigh I can't think of re-entering all the calendar entries again!).

Would it be sufficient for me to cmod the Agenda-X directory to 400 Owner Read-Only

As a backup precaution I've also renamed the module's folder name to something else.

But the agenda-X template and calendar data are still on mySQL.

I don't want to have to re-do all my calendar entries again.

Can someone please confirm my steps is sufficient to patch the security hole for now?