`Date: Mon, 19 Apr 1999 20:05:18 -0700 From: Joe To: BUGTRAQ@netspace.org Subject: Shopping Carts exposing CC data Tomorrow ( April 20 1999 ) CNet's news.com should be running a story regarding various commercial and freeware shopping carts that, when installed incorrectly or when installed by amateurs, result in the possible exposure of customer information... and not just a few digits of a credit card number like Yahoo's latest goof - everything is exposed. Name, CC Numbers, home address, phone number, what they ordered, how much they paid etc etc etc. These various shopping carts create world readable files in the web server's document tree which have subsequently been indexed by numerous search engines. (If a cold chill didn't just run down your spine, please, check your pulse) To access this order information you need a search engine and a little knowledge of how these various shopping carts are structured. Since some are freeware and the commercial carts have downloadable demos, this is trivial information to obtain. This email is a heads up to system administrators and hosts. These exposed order files were found by common search engine techniques and I suspect that after this story hits, those files are going to be even more vulnerable than they already are. If your users have 3rd party shopping carts installed on your servers, please run an audit on the files they generate and maintain. Any clear-text order information available to or stored in your web servers document tree should be immediately removed or have their access restricted. This is common sense to most of us here however, like most hosts, we don't always know what security nightmares our users have created for us and for themselves. I am hesitant to list the shopping carts that I've found to be exposing information, for fear of giving too much information to the wanna-be thieves out there. Please contact me directly if you want specifics. The list is very short, however, about 100 exposed installations of these carts have already been found and there are undoubtably hundreds more that I haven't found. Some of these sites are doing a great deal of business and some are doing none at all - but all of them are exposing order information. On one site alone was enough data to allow a thief to live like a king. (Until the FBI caught up with them that is :) A side note: Before anyone screams about us not contacting these CGI authors - Because of the sheer number of installations and the number of vendors involved, taking this to each one of them would have been prohibitive. We did have a conversation with one (fairly large) commercial vendor (who shall remain nameless) and if the response we got >from them was any indication, contacting the remaining vendors would have been futile. This particular vendor couldn't see the problem we had with the software that -they themselves- had installed on behalf of our mutual client. They couldn't understand why we told them to change their software or remove it from the server, even after a long and patient explanation of a little thing called 'liability'. Their tech told me last Wednesday that their engineer would contact us to address these issues - which as of this writing hasn't happened. (Not that I expected one - we had to explain "world readable" to their rep 3 times and I'm still not sure he really understood why this was such a Bad Idea (tm).) We also tried to get the various CC companies involved in this and to be blunt, they practically begged us to go away. This is fairly odd since they are the ones that take the financial hit if these data files are exposed. Visa Fraud's only recommendation to us was to "send a letter to the FTC and let them deal with it". Sorry, but red tape like that is best cut with the press, and they can get a much faster and more effective response from the various vendors than a modest sized ISP in Seattle can. My apologies for the late notice... and now for the standard disclaimer: Opinions expressed here are my own and not neccessarily that of my employer. Cheers. Joe. -- Joe H. Technical Support General Support: support@blarg.net Blarg! Online Services, Inc. Voice: 425/401-9821 or 888/66-BLARG http://www.blarg.net ------------------------------------------------------------------------------ Date: Tue, 20 Apr 1999 13:34:57 -0700 From: Joe To: BUGTRAQ@netspace.org Subject: Re: Shopping Carts exposing CC data My apologies for the canned response, but I'm getting an email request for specifics on this mess averaging 1 per minute - so I'll post this to the list. To answer many questions all at once: CNet has not posted the story yet. (This is a good thing) More time to minimize the damage... The larger ECommerce sites usually write their stuff in house. As such, places like Onsale.com, Amazon.com etc are not, to my knowledge, vulnerable in the least. The ones you need to concern yourself with are those that purchase 3rd party shopping systems and then install them incorrectly. From what I've been able to gather, it's the smaller mom-n-pop operations that are causing the most damage. If a cart is not listed here, it should not be considered vulnerable in the slightest. I myself have no problem doing business with Amazon, Onsale, SurplusAuction, UBid, Buy.com et al. This doesn't mean you shouldn't check your own installs though. It would perhaps be prudent for ECommerce sites to reveal their architecure and security scheme within their privacy statements. I for one would like to hear them all say "No un-encrypted data stored on servers - period." (This is our own policy) Hell, something as simple as a 1024b PGP scheme with off-net private keys would make me deliriously happy. Please don't ask me if your particular cart is "vulnerable". Check for yourself, since ALL of the carts listed below CAN be secured and are usually only exposing data when the end user fsks up the install. Simply check all files that contain customer data (order.log etc..) and see if it's available to a web browser. You should already have the path to it, so plug in the url to that file, if it comes up, you got problems. It should be noted that these are not "bugs" in the common vernacular, just improperly installed/maintained carts. Under NO circumstances should any of the carts listed below be blacklisted or considered unsafe. Quite the contrary. Many of the carts listed below provide PGP options that would completely eliminate this problem. Sadly, too few cart users are utilizing these options and instead are taking the path of least resistance. Here are the six shopping carts that, when installed contrary to their documentation or are improperly maintained can expose order information. All of the exposed information generated by these carts was discovered through a public search engine. Selena Sol's WebStore 1.0 http://www.extropia.com/ Platforms: Win32 / *Nix (Perl5) Executable: web_store.cgi Exposed Directory: Admin_files Exposed Order info: Admin_files/order.log Status: Commercial ($300)/ Demo available. Number of exposed installs found: 100+ PGP Option available?: Yes Order Form v1.2 http://www.io.com/~rga/scripts/cgiorder.html Platforms: Win32 / *Nix (Perl5) Executable: ? Exposed Directory: Varies, commonly "Orders" "order" "orders" etc.. Exposed Order Info: order_log_v12.dat (also order_log.dat) Status: Shareware ($15/$25 registration fee) Number of exposed installs found: 15+ PGP Option available?: Unknown. Seaside Enterprises EZMall 2000 http://www.ezmall2000.com/ Platforms: Win32 / *Nix (Perl5) Executable: mall2000.cgi Exposed Directory: mall_log_files Exposed Order Info: order.log Status: Commercial ($225.00+ options) Number of exposed installs found: 20+ PGP Option Available?: YES QuikStore http://www.quikstore.com/ Platforms: Win32 / *Nix (Perl5) Executable: quikstore.cgi Exposed Order info: quikstore.cfg* (see note) Status: Commercial ($175.00+ depending on options) Number of exposed installs found: 3 PGP Option Available?: Unknown. NOTE: This is, IMHO, one of the most dangerous of the lot, but thankfully, one of the lowest number of discovered exposures. Although the order information itself is secured behind an htaccess name/pwd pair, the config file is not. The config file is world readable, and contains the CLEAR TEXT of the ADMINS user id and password - rendering the entire shopping cart vulnerable to an intruder. QuikStore's "password protected Online Order Retrieval System" can be wide open to the world. (Armed with the name and pwd, the web visitor IS the administrator of the shopping cart, and can view orders, change settings and order information - the works.) PDGSoft's PDG Shopping Cart 1.5 http://www.pdgsoft.com/ Platforms: Win32 / *Nix (C/C++(?)) Executable: shopper.cgi Exposed Directory: PDG_Cart/ (may differ between installs) Exposed Order info: PDG_Cart/order.log Exposed Config info: PDG_Cart/shopper.conf (see note) Status: Commercial ($750+ options) Number of exposed installs found: 1+ (They installed it on our server) PGP Option Available?: Unknown. (Couldn't get a yes or no outta them) NOTE: if they renamed the order log, shopper.conf will tell you where it's at and what it was named - worse, shopper.conf exposes the clear text copy of Authnet_Login and Authnet_Password, which gives you full remote administrative access to the cart. shopper.conf, from what I can determine based on the company installed version we have here, is world readable and totally unsecured. And now a drum roll please: Mercantec's SoftCart http://www.mercantec.com/ Platform: Win32 (*Nix?) Executable: SoftCart.exe (version unknown) Exposed Directory: /orders and /pw Exposed Order Info: Files ending in "/orders/*.olf" Exposed Config Info: /pw/storemgr.pw (user ID and encrypted PW for store mgr?) Number of exposed installs: 1 PGP Option Available?: Unknown NOTES: This one has only been found vulnerable on ONE server. (user error?) The encryption scheme on the storemgr.pw password is unrecognized by me but I'm not an encryption guru. Someone's bound to recognize it. This is a scary one though - HiWay technologies is one of the largest domain hosts in the world, with over 120,000 domains. They are using SoftCart for clients that request ECommerce capabilities. The exposed install I found is hosted by HiWay. *shudder* Any and all opinions expressed here are solely those of the author and do not reflect the views, policies, practices or opinions of my employer. Joe. -- Joe H. Technical Support General Support: support@blarg.net Blarg! Online Services, Inc. Voice: 425/401-9821 or 888/66-BLARG http://www.blarg.net ------------------------------------------------------------------------------ Date: Wed, 21 Apr 1999 16:25:35 -0400 From: Richard Ford To: BUGTRAQ@netspace.org Subject: Re: "Shopping Carts exposing CC data" Joe said: > And now a drum roll please: > > Mercantec's SoftCart http://www.mercantec.com/ > Platform: Win32 (*Nix?) > Executable: SoftCart.exe (version unknown) > Exposed Directory: /orders and /pw > Exposed Order Info: Files ending in "/orders/*.olf" > Exposed Config Info: /pw/storemgr.pw > (user ID and encrypted PW for store mgr?) > > Number of exposed installs: 1 > PGP Option Available?: Unknown > NOTES: > > This one has only been found vulnerable on ONE server. (user error?) The > encryption scheme on the storemgr.pw password is unrecognized by me but > I'm not an encryption guru. Someone's bound to recognize it. > > This is a scary one though - HiWay technologies is one of the largest > domain hosts in the world, with over 120,000 domains. They are using > SoftCart for clients that request ECommerce capabilities. > > The exposed install I found is hosted by HiWay. > > *shudder* There's something about being so big that means that you can find almost anything on a Hiway system :-) In this case, though, the fire alarm is somewhat misplaced. In its usual setup, Mercantec pgp's all the .olf files, so there is no "plain text" CC information. Obviously, the user can not use pgp, and I have no doubt that that is exaclty what you found in the site(s) you looked at. One of the continual issues with being a Web Hosting entity is how much do you restrict what your users can do; should we *require* a user of ours to use a particular configuration of a product? It's a tough call. If a large number of our sites _had_ been vulnerable though, I wish you had given us a heads up first. FWIW, we've blocked all downloads from that directory via http/httpds, so now they won't get indexed or accessed... but as they should have been encrypted, that's not such quite so urgent. Either way, it should be completed shortly. Richard -- Dr. Richard Ford Mgr. of Engineering, Hiway Technologies, Inc. ------------------------------------------------------------------------------ Date: Sat, 24 Apr 1999 00:53:32 -0400 From: Earle Ake To: BUGTRAQ@netspace.org Subject: Just got probed for ezmall2000 shopping cart S/W It looks like someone is probing for ezmall2000 installed on the system! I just got a bunch of probes looking for logfiles 208.247.254.13 - - [23/Apr/1999:23:20:40 -0400] "GET /cgi-bin/ezmall2000/mall_log_files/order.log" 404 - 208.247.254.13 - - [23/Apr/1999:23:20:47 -0400] "GET /cgi/ezmall2000/mall_log_files/order.log" 404 4251 208.247.254.13 - - [23/Apr/1999:23:20:52 -0400] "GET /cgi-local/ezmall2000/mall_log_files/order.log" 404 4251 208.247.254.13 - - [23/Apr/1999:23:20:56 -0400] "GET /cgibin/ezmall2000/mall_log_files/order.log" 404 4251 208.247.254.13 - - [23/Apr/1999:23:20:59 -0400] "GET /unsecurecgi/ezmall2000/mall_log_files/order.log" 404 4251 208.247.254.13 - - [24/Apr/1999:00:17:21 -0400] "GET /cgi-bin/ezmall2000/mall_log_files/order.log" 404 - 208.247.254.13 - - [24/Apr/1999:00:17:23 -0400] "GET /cgi/ezmall2000/mall_log_files/order.log" 404 - 208.247.254.13 - - [24/Apr/1999:00:17:25 -0400] "GET /cgi-local/ezmall2000/mall_log_files/order.log" 404 - 208.247.254.13 - - [24/Apr/1999:00:17:26 -0400] "GET /cgibin/ezmall2000/mall_log_files/order.log" 404 - 208.247.254.13 - - [24/Apr/1999:00:17:27 -0400] "GET /unsecurecgi/ezmall2000/mall_log_files/order.log" 404 - 208.247.254.13 - - [24/Apr/1999:00:33:37 -0400] "GET /cgi-bin/ezmall2000/mall_log_files/order.log" 404 - 208.247.254.13 - - [24/Apr/1999:00:33:39 -0400] "GET /cgi/ezmall2000/mall_log_files/order.log" 404 4251 208.247.254.13 - - [24/Apr/1999:00:33:41 -0400] "GET /cgi-local/ezmall2000/mall_log_files/order.log" 404 4251 208.247.254.13 - - [24/Apr/1999:00:33:42 -0400] "GET /cgibin/ezmall2000/mall_log_files/order.log" 404 4251 208.247.254.13 - - [24/Apr/1999:00:33:44 -0400] "GET /unsecurecgi/ezmall2000/mall_log_files/order.log" 404 4251 -Earle -- Earle Ake Manager, Internet Services Earle.Ake@HCST.com Hassler Communication Systems Technology, Inc. http://www.hcst.net ------------------------------------------------------------------------------ Date: Tue, 27 Apr 1999 16:40:51 -0400 From: "Stout, Bill" To: BUGTRAQ@netspace.org Subject: Re: EC app security Well so much for that 'deafening silence' on EC app security. ;^) I count nine so far discovered vulnerable Catalogs. Selena Sol's WebStore 1.0 http://www.extropia.com/ Order Form v1.2 http://www.io.com/~rga/scripts/cgiorder.html Seaside Enterprises EZMall 2000 http://www.ezmall2000.com/ QuikStore http://www.quikstore.com/ PDGSoft's PDG Shopping Cart 1.5 http://www.pdgsoft.com/ Mercantec's SoftCart http://www.mercantec.com/ Perlshop http://www.perlshop.com/ Cybercash 2.1.4 - http://www.cybercash.com / Mountain Network Systems Inc. http://www.mountain-net.com / Bill Stout ---------- EC app security Stout, Bill (StoutB@PIONEER-STANDARD.COM) Mon, 19 Apr 1999 14:00:36 -0400 Has anyone done a security audit/analysis of Electronic Commerce software packages, such as catalog, database, and payment systems rolled into one? There seems to be a deafening silence on what seems to be the most vulnerable products. Most bug issues are at the 'bit level' (O.S., stack, or services) and not typically at the higher layer applications or workflow process. One experience; searching for database performance info one day, and pulling up the 'catalog administrator' page of one (political) commerce site. Had a hell of a time convincing the admin that that was a problem, without actually changing anything. Bill Stout ------------------------------------------------------------------------------ Date: Tue, 27 Apr 1999 21:57:31 +0000 From: Fred Bower To: BUGTRAQ@netspace.org Subject: Web Store EC App Security Analysis As a follow-on to the numerous reports of EC app security vulnerabilities, I thought that I would add my $.02. I did a (fairly) detailed analysis of WebStore ( http://www.extropia.com/scripts/web_store.html ) and have published my paper at http://www.cse.ogi.edu/~fredb/cse527paper.html for all to read. While WebStore has already been mentioned in a thread here, the detail given was limited. If you desire additional information, my report may be of interest. In addition to the unauthorized access to order information, I found potential denial of service or installation corruption issues that, while not as large a problem as publication of credit card numbers, are still significant problems in the product. fred Fred Bower Standard Disclaimers Apply fredb@cse.ogi.edu ------------------------------------------------------------------------------ ate: Wed, 28 Apr 1999 16:29:03 -0400 From: Suzanne Shine To: BUGTRAQ@netspace.org Subject: Re: EC app security I'm not sure about the others ECs, but our company had purchased EZMall 2000 from the vendor, and only a day or so after the first posting regarding security issues we had received an email regarding this posting, as well as a supposed patch from the vendor. I haven't had time to look at the patch; the site we use this for is a non-commerce site, and none of the logs are kept on the server, so there's no 'security' issues involved with our implementation. The manufacturer, however, was quite detailed with what needed to be done as far as securing a commerce site (basic permissions issues, not including patch). The patch contains two scripts which changes the following: 1. Encrypted username and password file. 2. Added a PIN (Personal ID Number) to the Admin Screen 3. Removed the admin username and password from the cfg file. 4. Renamed the password file so that it will not be able to be viewed by the general public. As I said, I haven't actually utilized the patch as of yet. The cart was more on our server for testing purposes, than anything else...there are no actual currency carts involved. What I find interesting, though, is the 'silence' from other vendors. Granted, I might have missed a posting or two, but in light of the ever-increasing number of SCs being implicated, I would have thought that I'd have noticed more. I've been lurking on the various commerce sites for a while, to see what kind of issues come up with their customers and haven't seen or heard anything regarding the security holes brought to light last week. But that could be just me. ===================================== Suzanne Shine V.Dot Net, Inc. Systems Administrator Voice: 516.234.5680 Fax: 516.348.1866 Email: suzanne@vdot.net ===================================== `

Query Builder