Made some changes to tpl_shopping_cart_default.php and either because of those changes or just coincidentally, now when adding anything to the cart the page errors out with "The connection was reset / The connection to the server was reset while the page was loading."

Even more strange is when you hit the back button, it shows the item in the cart with a quantity ranging from 4-10. You can go to the shipping cart and see item with various quantities there.

So, something it happening at the moment the add to cart button is clicked. Any ideas what?

The error above is from Firefox. Here is what Chrome says:

No data received
Unable to load the webpage because the server sent no data.
Here are some suggestions:
Reload this webpage later.
Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data.

Would you post a link to the site? If you don't want it indexed, you can enter the address like www.mysite com (missing the . before the com).

lat9:

Would you post a link to the site? If you don't want it indexed, you can enter the address like www.mysite com (missing the . before the com).

I was afraid someone would ask that. I very much appreciate any help but it being a client site I would rather try to solve this without posting if possible. Since it's not a design issue I'm hoping it will be possible. Thank you :blush:

The tpl_shopping_cart_default.php back to how it was before. Cleared cookies. Still having the issue though.

Same thing happening with the contact form. Throws the error page but sends 3 or more messages.

Seems like it might be a server issue. I tried to revert back to the unmodified template files for the shopping cart and product display. Issue still happening. Has anyone else ever heard of this?

Identical problem and symptoms (except my contact form works fine). Happened out of the blue on a long-happy functionalal site (on about 5/29/13) with which I had not been tampering, promise. I've not been able to figure it out ... and see no resolution here. Help!?

Site is: www.jewellamberoil com/sales/
Version: 1.3.8
Server: Linux on Godaddy

Nyssa:

Identical problem and symptoms (except my contact form works fine). Happened out of the blue on a long-happy functionalal site (on about 5/29/13) with which I had not been tampering, promise. I've not been able to figure it out ... and see no resolution here. Help!?

Site is: www.jewellamberoil com/sales/
Version: 1.3.8
Server: Linux on Godaddy

Looks like you have GoDaddy. It's their fault, something about some security update. Call them relentlessly to get it resolved.

Well it turns out that maybe it's not their fault. It appears that it is related to being hacked way back in 2011. Files that were created back then were used not to modify the index.php. There are some inconsistencies to this: the site was updated to 1.5.1 a while back, and according to them the site was hacked in March, but this issue only started last week. (It seems that the old install was still on the server and must have still contained the hacks from 2011 therefore they were able to use those files to compromise the new install, even though the other directory names were changed!)

Malicious Files Removed From Account:

/html/email/editors OLD/htmlarea/plugins/FullPage/popups/popups.php
/html/images/91831.php
/html/images/nddbc.php
/html/secureserver.php
Sample secureserver.php:
$auth_pass = "6256e91191e24a27";
$color = "#00ff00";
$default_action = 'FilesMan';

So in 2011 someone injected a file called secureserver.php, interestingly that would have referred to GoDaddy stuff right? Aren't they owners of the secureserver domain?

Files Containing Malicious Content (these files have been cleaned):

/html/includes/application_bottom.php
/html/ruby/move/includes/application_bottom.php
/html/ruby/move/includes/application_bottom.php
/html/index.php
Sample:
eval(base64_decode(wyFsyKjRdGnKpTeSGtjBVEeWTJGfrJKFD376FfgerEW

Sample of Attack Logs:

64.71.150.37 - - [20/Mar/2013] "GET site/secureserver.php HTTP/1.1" 200 1589 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0"
64.71.150.37 - - [20/Mar/2013] "POST site/secureserver.php HTTP/1.1" 200 67156 "site/secureserver.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0"

pricediscrimination:

It seems that the old install was still on the server and must have still contained the hacks from 2011 therefore they were able to use those files to compromise the new install, even though the other directory names were changed!)

Typically, what happens is people wait until their V1.3.8 install has been hacked, which usually involves uploading the 'back door' programs, then the site gets 'updated' leaving these backdoor files intact.
The hackers come back days, weeks, months, sometimes years later to see 'whats new'. Usually without the site owners knowledge.

pricediscrimination:

So in 2011 someone injected a file called secureserver.php, interestingly that would have referred to GoDaddy stuff right? Aren't they owners of the secureserver domain?

Doesn't really matter who owns the domain name. The filename was chosen so as to not be obvious that it doesn't belong. It could have been called anything,

This scenario should serve as a warning to anyone still running V1.3.8 and anyone that has been hacked while running this version and done a haphazard job of the recovery and upgrade. You must check for newly added files. Too many people think that a simple file comparison is enough to identify these backdoor programs.

Cheers
Rod.

ps. Thanks for sharing.

RodG:

Typically, what happens is people wait until their V1.3.8 install has been hacked, which usually involves uploading the 'back door' programs, then the site gets 'updated' leaving these backdoor files intact.
The hackers come back days, weeks, months, sometimes years later to see 'whats new'. Usually without the site owners knowledge.

In this case they must have dropped those files back in 2011 but didn't actually do anything to mess up the site. Updated, in this particular case, wasn't due to being hacked or anything, but it does appear that lots of people wait until that point.

The old files remained on the server but were all in different directories. How could the hacker have been able to find those files again despite the added and renamed dirs?

And what was the hack that caused the site to add multiple items to the cart and time out when using a form like that? (also strange that apparently they hacked in March according to logs, but this issue started in June.)

pricediscrimination:

How could the hacker have been able to find those files again despite the added and renamed dirs?

Same way that anyone finds anything on the Internet. Search engines. I'm unsure why you felt the need to ask this???

pricediscrimination:

And what was the hack that caused the site to add multiple items to the cart and time out when using a form like that?

Your guess is as good (probably better) than anyones. My guess is that this is an unexpected/unwanted side effect of whatever it was the hacker(s) had done.

pricediscrimination:

(also strange that apparently they hacked in March according to logs, but this issue started in June.)

I don't find this particularly strange at all. It could be two different hackers that independently found the backdoor(s) a few months apart. The 1st just snooping around, the second probably trying to install additional exploit software, messed something up in the process, which caused the alarm bells to ring.

Your line of questioning leads to to think that you may have some doubts over this being a possible scenario? It happens far more than you may imagine. The only difference here is the timing of the events. The entire scenario usually playing out over a matter of days/weeks, rather than months/years.

There is also a lot of speculation here. It is equally possible that this hack has nothing to do with ZenCart at all, and the backdoor code was uploaded via some other means at some other time. I/we don't have enough information available to us that will allow a full/detailed audit of what really happened (or when).

Cheers
Rod
(Adv Dip Network Security)

RodG:

Same way that anyone finds anything on the Internet. Search engines. I'm unsure why you felt the need to ask this???

I'm unsure why you felt the need to add three question marks??? It was a perfectly reasonable question. Not everyone is "Adv Dip Network Security" like Rod is.

:cool:

pricediscrimination:

I'm unsure why you felt the need to add three question marks??? It was a perfectly reasonable question. Not everyone is "Adv Dip Network Security" like Rod is.

:cool:

Troll begone!