Date: Mon, 19 Apr 1999 20:05:18 -0700
From: Joe <joe@GONZO.BLARG.NET>
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 <joe@GONZO.BLARG.NET>
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 <rford@HWAY.NET>
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 <earle.ake@HCST.COM>
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" <StoutB@PIONEER-STANDARD.COM>
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/
<http://www.extropia.com/>
Order Form v1.2 http://www.io.com/~rga/scripts/cgiorder.html
<http://www.io.com/~rga/scripts/cgiorder.html>
Seaside Enterprises EZMall 2000 http://www.ezmall2000.com/
<http://www.ezmall2000.com/>
QuikStore http://www.quikstore.com/ <http://www.quikstore.com/>
PDGSoft's PDG Shopping Cart 1.5 http://www.pdgsoft.com/
<http://www.pdgsoft.com/>
Mercantec's SoftCart http://www.mercantec.com/ <http://www.mercantec.com/>
Perlshop http://www.perlshop.com/ <http://www.perlshop.com/>
Cybercash 2.1.4 - http://www.cybercash.com <http://www.cybercash.com> /
Mountain Network Systems Inc. http://www.mountain-net.com
<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 <fredb@CSE.OGI.EDU>
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 <suzanne@VDOT.NET>
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
=====================================