|
Date: Tue, 11 Nov 1997 14:32:15 -0500 From: Megan Alexander <malexander@COMMANDCOM.COM> To: BUGTRAQ@NETSPACE.ORG Subject: Re: Major security flaw in Cybercash 2.1.2 This is also an issue with Verifone vPOS, which ships with the Microsoft Site Server, partnered as an evaluation version. Most of these credit card validators have the ability to store items to a logfile, which is often turned on in debugging and testing and never turned off by the administrator... Here are some other interesting things about vPOS and Site Server, for the e-commerce-minded among us: 1. In addition to the debug log mentioned above, the actual Commerce Server store also has the ability to write a very lengthy logfile, called ordinitbf, which can be added into the global.asa of the store, and called using a scriptor component. Again, not very useful unless an administrator turns on logging and never turns it off. Things included in this file include: all shopper info, all address info (billing and shipping), credit card info, including name, exp, and number... you get the idea. 2. the vPOS service cannot be started automatically. The encryption string MUST be typed in at start-up. This sequence cannot be automated. Therefore, if a server using vPOS is somehow compromised in the middle of the night, and no administrator is there to restart the service, all transactions will fail until the next time the administrator restarts the service. 3. In order for vPOS to work with Microsoft Site Server (Commerce Server 2.0), the Commerce Server version 1.0 component wrapper must be used. In order to trick the v1 component wrapper into thinking that Site Server is really Merchant Server 1.0, A LOT of registry entries must be made. Some of these registry entries include the SQL passwords, the NT administrator login passwords, etc. Fun for the whole family, and everything in plaintext. 4. The merchant certificates are stored in the SQL database whose passwords you just typed in plaintext into the registry. Sigh. -megan Megan Alexander: Webmaster, etc. Command Software Systems (561)575.3200 x 170 http://www.commandcom.com -----Original Message----- From: Tim Scanlon [SMTP:tfs@CHARM.SEALSOFT.COM] Sent: Saturday, November 08, 1997 12:35 AM To: BUGTRAQ@NETSPACE.ORG Subject: Re: Major security flaw i ffb n Cybercash 2.1.2 On Fri, 7 Nov 1997 , Anonymous said: >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. > ln -s Debug.log /dev/null Works easier than deleting over and over I'd hazard. Tim --- ________________________________________________________________ tfs@sealsoft.com (NeXTmail, MIME) Tim Scanlon tfs@epic.org (PGP key by req) crypto is good Seal Technologies Inc. I own my own words Date: Sun, 23 Nov 1997 04:08:28 -0500 From: Pat Farrell To: BUGTRAQ@NETSPACE.ORG Subject: CyberCash response to: Major security flaw in Cybercash 2.1.2 This message is going to bugtraq because I first heard of the report from this list. I believe it is in the spirit of the list's usage guidelines. Redistributed in accordance to the terms below. Other responses should be off list, directly to me. Pat -----BEGIN PGP SIGNED MESSAGE----- I have been asked by Steve Crocker, CyberCash's Chief Technical Officer, to post this message concerning security of CyberCash's software. The following should appear in its entirety if it's printed at all. Permission is granted to repost this message as long as the entire message is reposted unaltered with the PGP signature intact. Pat The following message appeared on the net. > === begin quoted message === > >From: Anonymous >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. > > === end quoted message === 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 a61 . 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 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNHfwF7CsmOInW9opAQHurAP+MPve2kBqh7Vtt6cMbzohCt2PTjaa6dl3 AzxTVPzgMPdGLB+pehGNxsxrlb/hQ07P3IqMaKcaKXs9O+7Av7ijaUGGkbWpbhEJ Zy38iKpEsMIHe2vrLXyyjVbzorj/8f/OHEr28NbXjviSllyJlGzowgS0AXuFMLMt lByJBsTAAS4= =ZlLs -----END PGP SIGNATURE----- Pat Farrell CyberCash, Inc. w:(703) 715-7834 Senior Engineer pfarrell@cybercash.com #include standard.disclaimer