Jump to content

IMPORTANT -- !!!!!!


Guest aikdo

Recommended Posts

EVERYONE THAT HAS BEEN HACKED CHECK YOUR INCLUDES FOLDER IF YOU FIND ANY FILES OUT OF PLACE DELETE THEM ASAP... YOUR SERVERS WILL BE USED FOR THE NEXT ATTACK IF YOU DO NOT... DELETE NOW...

PS. one server had...

3 aha.php (contained a trojon)

db.pl (could alter ANY of your database info)

[email protected] (would be used on other servers alike)...

I have removed these and am looking for more... BUT EVERYONE SHOULD CHECK THEIR SERVERS NOW!!!!

Link to comment
Share on other sites

All this talk is worrying, how is it possible for someone to hack your site if they do not have access to your ftp details? Is this something i should be concerned about before transferring my shop to CC?

Your website is not using FTP, it's using HTTP or HTTPS. Considering PHP is a very dynamic and powerful programming language, it's not difficult to code something which may be exploited in one way or another at somepoint in the future. Vulnerabilities are not all known about from the beginning, when when they are found the consequences can be disastrous if not fixed/patched ASAP. Credit to the people involved with coding for CC for responding so fast.

There are an unlimited number of ways to code the same thing... this is why it's so easy to detect those copying the code for their own purposes. The vulnerabilities usually arrise from bugs/features when used in conjunction with one or more other bugs/features at the same time, if that makes sense.

I expect someone else can explain it better than me. But no piece of code can be considered bullet proof.

Link to comment
Share on other sites

All this talk is worrying, how is it possible for someone to hack your site if they do not have access to your ftp details? Is this something i should be concerned about before transferring my shop to CC?

CubeCart is not the only script that has been hacked on servers where register_globals is set to on. A large complicated script can often have vulnerabilities that hackers will figure out to exploit. The recommended default setting for register_globals has been OFF for quite some time now - hosting companies will hopefully start to wake up and realize that leaving it ON is inviting hackers into their machines.

Link to comment
Share on other sites

Guest theorbo

Don't hold your breath on that. As good as my host is, they're still saying in effect, as long as major scripts/programs like OScommerce are written to require register_globals enabled by default, they'll continue to run that way....

Link to comment
Share on other sites

Don't hold your breath on that. As good as my host is, they're still saying in effect, as long as major scripts/programs like OScommerce are written to require register_globals enabled by default, they'll continue to run that way....

No decent PHP script requires register_globals to be on. I don't know if osC requires this or not (it's been a couple years since I last set up an osC store), but if it does then it's just plain poorly programmed. All a programmer has to do for their script to work with register_globals off is to check for the expected post or query variables before using them, and not doing this basically means you don't really know or care where that variable came from (= hackers' dream).

I think that hosts will start to move en masse to setting this off as there are more exploits that affect them directly. When a hacker takes over your account and through it can send massive spam or distribute viruses, that affects your host quite a bit. It won't take this happening many times before hosts start to say "OK that's enough."

I think in general they leave register_globals set to on now because it means fewer support requests from people writing their own scripts who don't know any better, since most open source scripts have been register_globals independent for as long as I can remember.

Link to comment
Share on other sites

Guest sunshine

Considering PHP is a very dynamic and powerful programming language, it's not difficult to code something which may be exploited in one way or another at somepoint in the future. Vulnerabilities are not all known about from the beginning, when when they are found the consequences can be disastrous if not fixed/patched ASAP. Credit to the people involved with coding for CC for responding so fast.

There are an unlimited number of ways to code the same thing... this is why it's so easy to detect those copying the code for their own purposes. The vulnerabilities usually arrise from bugs/features when used in conjunction with one or more other bugs/features at the same time, if that makes sense.

I expect someone else can explain it better than me. But no piece of code can be considered bullet proof.

I agree with Robsta and Zap. While we're in the midst of a script vulnerability, we are not the only ones. PHP overall has been facing some pretty strong attacks lately; ditto for Windows, Firefox and any other very popular scripts. It's the consequence of todays world and doing business over the world web. A script may not necessarily be vulnerable in it's born stages, though in time it is virtually inevitable. This is why, CC is my choice. I know this cart is being actively developed and I know Brooky puts his heart into this. I like his standards and his focus on ease of use, streamlined and feature-rich without intentionally compromising the security of our business. The contributions from some of the excellent coders here and the friendly forum are equally important.

With that said, maybe this fix wasn't necessarily 'succcessful' but frnkly, I'm thankful Brooky and his friends took immediate action to help secure our businesses. I'll take what they did over sweeping it under the rug any day of the week. Granted, implementing a 'Tester Group' is a fantastic idea, but in situations like this, it may not always be feasible. Time can be our friend or enemy so this could very well happen again and if it does, I hope Brooky makes the same decision and as Owner or Administrator, you make the choice to use the temp patch but if you've accepted the responsibility of managing others on your server or protecting your customers personal info, then you should be responsible and take the 'extra time and effort' even if it means patching two, three, ten times.

What you can do on the front-end is to ensure permission in all your file/folders are proper, check through your files for anything that wasn't put there by you, create long passwds using combo numbers/letters/symbols.

:)

Link to comment
Share on other sites

I'd like to thank cubecart for the orders I lost. I applied the fix, and after a few days found a forbidden 403 on the last step of the shopping cart for one of my 2 payment methods. And I was wondering why business was so slow.

This is on top of the bug (logged) where items deleted from a shopping cart show up on the order anyway (how many free products have I sent out before noticing this bug? Who knows?), that's just the issues that directly cost money. Heaps of others.

Cubecart... the cart that keeps on costing.

Link to comment
Share on other sites

Guest woodbtreasures

I'd like to thank cubecart for the orders I lost. I applied the fix, and after a few days found a forbidden 403 on the last step of the shopping cart for one of my 2 payment methods. And I was wondering why business was so slow.

This is on top of the bug (logged) where items deleted from a shopping cart show up on the order anyway (how many free products have I sent out before noticing this bug? Who knows?), that's just the issues that directly cost money. Heaps of others.

Cubecart... the cart that keeps on costing.

Yea your right...it would have been much better for them to have simply done nothing and then everyone's site could have ended up like mine.

Quit bitching and be thankful. If your cart had been hacked you wouldn't be doing any business at all...you'd be trying to put it all back together from the scraps that were left.

If you can do a better job coding then please by all means go and write your own super-non hackable shopping cart script...I'll bet brooky will even buy it from you.

Link to comment
Share on other sites

Please, spare me the "write it yourself". There's over 100 shopping carts out there, I'd just switch to another.

I'm not suggesting doing nothing. I'm suggesting doing the utmost basic of testing before releasing a fix to make sure that basic functions aren't broken.

If you've ever worked in a software development environment, you'll know about something called a test plan, designed to prevent exactly what happened from happening.

Oh, and if my store were hacked, I'd quickly restore from backup and keep going.

Edited by m00n1
Link to comment
Share on other sites

Guest woodbtreasures

Well if that was the case then why even bother to update at all.

After all each time it's hacked you could simply reinstall from your back up and move on.

Point is you sound like an ass. Granted you have one up on me as I haven't yet purchased my liscense yet...but I will and having my store hacked in no way will deter me from doing so.

Brooky works himself night and day on this software and the simple fact that he was trying to take a holday over the new year seems to give you the right to slam him and all of the others who devoted time and energy on their own to get this fixed.

You could be a little more greatful.

Link to comment
Share on other sites

Well if that was the case then why even bother to update at all.

After all each time it's hacked you could simply reinstall from your back up and move on.

My approach is to ensure my store is up and running as much as possible. Having the site hacked several times a week isn't going to achieve this, and the time I spend restoring will very quickly get tedious. Plus, there will be some loss if there's a hack, I don't backup every 5 minutes. Seeing a site hacked isn't going to inspire confidence with your customers, and will certainly affect sales. But you are free to choose that approach if you want.

Brooky works himself night and day on this software and the simple fact that he was trying to take a holday over the new year seems to give you the right to slam him and all of the others who devoted time and energy on their own to get this fixed.

And that's Brookys decision, not mine. I'm not forcing him to do that, and his work load places no responsbility on me. I have no problems with Brooky, I've had dealings with him and he's a nice guy. But I don't see what having a holiday has to do with it. It was a poor quality fix, with poor communication around it. I have a commercial product, and I expect reasonable support, which I didn't get. If you would prefer me to be a fan boy and say everything is sunny, despite loosing sales, just say so.

Software has bugs, that is inevitable, and unfortunately, security problems are also inevitable. A poor response to those bugs is not inevitable.

Edited by m00n1
Link to comment
Share on other sites

Guest TheWetFish

If you've ever worked in a software development environment, you'll know about something called a test plan, designed to prevent exactly what happened from happening.

Some people's kids..... :)

Moon... If you KNEW anything about software development side of things AND running your store on a script that did NOT cost you a single penny (NOBODY forced you to purchase a licence or anything else), you would grow up and quit whining about it. Brooky has done a fine job with CubeCart and he has NO CONTROL over some punk kids trying to hack cubecart sites. He made a quick fix that hindered future attempts at getting YOUR SITE HACKED ... he didnt do that for himself...he did that for YOU and everybody else. So while you have the right to sit and bitch about somebody giving you a free shopping script for you to make money with, Brooky spent the holiday season wondering which is the best way to secure that FREE SCRIPT that you are so ungrateful to have. I only hope that your customers can see how childish the person they are buying products from truely acts. I bet you would NOT have a single buyer if they only knew. So my advice (YES its FREE just like that shopping script) is to turn off your computer and go relax and think about how much of an idiot you are portraying yourself as. Then maybe you can come back in here and apologize like any decent human being would do.

Matt

Link to comment
Share on other sites

Guest bikeman

Don't hold your breath on that. As good as my host is, they're still saying in effect, as long as major scripts/programs like OScommerce are written to require register_globals enabled by default, they'll continue to run that way....

mmmm I am not aware of any major app which still requires register_globals to be on. Can't say never but everyone I know of, including oscommerce, has a mod to let the app run with reg_glo off.

Is your host irresponsible or have you just been fobbed off by a lazy tech support guy? Tech support are not usually the decision makers at med/large hosts. Write to them and tell them that you're going to move hosts, that may make their product managers review their decision.

Having said that you can turn register_globals off yourself via a .htaccess or php.ini file. However I have found that with a very popular host (1and1) you have to place a php.ini in every directory and sub-directory which is not very practical.

Link to comment
Share on other sites

My setup was the same as more and more hosting companies move PHP to a Cgi program rather that a Apache modual it means you cant use the .htaccess anyone and have to place a php.ini in EVERY folder and that really can be a pain in the a**e...

Link to comment
Share on other sites

Don't hold your breath on that. As good as my host is, they're still saying in effect, as long as major scripts/programs like OScommerce are written to require register_globals enabled by default, they'll continue to run that way....

I'm pretty sure this is still the case as I tried to install OsC about a month ago but couldn't as it required register_globals to be enabled. I searched and happily found a patch which could override this necessity but then it required something else to be enabled so I decided to use CC instead.

Whilst on the subject, the first time I tried to install OsC I couldn't get past install step 2 and the solution given to me was to ask my server provider to downgrade the current PHP version as it didn't work with PHP 5.0 (if I remembered correctly). My server provider wasn't pleased at the request. ;)

Apart from that being said, I've seen some quite amazing OsC sites.

Edited by Puppy
Link to comment
Share on other sites

Guest vrakas

Fortunatly my server provider gave me all the details to turn off and on whatever was needed to avoid this.

I had to add a simple line in the .htaccess and that did the trick.... i hope ;)

Link to comment
Share on other sites

Guest theorbo

bikeman: I myself attempted to use osc before finding cc. It required register_globals on (this was a few months back). There was nowhere to set for running with register_globals off - as stated by puppy, there were "tweaks" (unofficial IIRC), but then you had to tweak something else.... etc etc ad infinitum ad nauseam. In general, I don't make statements when I have no knowledge of the situation under discussion.

Link to comment
Share on other sites

If you've ever worked in a software development environment, you'll know about something called a test plan, designed to prevent exactly what happened from happening.
If you've ever worked in a software environment at all, you'd know to test your software after performing any upgrade. Why did you not test your payment process after the upgrade? If it didn't work, you could have easily reverted back to the backup you made just before the upgrade, right?
Link to comment
Share on other sites

bikeman: I myself attempted to use osc before finding cc. It required register_globals on (this was a few months back). There was nowhere to set for running with register_globals off - as stated by puppy, there were "tweaks" (unofficial IIRC), but then you had to tweak something else.... etc etc ad infinitum ad nauseam. In general, I don't make statements when I have no knowledge of the situation under discussion.

I did a search on the osC forums and found this thread. Basically both theorbo and bikeman are correct. osC as is requires register_globals set to on, but there is a commonly available mod that lets you run it with them off.

As someone from the osC Documentation Team says:

osCommerce MS2 was written at a time when Register Globals being on was not the issue it is now. There is a set of Register Globals Patch Files and there is a manual set of patch files for stores which have already been modified.

When I looked through the files from my last osC install (from over two years ago), there was some code in the downloaded files from then that was intended to make osC run with register_globals switched off. I guess it just wasn't completely patched then, and still hasn't been finished since then. I think that the last official release of osC was well over two years ago, so pretty much everyone at osC knows (or ought to know) that moding your files is much less optional than it is here.

I might also mention that the last time I installed an osC cart I decided that I would never do so again. The code is completely unintelligible spaghetti and needs a top-to-bottom rewrite. So personally I can believe that it requires register_globals switched on to work - and that's just the beginning of its problems.

Link to comment
Share on other sites

Guest bikeman

In general, I don't make statements when I have no knowledge of the situation under discussion.

mmm, touchy..

I agree there is nothing in oscoms admin but there is a mod that removes the requirement for register_globals to be on

http://www.oscommerce.com/community/contributions,2097

it is published on the oscommerce website, I have used it and it appears to work fine.

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...