official CyberCash response

--- begin forwarded text


X-Sender: cme@cybercash.com
Date: Tue, 25 Nov 1997 15:37:14 -0500
To: rah@shipwright.com
From: Carl Ellison <cme@cybercash.com>
Subject: official CyberCash response
Cc: cme@cybercash.com
Mime-Version: 1.0

If you know of any lists where the message appeared but the official
response didn't, you're welcome to post the following.

 - Carl

	--------------------------------------------

[The following should appear in its entirety if it's printed at all.]

The following message appeared on the net.

From: Anonymous <anon@ANON.EFGA.ORG>
Subject:      Major security flaw in Cybercash 2.1.2
To: BUGTRAQ@NETSPACE.ORG

CyberCash v. 2.1.2 has a major security flaw that causes all credit
card information processed by the server to be logged in a file with
world-readable permissions.  This security flaw exists in the default
CyberCash installation and configuration.

The flaw is a result of not being able to turn off debugging.  Setting
the "DEBUG" flag to "0" in the configuration files simply has no
effect on the operation of the server.

In CyberCash's server, when the "DEBUG" flag is on, the contents of
all credit card transactions are written to a log file (named
"Debug.log" by default).

The easiest workaround I've found is to simply delete the existing
Debug.log file.  In my experience with the Solaris release, the
CyberCash software does not create this file at start time when the
DEBUG flag is set to 0.

The inability to turn off debugging is noted on CyberCash's web site
under "Known Limitations".  The fact that credit card numbers are
stored in the clear, in a world readable file, is not.

We have taken this quite seriously and have put through a full release of
our software which will be available Monday 11/24 for three platforms and
others shortly thereafter. The flaw was in the debug logging function, not
in the protocols or core implementation.  Nonetheless, the effect was an
unnecessary exposure of potentially sensitive information, and it shouldn't
have gone out the door that way.  We're tightening our internal processes
to avoid this in the future.

That said, here's the actual exposure.  The credit card information that's
in the clear in the log comes from "merchant-initiated" transactions, which
means the merchant obtains the credit card number from somewhere -- phone,
mail, fax, SSL-protected Internet interaction, or unprotected Internet
interaction.  The merchant thus has the same info in the clear already.

If the card number was provided via a wallet, then the card number is
blinded at the consumer's end.  It is therefore not in the clear as it
passes through the merchant's machine and the reported exposure does not
apply..

In order for the unprotected log to pose a risk of exposure, someone has to
be able to gain access to the merchant's machine.  If the machine is well
protected, viz behind a firewall and/or carefully configured, presumably an
outsider won't be able to gain access.  And in terms of the *additional*
exposure the open log represents over existing risks, if the same
information is accessible in the clear elsewhere on the machine,
eliminating from the log or encrypting the log provides little or no real
protection.  We continue to advise merchants to take strong steps to
protect their machines.

To our knowledge, the exposure documented above has not resulted in the
actual loss of any customer data or other security incident.


----------------------------------
Steve Crocker                                   Desk:  +1 703 716 5214
CyberCash, Inc.                                 Main:  +1 703 620 4200
2100 Reston Parkway                             Fax:   +1 703 620 4215
Reston, VA 20191                                crocker@cybercash.com





--- end forwarded text



-----------------
Robert Hettinga (rah@shipwright.com), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
The e$ Home Page: http://www.shipwright.com/
Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>

Note that the following was posted without the indentation that was used to 
quote the anonymous posting.  I indicate it below with ":>".

At 07:38 PM 11/25/97 -0500, Robert Hettinga wrote:
>[The following should appear in its entirety if it's printed at all.]
>
>The following message appeared on the net.
>
:>From: Anonymous <anon@ANON.EFGA.ORG>
:>Subject:      Major security flaw in Cybercash 2.1.2
:>To: BUGTRAQ@NETSPACE.ORG
:>
:>CyberCash v. 2.1.2 has a major security flaw that causes all credit
:>card information processed by the server to be logged in a file with
:>world-readable permissions.  This security flaw exists in the default
:>CyberCash installation and configuration.
:>
:>The flaw is a result of not being able to turn off debugging.  Setting
:>the "DEBUG" flag to "0" in the configuration files simply has no
:>effect on the operation of the server.
:>
:>In CyberCash's server, when the "DEBUG" flag is on, the contents of
:>all credit card transactions are written to a log file (named
:>"Debug.log" by default).
:>
:>The easiest workaround I've found is to simply delete the existing
:>Debug.log file.  In my experience with the Solaris release, the
:>CyberCash software does not create this file at start time when the
:>DEBUG flag is set to 0.
:>
:>The inability to turn off debugging is noted on CyberCash's web site
:>under "Known Limitations".  The fact that credit card numbers are
:>stored in the clear, in a world readable file, is not.
>
>We have taken this quite seriously and have put through a full release of
>our software which will be available Monday 11/24 for three platforms and
>others shortly thereafter. The flaw was in the debug logging function, not
>in the protocols or core implementation.  Nonetheless, the effect was an
>unnecessary exposure of potentially sensitive information, and it shouldn't
>have gone out the door that way.  We're tightening our internal processes
>to avoid this in the future.
>
>That said, here's the actual exposure.  The credit card information that's
>in the clear in the log comes from "merchant-initiated" transactions, which
>means the merchant obtains the credit card number from somewhere -- phone,
>mail, fax, SSL-protected Internet interaction, or unprotected Internet
>interaction.  The merchant thus has the same info in the clear already.
>
>If the card number was provided via a wallet, then the card number is
>blinded at the consumer's end.  It is therefore not in the clear as it
>passes through the merchant's machine and the reported exposure does not
>apply..
>
>In order for the unprotected log to pose a risk of exposure, someone has to
>be able to gain access to the merchant's machine.  If the machine is well
>protected, viz behind a firewall and/or carefully configured, presumably an
>outsider won't be able to gain access.  And in terms of the *additional*
>exposure the open log represents over existing risks, if the same
>information is accessible in the clear elsewhere on the machine,
>eliminating from the log or encrypting the log provides little or no real
>protection.  We continue to advise merchants to take strong steps to
>protect their machines.
>
>To our knowledge, the exposure documented above has not resulted in the
>actual loss of any customer data or other security incident.
>
>
>----------------------------------
>Steve Crocker                                   Desk:  +1 703 716 5214
>CyberCash, Inc.                                 Main:  +1 703 620 4200
>2100 Reston Parkway                             Fax:   +1 703 620 4215
>Reston, VA 20191                                crocker@cybercash.com
>
>
>
>
>
>--- end forwarded text
>
>
>
>-----------------
>Robert Hettinga (rah@shipwright.com), Philodox
>e$, 44 Farquhar Street, Boston, MA 02131 USA
>"... however it may deserve respect for its usefulness and antiquity,
>[predicting the end of the world] has not been found agreeable to
>experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
>The e$ Home Page: http://www.shipwright.com/
>Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>
>
>
>
>For help on using this list (especially unsubscribing), send a message to
>"dcsb-request@ai.mit.edu" with one line of text: "help".
>
>

+------------------------------------------------------------------+
|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+