Jump to content

Anatomy of a Hack


Guest

Recommended Posts

Ok I just discovered some php files in the image folders and pear folder also. What is supposed to be in the pear/tmp folder? Or in the whole pear folder for that matter?

Link to comment
Share on other sites

  • 4 months later...

Guest walmarc

Basically I added .htaccess password-protection to the admin directory. Then I added "deny to all" .htaccess files in the following directories: classes, extra, includes, language, modules, and pear. This means that PHP scripts on the same server (index.php, cart.php, etc.) can access these files, but remote includes will be denied access.

I've recently had attacks involving pear/tmp. Have CHMOD'd to 744 to prevent the multitude of attempts to access hacks and warez links related to the site's pear/tmp folder. Will the CHMOD affect CubeCart in any way - or is there something else I should be trying?

Link to comment
Share on other sites

  • 3 months later...
Guest damascus

Great post, not sure if this is related but here I go.

We had an order placed say on a Friday and paid for in a bona fid way through paypal for an amount of say $365. On sunday the order had changed to 2 different products to a total of $880 but same order ID and no change in payment from paypal.

Is this

A/ some sort of glitch in the cubecart programme?

B/ some sort of hack

Further to this we deleted the order and reversed the payment and let the customer down softly via email. Customer reply is they are keen for all products and have reordered and re paid via paypal.

Any Ideas????

we have done a reverse check on phone number and it checks out to name and city/ possibly a fake mobile registration??? BTW the delivery address is a $2mil house currently for sale.

Link to comment
Share on other sites

  • 1 year later...
Guest Paul.G

Basically I added .htaccess password-protection to the admin directory. Then I added "deny to all" .htaccess files in the following directories: classes, extra, includes, language, modules, and pear. This means that PHP scripts on the same server (index.php, cart.php, etc.) can access these files, but remote includes will be denied access.

Hi Sir William,

Just having a go at adding the .htaccess protection you talked about, but any ideas what would cause the "deny to all" file to also stop the server side scripts? as when I protect the folders the features on the site wont work??

Hosted on Linux with Apache version 2.2.11

Thanks,

Paul

Link to comment
Share on other sites

  • 11 months later...
Guest Shelbeeray

I just completely cleaned out my domain after an exploit in a Joomla installation resulted in all hell breaking loose - they actually installed programs and mailed spam from my domain. One folder, 16 levels down in a module with permissions set at 777. I've rebuilt my store since that is the most important. I will rebuild the other sites after I am certain I have done everything in reason to make CC as secure as I can. I'm pretty darn grateful to Google for notifying me of the attack and bad files.

My questions:

1. I am used to setting all folders to 755 and all files to 644. Is that the best rule? Are there any files in CC which need to have a higher permission? How about folders? Can I lower access on any folders, say to 444 or 400?

2. Is there a good .htaccess file setup that I can use in CC that should not interfere with its operation? I've read up on .htaccess security and there are sooooo many suggestions, that now, I don't know what I should have that will work properly with CC.

3. Is there a way to scan my domain to find permissions set to 777? or 755? or whatever setting? I've been going through the folders and files one by one, but some are quite deep and I don't want to miss a single folder or file because I know the price!

I'll keep looking on this site and on .org. I just need really good, solid security advice because I don't want to go through this again. I know we can never be absolutely, 100% certain that we are safe, but I'd like to know how to try!

Link to comment
Share on other sites

  • 3 months later...

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.

:lol:

Link to comment
Share on other sites

  • 1 month later...
Guest shereen

thanx! sir william, but i was just contacted by my isp this past friday and i was informed that spammers hijacked my "cubecart v.3 tell a friend" script to send out a mass/bulk e-mail (spam). i am now ordered to take care of this problem with this script or else the isp will disable it in 72 hours.

i have looked at the php file for "tell a friend" and i don't see that it has the same validation as for the e-mail subscription list...is there a way to modify the "tell a friend" script so that it is not hijacked by future spammers?

i really need assistance regarding this issue asap--if we need to take this off board, that's fine by me, please contact me.

~ shereen ~

www.splashgearusa.com

Link to comment
Share on other sites

  • 1 month later...

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.

hackx.gif

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.

:lol:

Link to comment
Share on other sites

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

It's not a hack. Just enable spam control in General Settings.
Link to comment
Share on other sites

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

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

It's not a hack. Just enable spam control in General Settings.

Link to comment
Share on other sites

Obviously if you have manually disabled it for the registration form, then it won't do it's job.

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...