inspectaclueso
-
Posts
6 -
Joined
-
Last visited
Posts posted by inspectaclueso
-
-
Thanks for the response, I've voted for the feature requests you linked to.
I am guessing it could be months or not at all until such a fix is implemented. In the meantime it makes CC a non-viable option for me.
Any advice/direction on what files need manual editing. Happy to spend a couple of hours on it.
Thanks
-
Hi People,
I have been running a small CubeCart store for a number of years and performed a truck load of mods when I originally did the setup.
After upgrading PHP version, it broke the store so I've done a fresh install of V6.1.8 using the standard Foundation skin.
One of the immediate things I'd like to do is remove the County field from the registration address fields as they are not applicable in NZ.
Any info I can find online or my old notes from previous CC versions refer to /includes/content/reg.inc.php which no longer appears to be the case.
Can someone please advise how it would be possible to remove reference to County from my CC installation.
Thanks
-
Thanks for the response.
I have "Enable Script/Bot Flood Control? Forces users to enter a code on registration, tell a friend etc to prevent bot's from spamming the store." set to YES
However I originally customised to registration form so perhaps this interferes with it? I don't recall users ever having to enter a code at registration?
Thanks
Jason
It's not a hack. Just enable spam control in General Settings.Hi again,
I'm surprised that there has not been more response to my original post and that no one else has experienced a similar thing.
Basically, my customers database is being populated with bogus customers. Below is a screen shot.
Does anyone have any ideas. Is some sort of bot actually populating my customer registration form or could the database be being hacked through some back door somewhere?
Any help would me much appreciated.
Thanks
Jason
-
Hi again,
I'm surprised that there has not been more response to my original post and that no one else has experienced a similar thing.
Basically, my customers database is being populated with bogus customers. Below is a screen shot.
Does anyone have any ideas. Is some sort of bot actually populating my customer registration form or could the database be being hacked through some back door somewhere?
Any help would me much appreciated.
Thanks
Jason
Hello CubeCart users,
I am currently finding nearly every day that random customers are appearing in my customer database with nonsense details. The phone number is always 0123456.
I have googled for this type of hack but can not find any reference to it.
Does anyone have any experience with this type of thing or can shed some light on it?
Could it be a hack of sorts or is it simply spam bots 'registering' as a new customer on the site?
Is it possible to include one of those spam catcha type verification boxes on the registration page?
My site is www.topstuff.co.nz
Thanks in advance
Jason
With more and more people claiming that their installations of CubeCart have been hacked, I thought it appropriate to explain a bit about how most hacks occur and what to do about them.The first thing we need to clarify is a problem in terminology. If somebody really did HACK your site, they would have found a way in to your admin or FTP. This could have been by guessing the password or by a brute force or dictionary password attack. This is NOT what happens to most installations or servers. So what is happening? Exploits.
An exploit is finding an existing security hole and taking advantage of it. There are many known exploits out there with software payloads that do everything from spamming to running IRC bots to portscans to collecting personal info from users. MOST are spamming and botnet attacks.
What most people see when they've been "hacked" is extra files in their /images/upload/ folder. This is because those folders have permissions set to "777". This means the folder is world-writable by everybody, including the web server -- user "nobody" for you more technical types. This is done to allow you to upload images to this folder. The potential problem is that ANY process on the web server can then write to this directory.
Now, the big question, HOW does that stuff get there? In disecting several exploit packages, there are several similarities that we'll discuss. The simplest ones put their payload into /tmp or /var/tmp. These are temporary folders setup by the operating system on the server for....uhhh...temporary stuff. Sessions, process IDs, etc are stored there. They are also world-writable.
The exploit code loads a small script into the /tmp folder and executes it. Sometimes that's all that happens, the code runs from /tmp and it does what it needs to. But some scripts are sneakier. They will perform a search on the server for other world-writable directories. They don't care where they are. But they will frequently load their payload into ALL world-writable folders....including YOUR CubeCart installation.
Herein lies the problem. There is typically NO trace of how those files got into YOUR folders. Just because they were in your store folders does NOT mean that they came in through CubeCart. I found one such instance where the exploited script was a forgotten portion of a web site that hadn't been touched in nearly 3 years. It was an older version of a software package that wasn't used much anymore. Unfortunately there was a published attack for it. That hole was exploited and the server compromised.
These "hackers" are almost never programmers themselves. They are what's known as "script kiddies". They find these exploit scripts on sites out there and use them for their own jollies. They also rarely have ill intentions against the servers or sites they exploit. They just think it's cool to do.
If you find stuff in your folders that shouldn't be there, let your hosting company know. The things they'll want to check are unknown or unusual files and folders in /tmp, /var/tmp/, /usr/tmp, /usr/local/tmp, and/or /dev/shm. Those are common payload dropoff locations. Also watch for unusually high server loads or unfamiliar processes running as user "nobody" (or whatever user Apache runs as). This can be done easily with this command under Linux: ps -f --User nobody.
If anybody would like to go into more technical detail, I'll be happy to in a private discussion. The main think I wanted to make people understand is that what they think happened may not be what really has happened. As of this writing, there are no known security holes in CubeCart. Hopefully this explanation will help people understand what really happened on their sites when they're "hacked".
-- Sir William is a programmer and systems/network administrator at an ISP in Arkansas, USA. He has been working with computers for over 23 years. He is a modertor here at CubeCart.com and a founding Administrator at CubeCart.org. He's contributed several modifications and additions to the CubeCart base code and spends countless hours helping others in both free and paid-consultancy capacities.
-
Hello CubeCart users,
I am currently finding nearly every day that random customers are appearing in my customer database with nonsense details. The phone number is always 0123456.
I have googled for this type of hack but can not find any reference to it.
Does anyone have any experience with this type of thing or can shed some light on it?
Could it be a hack of sorts or is it simply spam bots 'registering' as a new customer on the site?
Is it possible to include one of those spam catcha type verification boxes on the registration page?
My site is www.topstuff.co.nz
Thanks in advance
Jason
With more and more people claiming that their installations of CubeCart have been hacked, I thought it appropriate to explain a bit about how most hacks occur and what to do about them.The first thing we need to clarify is a problem in terminology. If somebody really did HACK your site, they would have found a way in to your admin or FTP. This could have been by guessing the password or by a brute force or dictionary password attack. This is NOT what happens to most installations or servers. So what is happening? Exploits.
An exploit is finding an existing security hole and taking advantage of it. There are many known exploits out there with software payloads that do everything from spamming to running IRC bots to portscans to collecting personal info from users. MOST are spamming and botnet attacks.
What most people see when they've been "hacked" is extra files in their /images/upload/ folder. This is because those folders have permissions set to "777". This means the folder is world-writable by everybody, including the web server -- user "nobody" for you more technical types. This is done to allow you to upload images to this folder. The potential problem is that ANY process on the web server can then write to this directory.
Now, the big question, HOW does that stuff get there? In disecting several exploit packages, there are several similarities that we'll discuss. The simplest ones put their payload into /tmp or /var/tmp. These are temporary folders setup by the operating system on the server for....uhhh...temporary stuff. Sessions, process IDs, etc are stored there. They are also world-writable.
The exploit code loads a small script into the /tmp folder and executes it. Sometimes that's all that happens, the code runs from /tmp and it does what it needs to. But some scripts are sneakier. They will perform a search on the server for other world-writable directories. They don't care where they are. But they will frequently load their payload into ALL world-writable folders....including YOUR CubeCart installation.
Herein lies the problem. There is typically NO trace of how those files got into YOUR folders. Just because they were in your store folders does NOT mean that they came in through CubeCart. I found one such instance where the exploited script was a forgotten portion of a web site that hadn't been touched in nearly 3 years. It was an older version of a software package that wasn't used much anymore. Unfortunately there was a published attack for it. That hole was exploited and the server compromised.
These "hackers" are almost never programmers themselves. They are what's known as "script kiddies". They find these exploit scripts on sites out there and use them for their own jollies. They also rarely have ill intentions against the servers or sites they exploit. They just think it's cool to do.
If you find stuff in your folders that shouldn't be there, let your hosting company know. The things they'll want to check are unknown or unusual files and folders in /tmp, /var/tmp/, /usr/tmp, /usr/local/tmp, and/or /dev/shm. Those are common payload dropoff locations. Also watch for unusually high server loads or unfamiliar processes running as user "nobody" (or whatever user Apache runs as). This can be done easily with this command under Linux: ps -f --User nobody.
If anybody would like to go into more technical detail, I'll be happy to in a private discussion. The main think I wanted to make people understand is that what they think happened may not be what really has happened. As of this writing, there are no known security holes in CubeCart. Hopefully this explanation will help people understand what really happened on their sites when they're "hacked".
-- Sir William is a programmer and systems/network administrator at an ISP in Arkansas, USA. He has been working with computers for over 23 years. He is a modertor here at CubeCart.com and a founding Administrator at CubeCart.org. He's contributed several modifications and additions to the CubeCart base code and spends countless hours helping others in both free and paid-consultancy capacities.
CubeCart 6.1.8 - County not applicable in my country, how to remove?
in Technical Help
Posted
Thanks for the responses. Populating the table with a single entry "N/A" could be a workaround. To do this, use PHP MyAdmin and edit that geo_zone so all County's are "N/A"?