Possible Security Issue

[mattyb]

Ok so I went to do a backup of the database b/c you can never be too safe. And in the listing I saw these files:

 

base.php

.htaccess

guest.php

messages.php

 

They were done at about 9am yesterday morning. Our store is closed then and I'm pretty sure I'm the only one who knows how to do it. Should I be worried? And what do they reference?

 

Thanks everyone.

[user99999999]

You probably have more. You need to contact your host and find the security problem and restore your site. Most likely came from another account on your server and not osc code unless you did not password protect your admin.

[mattyb]

The site is password protected. Can I just go and delete those or should I leave those there for the host staff?

[mattyb]

There is another quick question I have. The /catalog/admin directory is password protected but the other directories are not. What preventative measures can I take so that this doesn't happen again?

[mattyb]

After conversations with our webhost this is what they said:

Thank you for bringing this to our attention. In

checking your account it appears that an intruder

was able to inject files into the directories on

your account which were assigned world write

permissions (777). In addition to the files you

mentioned in /catalog/admin/backups I found similar

files in /catalog/temp and /catalog/temp.

 

The files are listed as being owned by user nobody

which indicates that they were uploaded through or

generated by a PHP script, and as only directories

which have write permissions (777) seem to be effected

my suspicion would be that a security flaw in a PHP

script may have been exploited and that the intruders

took advantage of the writable directories to inject

files.

 

If you change the permissions on the the /catalog/admin/backups directory to 775 none of the backups show up. Is there anything that can be done?

[user99999999]

You can look in your apache log files and see if it came via your scripts.

 

What verson OSC and what mods do you have.

 

If you have 2.1 then include_once.ph might be your problem

 

http://xforce.iss.net/xforce/xfdb/9369

 

http://www.oscommerce.com/about.php/news,72

[mattyb]

You can look in your apache log files and see if it came via your scripts.

 

What verson OSC and what mods do you have.

 

If you have 2.1 then include_once.ph might be your problem

 

http://xforce.iss.net/xforce/xfdb/9369

 

http://www.oscommerce.com/about.php/news,72

 

I'm running 2.2 MS2. I'll take a look at the logfiles to see. Thanx for the help though.

[RobertBlas]

Past posts have also recommended

 

1) changing the name of your admin directory so that hackers can not easily guess where it is.

2) Use SFTP rather that FTP on any data transfers. I don't know how, but people who do can get your password from some sort of FTP log or console on shared servers.

 

 

I have also

3) changed my backup directory name

4) created a blank index.html file in any work directory I create so that people can not easily get a web listing of concents.

5) if your OSC version is prior to Nov 2005, there are a bunch of security updates that are fairly easy to

implemement ... see the announcements section of this bullitin board.

 

I probably should also change the temp directory name.

[custodian]

Past posts have also recommended

 

1) changing the name of your admin directory so that hackers can not easily guess where it is.

2) Use SFTP rather that FTP on any data transfers. I don't know how, but people who do can get your password from some sort of FTP log or console on shared servers.

I have also

3) changed my backup directory name

4) created a blank index.html file in any work directory I create so that people can not easily get a web listing of concents.

5) if your OSC version is prior to Nov 2005, there are a bunch of security updates that are fairly easy to

implemement ... see the announcements section of this bullitin board.

 

I probably should also change the temp directory name.

 

 

Better way is to have the web host Removed "Indexes" from Options directive... something like

 

UserDir public_html

 

#

# Control access to UserDir directories. The following is an example

# for a site where these directories are restricted to read-only.

# Removed Indexes from Options to improve security

#

<Directory /home/*/public_html>

AllowOverride FileInfo AuthConfig Limit

Options MultiViews IncludesNoExec SymLinksIfOwnerMatch

<Limit GET POST OPTIONS>

Order allow,deny

Allow from all

</Limit>

<LimitExcept GET POST OPTIONS>

Order deny,allow

Deny from all

</LimitExcept>

</Directory>

 

This way you don't need to worry if you took care of ALL directories...

 

To the original Poster.

 

Setup a file in your /admin directory

 

name it .htaccess

 

in side put this

 

AuthType Basic

AuthName "Restricted Files"

# (Following line optional)

AuthBasicProvider file

AuthUserFile /home/YOUR-NON-PUBLIC-ROOT-DIRECTORY/passwords

Require user SOME-USER-NAME

 

<IfModule mod_setenvif.c>

<IfDefine SSL>

SetEnvIf User-Agent ".*MSIE.*" \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

</IfDefine>

</IfModule>

 

 

 

Then either you or your admin should run

 

htpasswd -c /home/YOUR-NON-PUBLIC-ROOT-DIR/passwords SOME-USER-NAME

 

It will prompt for a password for the SOME-USER-NAME

 

example.. if you set the SOME-USER-NAME to bob

 

$: htpasswd -c /home/bob/passwords bob

 

That's it.

 

If you have telnet access, turn it off, use SSH.

 

And yes a 'hacker' could intercept information in transit, though in order to do this some point between point A and point Z has to be compromised already.

 

 

See if your host will send you daily diff comparisons via a cron job - if you do a lot of daily changes this would not be worthy. But if you seldom change anything it will help you to stay on top of things when something mysteriously changes.