1
drbowen
XOOPS security
  • 2007/10/26 0:41

  • drbowen

  • Just popping in

  • Posts: 19

  • Since: 2006/4/28


I am wondering what the exact need for making the permissions on the directories:

cache/
templates_c/
uploads/

so liberal.

I recently had a malicious user insert a redirect statement in

uploads/

that initiated a phishing scam that prompted some angry emails from a very large bank.

I have found other similar phishing scams inserted into all three directories.

What would be a good way to prevent this happening again?

Sam Bowen

2
davidl2
Re: XOOPS security
  • 2007/10/26 0:56

  • davidl2

  • XOOPS is my life!

  • Posts: 4843

  • Since: 2003/5/26


If its: oemr.org

1 - Updating to the latest 2.2.x release may help.

2 - Installing Protector would be a good idea (I think the latest release supports 2.2 still?)

3
damaster
Re: XOOPS security
  • 2007/10/26 1:06

  • damaster

  • Just can't stay away

  • Posts: 556

  • Since: 2003/5/11


Humm...


It seems that Gijoe has stopped to support the core from xoops.org

http://xoops.peak.ne.jp/md/d3forum/index.php?post_id=9755
I like people more than machines or money. But that's me!
Lets do something good and great: Lets do open source!

4
vaughan
Re: XOOPS security
  • 2007/10/26 1:11

  • vaughan

  • Friend of XOOPS

  • Posts: 680

  • Since: 2005/11/26


as alkways nuno, useless info, old news, repeated news & pretty much wrong.

gijoe is still supporting XOOPS the last i heard.

5
jdseymour
Re: XOOPS security

Server security is the issue here, not xoops. As long as the files and folders are owned by the user that runs apache (usually uid/gid apache/apache) the folders do not need to be chmod 777. suexec is even better, because it runs as the actual user of the site (if it where my case uid/gid jdseymour/jdseymour).

Some shared hosts do not set their servers correctly (or loosely) for the sake of compatibility. And leave open room for sites to be compromised.

cache, templates_c and the uploads folders only require permissions for the server to write to them. If you need chmod 777 (or writable by everyone) it is the server setup to blame.

6
skenow
Re: XOOPS security
  • 2007/10/26 2:01

  • skenow

  • Home away from home

  • Posts: 993

  • Since: 2004/11/17


If you are, indeed, stuck with those liberal permissions and you can use .htaccess files on your site, try adding this little directive to your .htaccess file in the root of your site

<Limit POST>
order deny,allow
deny from all
#modify mysite.com to match your site's domain
allow from mysite.com
</Limit>

7
Catzwolf
Re: XOOPS security
  • 2007/10/26 5:12

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


The only real way to prevent this from happening again is to remove the folders involved from some script kiddies.

Somone has already mentioned installing protector, but in all honesty it creates just as many issues than it solves. You could use htaccess and that should suffice.

But the method of renaming the directories that you have mentioned is the only real way to prevent this from happening again. In some cases it would be a preg_replace of dir names etc within the core and some of the modules that you use.

Drastic agreed, but assured.

8
drbowen
Re: XOOPS security
  • 2007/10/26 13:41

  • drbowen

  • Just popping in

  • Posts: 19

  • Since: 2006/4/28


Yes, oemr.org.

I appreciate the input a lot.

I have been examining the files with (hopefully) wiser eyes. The malicious files are owned by the apache web server and have the same owner and group permission as my Apache web server process.

To me this implicates a registered user who is posting this somehow using the XOOPS software, possibly using the newbb or the wiwimod to load the malicious software.

I need to start logging which users are posting if possible. This is likely someone very familiar with the behavior of XOOPS to be able to insert the files in the cache/, templates_c/, and updates/ directories using XOOPS and the Apache webserver.

I am running XOOPS 2.2.3a. I have the following modules installed:

System
Private Messaging
Extended Profiles
Wiwimod
C-Jay Content
News
CBB

The files were in

uploads/ Chase Bank scam

cache/ Paypal scam

These were javascripts that redirect users to previously hacked web servers. The user had inserted malicious files into into poorly secured web servers (inappropriate file ownership permissions). The Chase Bank scam has already been closed by the owner of the hacked web page. I have contacted the administrator of the site that contains the PayPal scam and asked them to remove the malicious files.

I would like to identify the user and prosecute them if possible.

Any thoughts?

Sam Bowen

9
skenow
Re: XOOPS security
  • 2007/10/26 23:38

  • skenow

  • Home away from home

  • Posts: 993

  • Since: 2004/11/17


Do you have spaw installed with CJay content? http://secunia.com/advisories/10451/

10
drbowen
Re: XOOPS security
  • 2007/10/27 16:49

  • drbowen

  • Just popping in

  • Posts: 19

  • Since: 2006/4/28


No I do not. I ended up not installing any of the WSIWYG editors.

When I first installed XOOPS 2.2.3 it was the recommended stable most recent version. It became apparent that a lot of the modules were not compatible with 2.2.3, I remember trying to install one of the WYSIWYG editors but it didn't work (I don't remember ever trying Spaw).

Later the XOOPS developer group decided to back up and go back to 1.3.10 as the recommended stable release. This has now progressed to 2.0.17.1.

I have been stuck. Reverting 2.2.3a back to 1.3.10 is not very easy. The XOOPS roadmap states that eventually the two branches will be brought back together in 2.4. But I am not sure if and when this will actually occur.

Sam Bowen, MD
www.oemr.org

Login

Who's Online

61 user(s) are online (28 user(s) are browsing Support Forums)


Members: 0


Guests: 61


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Aug 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits