Jump to content

CUBECART IS A JOKE


Guest

Recommended Posts

EDITED POST due to possible overexcitement - please find attached email from host

for some reason they are able to access and upload using the IMAGE dir, same happened last time. my sa fixed all problems - so obviously not well enough. any ideas?

i have now terminated the store.

----

Hello,

We have temporarily suspended the site below for Ebay Fraud. We have tracked this down to the path /home/filmrare/public_html/images/. Please investigate this in further detail and reply back (without fail) with the results of your investigations. The original Abuse Complaint follows.

Name: filmrare.com

Address: 65.98.67.242

Regards,

Sales Support

Beachcomber Creations Inc

[email protected]

Support: Desk https://tickets.beachcombersupport.net/supp...enter/index.php

http://Beachcomber.net

Relax..At the Beach

The content of all e-mail communication is strictly confidential and is intended solely for the use of Beachcomber Creations Inc and its client.

Disclosure, copying, distributing, public displaying or use of any information within this e-mail is strictly prohibited.

Subject: [eBay:IRN06V317] eBay.com e-mail spoofing and password phishing

To: [email protected], [email protected]

From: [email protected]

Reply-To: [email protected]

Date: Wed, 26 Apr 2006 20:24:45 -0400

Dear Fortress Integrated Technologies,

Please read through this email carefully, as it contains additional information important to this case.

We have just learned that your service is being used to display false or "spoofed": eBay.com pages, apparently in an effort to steal personal and financial information from consumers, and defraud eBay users. Specifically, it appears that a Fortress Integrated Technologies user is sending unsolicited messages which misrepresent the sender as eBay, and making false statements that encourage the recipient to go to a page hosted by you at

http://www.filmrare.com/images/.redirect/eBISAPI.php?

is asked to enter personal information. The purloined information is then sent to an email account and, based on our investigation of similar schemes, used to steal accounts and commit other fraudulent acts including international credit card and wire fraud.

**IMPORTANT**

This website WILL NOT pull up if you just open the provided URL. Using some PHP code, the creator of this webpage is able to tell the page to display only if the viewer has been redirected from another webpage. If you try viewing the page without that redirect, the page will not display. We have evidence of this and can give you the redirect code if you need it during your investigation of this site. You will also find in the images folder of this site a script the third party uses to upload these files as well as a script used to email information to those involved in this scheme. Please respond to this email if you need further information or the redirect code.

This matter is urgent - we believe that consumers have been falsely directed to this page and may be fooled into divulging personal information to a criminal if the page is not immediately disabled. We ask that you immediately disable the site at http://www.filmrare.com/images/.redirect/eBISAPI.php? as well as any associated email addresses, so that this fraudulent scheme can be stopped. We further request that you provide us with all contact information that you have for this user so that we may provide this information to the proper law enforcement authorities.

While we believe that the above information gives your company more than a sufficient basis for disabling the page immediately, out of caution we note that your user's unauthorized reproduction of eBay's trademark and copyrighted materials violates federal law, and places an independent legal obligation on your company to remove the offending page(s) immediately upon receiving notice from eBay, the owner of the copyrighted materials. Accordingly, the information below serves as eBay's notice of infringement pursuant to the Digital Millennium Copyright Act, 17 U.S.C. Section 512 ©(3)(A):

I, the undersigned, CERTIFY UNDER PENALTY OF PERJURY that I am the agent authorized to act on behalf of the owner of certain intellectual property rights, said owner being named eBay Inc. I have a good faith belief that the website located at URL http://www.filmrare.com/images/.redirect/eBISAPI.php? as its copyright in each page of its website and associated source code. Please act expeditiously to remove or disable access to the material or items claimed to be infringing.

We sincerely appreciate your immediate attention to this important matter. We would also appreciate if you would take steps to confirm the accuracy of any contact information that your user may have provided to you in establishing the account. Should you have any accurate information that could assist eBay and law enforcement in tracking this individual, we greatly appreciate your assistance, as we know that you do not condone the use of your services for such criminal purposes.

Finally, please be advised that we have referred this issue to the Federal Bureau of Investigation for their investigation. The F.B.I. has requested that we convey to you in this message their request that you preserve for 90 days all records relating to this web site, including all associated accounts, computer logs, files, IP addresses, telephone numbers, subscriber and user records, communications, and all programs and files on storage media in regard to all Internet connection information, pursuant to 18 U.S.C. Section 2703(f). While we do not act as an agent of the FBI in conveying this request, we do intend to fully cooperate with their investigation, and encourage you to do so as well.

eBay Inc.

Audit and Investigations

[email protected]

Get automated, real-time notifications of new phishing attacks! Join the Phish Report Network as a RECEIVER today! http://www.phishreport.net/

Link to comment
Share on other sites

Perhaps if you enlighten us as to the exploit used, someone could create a patch to fix it.

I'm certainly not an expert, but with the little I know about programming, the code seems solid enough. Certainly more secure than many other scripts I've used.

Link to comment
Share on other sites

Guest CaseyC

last month my site was pulled by my host as ebay had notified them thats someone was ebay phishing from the site.

that was v3.09 - it was then updated

today again v3.10 (the latest version) - again exploited. i never hear about this happening with oscommerce.

sales lost are in the thousands.

WARNING DO NOT USE CUBECART FOR ANYTHING IMPORTANT.

CC SUPPORT PLEASE CONTACT ME TO REFUND MY LICENSE MONEY.

I would also be very interested how CubeCart was "exploited"........please explain.

Link to comment
Share on other sites

Until you can backup your statements, I put ZERO faith in them. You need to send one of us the proof provided by your hosting company that shows that CubeCart specifically was the root of the problem.

At this time, there are no known exploits of 3.0.9 or 3.0.10.

Don't come on here and scare people without proof.

:P

Link to comment
Share on other sites

Guest groovejuice

As a successful ( and mostly trouble free) user of CC for the better part of a year -I'd like to say that I 'm confident that Brooky and the Gang are in perpetual motion improving, upgrading, creating....ad nauseum.

Having said that in all honesty, it is perhaps time a designated area in the forum for exploits and general site vulnerabilities is created. I feel this is overdue and have noticed several provocative suggestions regarding

'email a friend' among others, have gone unaddressed by the moderators.

2 rubles worth...

Link to comment
Share on other sites

Guest landracing

There was an issue with my server doing the same thing from ebay...

Here was the problem, the passwords on the account were compromised...

Let me guess someone added directories on your server and was publishing

a page that looked like ebay...

I suggest you strengthen your passwords on the account....

Seems that you are one of the only ones with the problem, instead of

bashing the product why dont you enlighten us with your genius mind....

I am a newer user with Cubecart and I must say I love it, only wish more

features came with it instead of purchasing third party...

Landracing

Link to comment
Share on other sites

Guest vrakas

Have you searched this forum to find the thread(s) that tells you ways to secure your server?

I would strongly suggest you do this, stop paniking and trying to create something that does not excist :P

Link to comment
Share on other sites

Guest EverythingWeb

Well it would appear the the images/ folder on your server has been compromised. Please bear in mind that /images/uploads and images/upload/thumbs are the two directories that should be given Write permissions to the Web Server user.

If you have set images/ with a permission of 777, then please note this is your responsibility, no-one elses.

If you can still login to your FTP, please navigate to the images/ folder, and somewhere in your FTP client, send the command to show hidden files. On WS_FTP there is a small white box, top right, in which you would type -a

This will show you the folder who's name is proceeded with the .

Get some information as to when it was created and which user owns it.

There's some starting points for you....

Link to comment
Share on other sites

Guest gwizard

The "upload files to images folder" has been fixed in 3.0.10 and there is a very simple patch available for 3.0.9 as per Brooky's announcments. However, as stated above, if you indeed gave 777 permissions to your images folder or your host did it via Fantastico install, then it's not CubeCart issue.

I suggest you speak with your host and explain them that.

Link to comment
Share on other sites

that is false

images dir had correct permission

fantastico did not install it

v3.09 was exploited using this method

v3.10 was exploited using this method

* i find it highly doubtful that a writeable image directory could be to blame anyway - as peoples images directories around the world would be affected (as loads of scripts require a 777 image dir).

Link to comment
Share on other sites

Guest gwizard

Care to send me your server logs to see how the exploit was done ?

If it's the same way as I know then something was wrongly uploaded/configured in your case. If it's a new one, that should be interesting :P

Use [email protected] for email.

Link to comment
Share on other sites

i terminated the site via whm, where would i find the log? as obviously i want to keep using cubecart as we just started getting on.

Link to comment
Share on other sites

Just an FYI....I'd put money that the culprit was NOT CubeCart. I've seen this before on another customer's server. The malicious script is called through an insecure script anywhere on the server. It then uses system calls to run a find for any directory with 777 permissions. It then puts the offensive files in that directory. It doesn't have to be on the same domain at all. I finally found it by parsing EVERY web site's log file looking for the offensive code traces.

So no, I don't believe CubeCart was the problem. But it may have been the first one they found with 777 permissions. I would be happy to share this info with your host if you desire. Because until they find the problem script, the entire server is vulnerable....PERIOD!

:P

Link to comment
Share on other sites

Guest Brivtech

Out of interest, when did you last change ALL of your passwords?

By this I mean, have you changed them for:

- FTP access

- SQL database

- CubeCart admin login

- Ebay password

- Pay-pal password

and passwords that may affect any other parts of the system.

I would also like to suggest that your host provides further information about where the access came from, which should clear your concern about the FBI knocking at your door.

There is a chance that the server's own shared hosting was compromised, although this is more of a rarity, and chances are that someone sneaked in another way.

Finally, the passwords you use - if you don't already, you should be mixing them up, so they are random:

A password like "fluffy" is worthless, as it is a dictionary word- one like 'dfj309HgJ" will take much much longer to crack - Hackers go for easy targets.

Link to comment
Share on other sites

Guest walmarc

i terminated the site via whm, where would i find the log? as obviously i want to keep using cubecart as we just started getting on.

By default, I believe Fantastico sets permissions on /images/uploads/ to 755. I needed to amend this (ver. 3.0.10) to 777 to upload images in "add product" or "upload images" (to prevent an error message in FCKEditor).

As long as you amend the permissions on this folder back to 755 after upload I don't believe you will have a security issue - anyone please correct me if I'm talking "bullshit" (Aussie terminology)!

:wacko:

Link to comment
Share on other sites

This doesn't sound to me as if this person's password(s) were compromised. If that had happened, the hackers could have modified any file on the server. The fact that they used the images directory (with permissions of 777) makes it seem much more likely that a script was compromised.

So for example if there is a vulnerability in Pear that the hackers look for (because they have already worked out the exploit), they could run it as the PHP user and write to any 777 directory. Many PHP-based sites (CMS, portals, forums, eCommerce, etc.) use Pear and also set the images directory to 777 for easier uploading of images in exactly the same way that these hackers may have uploaded their code.

I don't know that Pear has anything to do with this of course; it's just an example of the kind of standard package that might be an attractive target for hackers.

The fact that they named their file ".redirect" makes me think that they didn't do it directly throught CC 3.09 or 3.10, since I believe that there is code in those to restrict uploads based on file extensions. This would offer some protection against this type of hack if and only if CubeCart is the script that they are attempting to exploit to copy their files. If they find a vulnerability in some other script on the server then of course the file extension limits in CubeCart are irrelevant.

It is certainly easier to allow clients to upload images via a PHP admin tool, but I wonder whether the danger of having 777 directories on your site outweighs this convenience. If you don't make these directories world-writeable the only disadvantage is that you have to upload images and thumbnails via FTP. Alternatively you could set these directories to 777 only when you want to use the image features in Admin and then reset them when you finish (perhaps on some servers we could even script an "Unlock/Lock Image Features" link into the admin area).

I have used .htaccess to protect the admin directory, which means that users need to log in twice (once for Apache and again for CubeCart), but it also protects all the scripts within that directory from hacking. I think that's worth the extra hassle of logging in twice. Rich Text Editors like FCK are also common targets for hacks, and I think it's best to limit your exposure.

What other things can we do to make CubeCart more secure? Anyone tried using .htaccess to deny all users entry to the includes and Pear directories? I think that would be another big step towards a much more secure installation.

It seems to me that CubeCart is relatively secure when compared to other PHP packages and doesn't present as easy or big a target as some others, but we could still lock it down a bit better so that other exploits can't compromise it as well.

Link to comment
Share on other sites

Guest gwizard

t is certainly easier to allow clients to upload images via a PHP admin tool, but I wonder whether the danger of having 777 directories on your site outweighs this convenience.

This is not the only function that CC does. It is also resizing the image and making a thumb out of it.

So, no, this idea is a no go.

Link to comment
Share on other sites

Realistically, setting permissions to 755 after doing graphic additions and/or product changes which require thumb creation would help, but would only bandaid the problem, not solve it. The scripts allowing writing to these directories are NOT in the directories themselves. They could literally be ANYWHERE on the server. Since it's next to impossible to police each and every script running, keeping things under control is an ongoing battle for server admins.

When an exploit has happened, it takes careful and tedious reviews of log files and program versions on the entire server to find what happened. It sucks....believe me, I know.

:wacko:

Link to comment
Share on other sites

This is not the only function that CC does. It is also resizing the image and making a thumb out of it.

So, no, this idea is a no go.

I'm going with it. I prefer to make my own thumbnails anyway. But like I said you could always just reset your images folders to 777 whenever you want to use those features (and depending upon your server's PHP user privileges you might be able to script changing permissions into the admin menus).

A lot of scripts count on having images and cache folders world-writeable, so this is not just a CubeCart issue at all. But it is a risk that is being exploited more and more and I personally would rather FTP my images than have my site hacked. That may not be how everyone feels about this, but it would be nice to have available instructions for the option of doing this.

Anyone tried protecting the includes and Pear directories? I guess I'll give that a shot this afternoon. In future releases maybe these directories should be within the admin directory so that it could all be easily protected via Apache.

Realistically, setting permissions to 755 after doing graphic additions and/or product changes which require thumb creation would help, but would only bandaid the problem, not solve it. The scripts allowing writing to these directories are NOT in the directories themselves. They could literally be ANYWHERE on the server. Since it's next to impossible to police each and every script running, keeping things under control is an ongoing battle for server admins.

Well it might help. On most servers the PHP user can't write to a directory unless the permissions are 777 (which is why we set the images folder to this). So if a hacker can exploit a script somewhere (CubeCart or other) but can't write to your server then there's actually very little they can do. It's when they can write their own executable code to your server that they can do some damage. That's how this eBay spoof works, and that's how spammers can bulk mail from your server even if you have no mail form. If you have no 777 directory on your server then they won't be able to install their own scripts, which means they could only exploit code that already exists (and isn't likely to be very useful).

Link to comment
Share on other sites

Guest gwizard

Actually, the idea of putting image dir under admin and crafting .htaccess that would require password to protect the realm is a very nice idea. The next question is what would you do with a windows server or one that doesn't run Apache ?

The proper way to handle this for good is chown the image dir to the webserver user and setting it to 744. But that would require prior knowledge of what the webserver user is. Maybe if the images dirs were to be created by the installation script instead of being copied ?

Brooky, for your consideration. :wacko:

Link to comment
Share on other sites

Actually, the idea of putting image dir under admin and crafting .htaccess that would require password to protect the realm is a very nice idea. The next question is what would you do with a windows server or one that doesn't run Apache ?

The proper way to handle this for good is chown the image dir to the webserver user and setting it to 744. But that would require prior knowledge of what the webserver user is. Maybe if the images dirs were to be created by the installation script instead of being copied ?

Brooky, for your consideration. ;)

I think that something like what you're proposing would make a lot of sense. I would still leave the images directory outside of admin so that there are no issues loading images in pages if people use .htaccess to protect the admin directory. But I would definitely move all scripts (includes, Pear, etc.) that don't HAVE to be outside into it.

I'm not sure if CHOWNing the images directory would close the loophole as well as switching from 777 to 755 when you're done using it via admin. The reason is that if a script is exploited in a way that allows writing then it would be running as that user (and so could write wherever it is the owner). So that wouldn't make any difference in that particular circumstance at all.

Windows servers don't have all the advantages of Apache, but that's no reason for those of us who run Apache not to use all of its features (it's more of a reason for Windows users to switch). But the same basic principles would apply to Windows server setup. It's just a matter of protecting all scripts except the main ones in the admin directory and not having any world-writeable directories lying around.

Apache .htaccess authentication is extremely secure, so it makes me sleep a lot better at night to have as much as possible protected by it.

Link to comment
Share on other sites

Guest Brivtech

William's idea of CHMODding the folder from 777 to 755 when finished sounds like a good interim solution until an improvement can be found.

There's also the consideration of making a full backup when the store is installed, so if a hacking attempt in thisor any other manner is detected, the server can be cleaned out (images simpley downloaded, all files on server erased) and then restored. If the rogue script was beign called from somewhere else, at least this will eliminate it.

Link to comment
Share on other sites

Guest gwizard

I would still leave the images directory outside of admin so that there are no issues loading images in pages if people use .htaccess to protect the admin directory. But I would definitely move all scripts (includes, Pear, etc.) that don't HAVE to be outside into it.

No need !

You forget that PHP can use file path as well as web path. While the writable directories reside inside protected admin dir, there is no problems for PHP to load the images using admin/images/uploads/1.jpg instead of domain.com/admin/images/upload/1.jpg

Pear shouldn't be writable at all. The only reason (as far as I understand and please correct me if I'm wrong) for the Pear/tmp dir to writable is PayPal IPN.

Link to comment
Share on other sites

I would still leave the images directory outside of admin so that there are no issues loading images in pages if people use .htaccess to protect the admin directory. But I would definitely move all scripts (includes, Pear, etc.) that don't HAVE to be outside into it.

No need !

You forget that PHP can use file path as well as web path. While the writable directories reside inside protected admin dir, there is no problems for PHP to load the images using admin/images/uploads/1.jpg instead of domain.com/admin/images/upload/1.jpg

Hmm. I'll have to test this. I was under the impression that if you used .htaccess to protect the images folder (since it would be inside the admin folder, which would be password-protected) that you couldn't display any of those images in a web page without authentication (since the browser calls them via http).

But if I'm wrong, then that would be a perfect solution. You could still use the thumbnail and upload scripts but the 777 directory would be inside a protected directory. If it works you could have your cake and keep it secure, too.

The next best thing would be to have the images directory outside the admin directory but script in a CHMOD command to lock/unlock it (which may not work on all servers, since I don't know if you can run as a different user...).

Pear shouldn't be writable at all. The only reason (as far as I understand and please correct me if I'm wrong) for the Pear/tmp dir to writable is PayPal IPN.

The Pear directory doesn't worry me because it can be written to (although if there are cases where it can be, then it would). I think we should move all of the folders with executable scripts into the admin directory so that there's no chance they could be exploited. That means classes, extra, includes, language, modules, pear, and skins.

Here's the type of hack that I'm trying to deter by doing so:

Let's say that an exploit is discovered with one of these scripts (CubeCart or other) that allows a hacker to include their own code on a remote server. To do this they load the script in a browser and pass a variable in the query string. This is not totally academic, since something like this happened here only a few months ago...

If these scripts are password-protected (prferably by Apache), then there's no way to use this exploit. Many exploits count on being able to grab an include file and use it in a way that wasn't anticipated by the programmers. Why have these in public directories when PHP can include them from inside a protected one?

The same is true for other types of exploits. If the only handle that a hacker can get on your scripts is via your main PHP files (index, cart, etc.) then you can focus on keeping those secure and not have to worry that there are 1000 potential back doors. And if all those scripts are in one main directory (admin) then you can lock them down as a group and know that they're all secure.

I'm not a developer, but I think that this is not generally done because of the existence of Windows servers. Since developers want to make sure that their products work on those, they tend to create their own user authentication systems for the admin scripts and whatnot so that they will work on any server. And granted they can also do other things (like integrate with an audit trail script, etc.).

But none of those systems ever seems to be as secure and foolproof as good ol' Apache .htaccess. It's much more difficult to script something over top of the server processes that will cover all possible exploits. An authentication system based on PHP/mySQL will never be as secure as Apache.

So I guess I would advocate making it easier to use both for those of us who can. That would basically just mean moving all script directories inside the admin folder and fixing the paths. If everything works this way then I for one would feel like CubeCart was a lot more secure then its competitors.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...