December 2003 - cypherpunks-legacy

<fwd> FV's crypted credit card "attack"
by vin＠shore.net 17 Dec '03

17 Dec '03

Date: Mon, 29 Jan 1996 15:43:53 -0500 Subject: IP: FV's position on Merc article Date: Mon, 29 Jan 1996 10:44:26 -0500 (EST) From: Nathaniel Borenstein <nsb(a)nsb.fv.com> ================ As you may already have heard via the popular press, First Virtual Holdings has developed and demonstrated a program which completely undermines the security of every known credit-card encryption mechanism for Internet commerce. This is a very serious matter, and we want to make sure that the Internet community is properly informed about the nature of the problem that we have uncovered, and the manner in which we have made the information known. In this (unavoidably lengthy) post, I will try to explain the nature of the problem and its implications for Internet commerce. In deference to those who are not technically oriented, the detailed explanation of how the attack works will be the LAST part of this message. First of all, let me be perfectly clear about the nature of the problem we have exposed. It is NOT a bug in a single program, and it is therefore NOT something that can be fixed with a "patch" or any other kind of software upgrade. Instead, we have demonstrated a very general attack that undermines ALL programs that ask users to type a credit card number into their home computer. We have tested the program and confirmed that it undermines the security of the credit card encryption software from Netscape and Cybercash, and we expect that it will work similarly for ANY future software based on the encryption of credit card numbers on the desktop. Quite simply, we believe that this program demonstrates a FATAL flaw in one whole approach to Internet commerce, and that the use of software to encrypt credit card numbers can NEVER be made safe. For consumers, we recommend the following simple rule: NEVER TYPE YOUR CREDIT CARD NUMBER INTO A COMPUTER. We should also be clear about the Internet commerce mechanisms that are NOT affected by this problem. First Virtual is unaffected because we never ask the user to put a credit card number at risk by typing it into a computer. Hardware-based solutions can also be devised that are immune to this attack, including solutions based on smart cards and solutions based on "card swipe" machines in the home. We believe that current digital cash solutions are also not vulnerable to this attack, although some variants of digital cash may be vulnerable to a similar form of attack. Commerce mechanisms based on the use of telephones or fax machines to transmit credit card numbers are also unaffected by this kind of attack. Other proposed commerce mechanisms should, from now on, be evaluated with this kind of attack in mind. The bottom line: INTERNET COMMERCE CAN BE VERY SAFE, WITH SEVERAL DIFFERENT MECHANISMS, BUT ENCRYPTING CREDIT CARDS ON THE DESKTOP IS NOT ONE OF THE SAFE MECHANISMS. It's important to understand why we have taken this step. Obviously, as the long-time leaders in Internet commerce, the last thing we would want to do is to undermine general confidence in Internet commerce. However, we realized that many people believed that credit card encryption was a safe and easy path to Internet commerce, and that very few people understood how easily it could be undermined. Upon investigation, we were frankly startled to realize just how easy it was -- a single programmer got the first version of our program running in about a week. Aside from our obvious interest in promoting our own commerce mechanism, we felt that we had an ethical obligation to bring this problem to the attention of the consumers, banks, and other financial institutions who could conceivably suffer catastrophic losses if software encryption of credit card numbers became widespread. We also realize that we have an obligation to do everything possible to avoid helping any unscrupulous people who might seek to utilize this flaw for malicious purposes. We have accordingly been extremely responsible in how we have handled our discovery. We first demonstrated and explained our program to vital organizations such as CERT (the Computer Emergency Response Team) and the ABA (American Banking Association). Only after many such private disclosures, none of which revealed any defense against our technique, did we publicly disclose the existence of this program. In addition, we have taken several steps to "cripple" our demonstration program, all of which will be discussed below. Furthermore, we have NOT made the program itself generally available. We are currently demonstrating it to selected financial institutions and government agencies, and will provide copies of the program only to CERT and a few other independent security-minded organizations. We have also alerted Netscape to the problem as part of their "bugs bounty" program. At some future date, we might conceivably distribute the program, in binary form on CD ROM, to selected financial institutions. The source code will always be very closely guarded. Unfortunately, however, the general method of attack is extremely easy to duplicate, and we don't know of any good way to alert the public to the problem without explaining it. THE TECHNIQUE Our basic approach was to write a computer program that runs undetected while it monitors your computer system. A sophisticated version of such a program can intercept and analyze every keystroke, mouse-click, and even messages sent to your screen, but all we needed was the keystrokes. Selectively intercepted information can be immediately and secretly transmitted via Internet protocols, or stored for later use. First Virtual's research team has built and demonstrated a particular implementation of such a program, which only watches for credit card numbers. Whenever you type a credit card number into your computer -- even if you are talking to "secure" encryption software -- it captures your card number. Our program doesn't do anything harmful with your credit card number, but merely announces that it has captured it. A malicious program of this type could quietly transmit your credit card number to criminals without your knowledge. The underlying problem is that the desktop -- the consumer's computer -- is not secure. There is no way of ensuring that all software installed on the consumer's machine can be trusted. Given this fact, it is unwise to trust ANY software such as a "secure" browser, because malicious software could have easily been interposed between the user and the trusted software. The bottom line for consumers is that, on personal computers, INFORMATION IS INSECURE THE MOMENT YOU TOUCH A KEY. We have dramatically proven that security ends the moment you type sensitive information into your computer. The vulnerability lies in the fact that information must travel from your keyboard, into your computer's operating system, and then to your "secure" application. It can be easily intercepted along the way. This kind of insecurity is very frightening, and has implications far beyond credit card theft. However, credit cards embody and demonstrate the kind of information that is MOST vulnerable to this kind of attack. Credit card numbers are far more vulnerable to this kind of attack than most other forms of information because of the following particular characteristics of credit card numbers: -- Credit card numbers are easily recognized by simple pattern recognition. -- Credit card numbers are "one way" financial instruments, with no user-level confirmation or verification required for their use. -- Credit card numbers are of direct financial value. In short, credit card numbers are an almost perfect example of how NOT to design a payment instrument for an insecure public computer network such as the Internet. DETAILS: HOW TO TOTALLY UNDERMINE SOFTWARE ENCRYPTION OF CREDIT CARDS First Virtual's demonstration credit-card interception program, once installed, observes every keystroke that you type, watching for credit card numbers. It recognizes credit card numbers with almost perfect accuracy, because credit card numbers are specifically designed to match a simple, self-identifying pattern, including a check digit. Our program is even smart about punctuation and simple editing functions, so that nearly any credit card number that you type into your computer is immediately recognized as such by this program. When our program spots a credit card number, it immediately plays a warning sound and pops up a window on your screen, including an iconic representation of the type of credit card that you have just entered, along with a clear explanation of what has just happened. The current program works only on Microsoft Windows (Windows 3.1, Windows NT, and Windows 95), but we believe that it would be simple to implement on Macintosh and UNIX systems as well. The program doesn't exploit any "holes" or bugs in the operating system. It uses existing, necessary operating system facilities which are part of the published Windows API, and which are necessary for the implementation of screen savers, keyboard macros, and other important software packages. First Virtual's intent is to educate the public, certainly not to endanger it. For that reason, our program incorporates four important precautions intended to prevent any possibility of harm: 1) Our program is not self-replicating. While a malicious program exploiting the same security flaw could easily be embedded in a virus, spreading itself all over the world, that was not our goal. Instead, the program must be deliberately and manually installed on each computer on which it is to run. 2) Our program always puts up an icon on your screen when it is watching your keystrokes. This is certainly not necessary, and it is clear that a malicious program would be unlikely to do this. 3) Our program is easy to remove from your computer, and even offers an "Uninstall" button to the user. Obviously a malicious program would hide itself as well as possible, and make itself as hard to remove as possible. 4) Our program never transmits your credit card over the Internet. While a program using this approach could transmit your information to a criminal in a totally untraceable manner, we would never do anything like that. In fact, we erase your credit card number from our program's memory before we even tell you that we've seen it, thus making sure that the credit card number can't even be retrieved by an inspection of our program's memory. It is frankly difficult to overstate the severity of the problem demonstrated by our program. A clever criminal could use viral techniques to spread a malicious program based on the same approach, and would be no more likely to be caught in the act than the authors of any of the computer viruses that plague the world today. Once it detects a credit card number, a criminal program could use any of several techniques to send that number to the original criminal without providing any way to trace the criminal's receipt of it. (If you're skeptical about this claim, we'd prefer to talk with you privately, as we've never seen the "best" methods for doing this spelled out in public, and we would prefer to keep it that way.) Altogether, this means that if millions of credit card numbers were being typed into Internet-connected personal computers, a criminal could obtain a virtually unlimited supply of card numbers for his own use. In fact, for all we know this could already be happening today. The first visible sign of such an attack, if it were well-executed, would be a gradual rise in the overall rate of credit card fraud. POSSIBLE SOLUTIONS First Virtual believes that the flaw we have uncovered is fatal. In the foreseeable future, all commerce schemes based on software encryption of credit cards on the desktop are completely vulnerable to this sort of attack. The basic problem is that software encryption of credit cards is predicated on the notion of "trusted software". On the consumer computing platforms, however, general purpose operating system functionality makes it unwise to assume too strong a level of trust in such software. No operating system with anything less than military-grade security (B2) is likely to be safe from an attack such as this one. This does not mean that Internet commerce is dead. Any scheme that is not based on self-identifying one-way financial instruments such as credit cards will be essentially unaffected by this problem. Moreover, even credit cards may be made safe on the Internet using one of two approaches: secure hardware add-ons and the First Virtual approach. First Virtual's Internet Payment Systems never places the consumer's credit card number on the Internet. Instead, the consumer provides it to us by telephone when the account is opened. After that, all purchases are made using a "Virtual PIN". Virtual PINs are essentially Internet aliases for underlying payment mechanisms such as credit card numbers, but with several kinds of added security. Virtual PINs are free-form text, with no recognizable pattern, which makes them much harder to detect with the kind of attack we have just demonstrated. Moreover, Virtual PINs are only usable in conjunction with First Virtual's unique email verification process. No payment is made until the consumer confirms an email query, which means that defrauding First Virtual is a multi-step process that is extremely difficult to automate. (For more details, we recommend our paper, "Perils and Pitfalls of Practical CyberCommerce", available via ftp from ftp://ftp.fv.com/pub/nsb/fv-austin.txt.) The bottom line, once again, for those of you who have read this far: NEVER TYPE YOUR CREDIT CARD NUMBER INTO A COMPUTER. There's simply no other way to keep credit cards safe on the net. The program we have demonstrated completely undermines the security of all known programs that claim to handle credit card numbers safely on the Internet. -------- Nathaniel Borenstein <nsb(a)fv.com> Chief Scientist, First Virtual Holdings FAQ & PGP key: nsb+faq(a)nsb.fv.com Vin McLellan +The Privacy Guild+ <vin(a)shore.net> 53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*>

1 0

Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards
by mka＠pobox.com 17 Dec '03

17 Dec '03

At 15.07 1996-01-29 -0500, Nathaniel Borenstein wrote: >NEVER TYPE YOUR CREDIT CARD NUMBER INTO A COMPUTER. This problem is greatly exagerated. The software simply won't be running in the average users machine. If the program propagates like a virus, it will soon be catched and killed by the anti-virus utilities that any responsible user is already running on a regular basis. If you have to start the program for it to do its magic, then just don't start it. Todays computer users should know that running software you don't trust is generally a bad idea. That's how you get a virus in the machine in the first place... Come on Nathaniel, admit it, it's a scam to sell FV's expensive services! matts

2 1

Re: [Fwd: Netscape, CAs, and Verisign]
by Peter Williams 17 Dec '03

17 Dec '03

>I'd like to see a less centralized CA that's tied into the existing system >of notaries. The idea is to make it necessary to spoof a notary in order >to spoof the CA. That won't make spoofing the CA impossible (nothing >will), but it will make spoofing the CA illegal. You might wish to look at the Apple DigiSign design. RSA DSI ran a CA under contract as a notary enrollment system for 2 years. The people from RSA DSI, now at Verisign, have a certain amount of experience with this system. I dont understand how you intend to make CA spoofing illegal. Who who perform the enforcement? (By illegal, I assume you mean that there is a criminal offence involved, rather than a tort.) > >A notary could apply to the CA for the right to work as an agent, for a >nominal fee (<$100/year). Only notaries could be agents. If a person >wants a certificate, they'd come in and present ID and a key to the >notary/agent. The person would have to present a form document stating >that he's requesting the cert. The notary would stamp the form and affix >a signature to the key which would enable it to be processed automatically >by the CA. This has been tried, and many certificates issued under a variant of this scheme. it seems likely that only an ABA-certified notary would be reasonaby secure from professional liabilities. Good efforts have been made to qualify what the professional procedures would be. > >Fees for the whole procedure ought to be less than $30. The CA ought to >operate off of the fees from the agents as a non-profit organization, and >the agents ought to keep the fees paid by the people requesting the >certificates. Notary fees might be best controlled by the notary, not the CA. Seems an unreasonable restriction of trade to price-fix, even at the low-end. > >Would any of the lawyers on the list be willing to comment on whether or >not it's possible or practical to tie a CA into the notary system? Does >anyone have any thoughts as to how difficult/risky spoofing my CA is >compared to spoofing Netscape or Verisign? There is indeed a large body of legal ramifications in this area. The best way to learn about it is to become a CA and do it. Risk taking is part of being in the CA business, however you operate it, even for free. > >I could put up a server and I think I know a laywer who would help me set >up a non-profit organiation on a shoestring, but I don't want to do it if >the plan is impractical. Running as a not-for-profit may not prevent general liability. You can give the service away for free and will still be liable for the mis-representations you or your agents make. There are DARPA reports written about the issue (though these do not usually constitute advice.) > >Morevover, although I don't think it's reasonable to expect Netscape to >agree to include a non-existent CA in their browsers sight unseen, at the >same time it doesn't seem smart to sink money into setting up the CA >without some indication from Netscape that they're willing to give the >idea good faith consideration. Navigator betas seem to already facilitate users configuring their own trust points in a manner rather similar to adding a key to your personal PGP keyring. IBM browsers allow formal configuration of trust points. CAs as a business and economic growth area are just happening. We have two declared companies; Verisign and GTE. I personally expect another 10-20 to declare soon. The large (phone company) networks seem to be where the current action is, followed by the large accounting firms. As a small software company, I personally back the other similarly small software companies making and selling organizational CA systems to help people manage their own community of interest as they see fit.

1 0

Re: FV's Borenstein discovers keystroke capture programs! (pictures at 11!)
by droelke＠rdxsunhost.aud.alcatel.com 17 Dec '03

17 Dec '03

> > 2. It has nothing to do with viruses. No current virus protection > program will ever detect this thing, and if you write a program that > detects one instantiation of the attack, the program can be easily > changed to require a new "detector" program. This means you can only > protect against the last attack, not the next one. It has *everything* to do with viruses. Your program is not a virus BUT the press release tells the "danger" of trusting your own computer. If your own computer is doing something other than what the software on it is advertised as doing you have a virus, or trojan horse like a dirty-picture-viewer-with-keyboard-capture. Virus's and trojan horses are nothing new. The detector programs keep up with them quite nicely and make a good buck doing it. As for the technical content of the program - I'ld hack up a DOS version tonight if I thought it was worth my effort to drag the PC compiler/assembler out of mothballs. (I don't do MS-Windows). A weeks time is more that enough for any technically competent programmer to do the capture and add in the Windoze bells and whistles. I find that FV's hype on this is nothing but a thin disguise for a selling of their product. Come-on guys. Sell your product, not FUD. Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

1 0

Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards
by Tatu Ylonen 17 Dec '03

17 Dec '03

I find this kind of marketing extremely inappropriate. PLEASE STOP IT. The "flaw" you describe is quite obvious. The key issue is whether untrusted code gets executed on your computer, and what your risk model is. When balancing the probable damage due to this risk against the benefits of easily obtained software (from sources one chooses to trust) and easy electronic commerce, at least I find that this "flaw" is no cause for special alarm. The risk is analogous to that posed by computer viruses. I detest people causing public hysteria to advance their private commercial goals. Tatu Ylonen <ylo(a)cs.hut.fi> ------- start of forwarded message (RFC 934 encapsulation) ------- Received: from relay3.UU.NET by hutcs.cs.hut.fi with SMTP id AA23837 (5.65c8/HUTCS-S 1.4 for <ylo(a)cs.hut.fi>); Mon, 29 Jan 1996 22:29:47 +0200 Received: from toad.com by relay3.UU.NET with SMTP id QQaaqq05894; Mon, 29 Jan 1996 15:11:37 -0500 (EST) Received: by toad.com id AA21824; Mon, 29 Jan 96 12:07:29 PST Received: from zloty.fv.com by toad.com id AA21818; Mon, 29 Jan 96 12:07:22 PST Received: from nsb.fv.com (nsb.fv.com [152.160.80.42]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id MAA00050 for <cypherpunks(a)toad.com>; Mon, 29 Jan 1996 12:07:38 -0800 (PST) Received: by nsb.fv.com (4.1/SMI-4.1) id AA20803; Mon, 29 Jan 96 15:07:47 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.nsb.fv.com.sun4.41 via MS.5.6.nsb.fv.com.sun4_41; Mon, 29 Jan 1996 15:07:46 -0500 (EST) Message-Id: <Al3GYGSMc50eQWYAdR(a)nsb.fv.com> Precedence: bulk From: Nathaniel Borenstein <nsb(a)nsb.fv.com> Sender: owner-cypherpunks(a)toad.com To: cypherpunks(a)toad.com Subject: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards Date: Mon, 29 Jan 1996 15:07:46 -0500 (EST) [My apologies in advance if you see several copies of this message. I am posting this fairly widely due to the severity and importance of the problem described.] As you may already have heard via the popular press, First Virtual Holdings has developed and demonstrated a program which completely undermines the security of every known credit-card encryption mechanism for Internet commerce. This is a very serious matter, and we want to make sure that the Internet community is properly informed about the nature of the problem that we have uncovered, and the manner in which we have made the information known. In this (unavoidably lengthy) post, I will try to explain the nature of the problem and its implications for Internet commerce. In deference to those who are not technically oriented, the detailed explanation of how the attack works will be the LAST part of this message. First of all, let me be perfectly clear about the nature of the problem we have exposed. It is NOT a bug in a single program, and it is therefore NOT something that can be fixed with a "patch" or any other kind of software upgrade. Instead, we have demonstrated a very general attack that undermines ALL programs that ask users to type a credit card number into their home computer. We have tested the program and confirmed that it undermines the security of the credit card encryption software from Netscape and Cybercash, and we expect that it will work similarly for ANY future software based on the encryption of credit card numbers on the desktop. Quite simply, we believe that this program demonstrates a FATAL flaw in one whole approach to Internet commerce, and that the use of software to encrypt credit card numbers can NEVER be made safe. For consumers, we recommend the following simple rule: NEVER TYPE YOUR CREDIT CARD NUMBER INTO A COMPUTER. We should also be clear about the Internet commerce mechanisms that are NOT affected by this problem. First Virtual is unaffected because we never ask the user to put a credit card number at risk by typing it into a computer. Hardware-based solutions can also be devised that are immune to this attack, including solutions based on smart cards and solutions based on "card swipe" machines in the home. We believe that current digital cash solutions are also not vulnerable to this attack, although some variants of digital cash may be vulnerable to a similar form of attack. Commerce mechanisms based on the use of telephones or fax machines to transmit credit card numbers are also unaffected by this kind of attack. Other proposed commerce mechanisms should, from now on, be evaluated with this kind of attack in mind. The bottom line: INTERNET COMMERCE CAN BE VERY SAFE, WITH SEVERAL DIFFERENT MECHANISMS, BUT ENCRYPTING CREDIT CARDS ON THE DESKTOP IS NOT ONE OF THE SAFE MECHANISMS. It's important to understand why we have taken this step. Obviously, as the long-time leaders in Internet commerce, the last thing we would want to do is to undermine general confidence in Internet commerce. However, we realized that many people believed that credit card encryption was a safe and easy path to Internet commerce, and that very few people understood how easily it could be undermined. Upon investigation, we were frankly startled to realize just how easy it was -- a single programmer got the first version of our program running in about a week. Aside from our obvious interest in promoting our own commerce mechanism, we felt that we had an ethical obligation to bring this problem to the attention of the consumers, banks, and other financial institutions who could conceivably suffer catastrophic losses if software encryption of credit card numbers became widespread. We also realize that we have an obligation to do everything possible to avoid helping any unscrupulous people who might seek to utilize this flaw for malicious purposes. We have accordingly been extremely responsible in how we have handled our discovery. We first demonstrated and explained our program to vital organizations such as CERT (the Computer Emergency Response Team) and the ABA (American Banking Association). Only after many such private disclosures, none of which revealed any defense against our technique, did we publicly disclose the existence of this program. In addition, we have taken several steps to "cripple" our demonstration program, all of which will be discussed below. Furthermore, we have NOT made the program itself generally available. We are currently demonstrating it to selected financial institutions and government agencies, and will provide copies of the program only to CERT and a few other independent security-minded organizations. We have also alerted Netscape to the problem as part of their "bugs bounty" program. At some future date, we might conceivably distribute the program, in binary form on CD ROM, to selected financial institutions. The source code will always be very closely guarded. Unfortunately, however, the general method of attack is extremely easy to duplicate, and we don't know of any good way to alert the public to the problem without explaining it. THE TECHNIQUE Our basic approach was to write a computer program that runs undetected while it monitors your computer system. A sophisticated version of such a program can intercept and analyze every keystroke, mouse-click, and even messages sent to your screen, but all we needed was the keystrokes. Selectively intercepted information can be immediately and secretly transmitted via Internet protocols, or stored for later use. First Virtual's research team has built and demonstrated a particular implementation of such a program, which only watches for credit card numbers. Whenever you type a credit card number into your computer -- even if you are talking to "secure" encryption software -- it captures your card number. Our program doesn't do anything harmful with your credit card number, but merely announces that it has captured it. A malicious program of this type could quietly transmit your credit card number to criminals without your knowledge. The underlying problem is that the desktop -- the consumer's computer -- is not secure. There is no way of ensuring that all software installed on the consumer's machine can be trusted. Given this fact, it is unwise to trust ANY software such as a "secure" browser, because malicious software could have easily been interposed between the user and the trusted software. The bottom line for consumers is that, on personal computers, INFORMATION IS INSECURE THE MOMENT YOU TOUCH A KEY. We have dramatically proven that security ends the moment you type sensitive information into your computer. The vulnerability lies in the fact that information must travel from your keyboard, into your computer's operating system, and then to your "secure" application. It can be easily intercepted along the way. This kind of insecurity is very frightening, and has implications far beyond credit card theft. However, credit cards embody and demonstrate the kind of information that is MOST vulnerable to this kind of attack. Credit card numbers are far more vulnerable to this kind of attack than most other forms of information because of the following particular characteristics of credit card numbers: - -- Credit card numbers are easily recognized by simple pattern recognition. - -- Credit card numbers are "one way" financial instruments, with no user-level confirmation or verification required for their use. - -- Credit card numbers are of direct financial value. In short, credit card numbers are an almost perfect example of how NOT to design a payment instrument for an insecure public computer network such as the Internet. DETAILS: HOW TO TOTALLY UNDERMINE SOFTWARE ENCRYPTION OF CREDIT CARDS First Virtual's demonstration credit-card interception program, once installed, observes every keystroke that you type, watching for credit card numbers. It recognizes credit card numbers with almost perfect accuracy, because credit card numbers are specifically designed to match a simple, self-identifying pattern, including a check digit. Our program is even smart about punctuation and simple editing functions, so that nearly any credit card number that you type into your computer is immediately recognized as such by this program. When our program spots a credit card number, it immediately plays a warning sound and pops up a window on your screen, including an iconic representation of the type of credit card that you have just entered, along with a clear explanation of what has just happened. The current program works only on Microsoft Windows (Windows 3.1, Windows NT, and Windows 95), but we believe that it would be simple to implement on Macintosh and UNIX systems as well. The program doesn't exploit any "holes" or bugs in the operating system. It uses existing, necessary operating system facilities which are part of the published Windows API, and which are necessary for the implementation of screen savers, keyboard macros, and other important software packages. First Virtual's intent is to educate the public, certainly not to endanger it. For that reason, our program incorporates four important precautions intended to prevent any possibility of harm: 1) Our program is not self-replicating. While a malicious program exploiting the same security flaw could easily be embedded in a virus, spreading itself all over the world, that was not our goal. Instead, the program must be deliberately and manually installed on each computer on which it is to run. 2) Our program always puts up an icon on your screen when it is watching your keystrokes. This is certainly not necessary, and it is clear that a malicious program would be unlikely to do this. 3) Our program is easy to remove from your computer, and even offers an "Uninstall" button to the user. Obviously a malicious program would hide itself as well as possible, and make itself as hard to remove as possible. 4) Our program never transmits your credit card over the Internet. While a program using this approach could transmit your information to a criminal in a totally untraceable manner, we would never do anything like that. In fact, we erase your credit card number from our program's memory before we even tell you that we've seen it, thus making sure that the credit card number can't even be retrieved by an inspection of our program's memory. It is frankly difficult to overstate the severity of the problem demonstrated by our program. A clever criminal could use viral techniques to spread a malicious program based on the same approach, and would be no more likely to be caught in the act than the authors of any of the computer viruses that plague the world today. Once it detects a credit card number, a criminal program could use any of several techniques to send that number to the original criminal without providing any way to trace the criminal's receipt of it. (If you're skeptical about this claim, we'd prefer to talk with you privately, as we've never seen the "best" methods for doing this spelled out in public, and we would prefer to keep it that way.) Altogether, this means that if millions of credit card numbers were being typed into Internet-connected personal computers, a criminal could obtain a virtually unlimited supply of card numbers for his own use. In fact, for all we know this could already be happening today. The first visible sign of such an attack, if it were well-executed, would be a gradual rise in the overall rate of credit card fraud. POSSIBLE SOLUTIONS First Virtual believes that the flaw we have uncovered is fatal. In the foreseeable future, all commerce schemes based on software encryption of credit cards on the desktop are completely vulnerable to this sort of attack. The basic problem is that software encryption of credit cards is predicated on the notion of "trusted software". On the consumer computing platforms, however, general purpose operating system functionality makes it unwise to assume too strong a level of trust in such software. No operating system with anything less than military-grade security (B2) is likely to be safe from an attack such as this one. This does not mean that Internet commerce is dead. Any scheme that is not based on self-identifying one-way financial instruments such as credit cards will be essentially unaffected by this problem. Moreover, even credit cards may be made safe on the Internet using one of two approaches: secure hardware add-ons and the First Virtual approach. First Virtual's Internet Payment Systems never places the consumer's credit card number on the Internet. Instead, the consumer provides it to us by telephone when the account is opened. After that, all purchases are made using a "Virtual PIN". Virtual PINs are essentially Internet aliases for underlying payment mechanisms such as credit card numbers, but with several kinds of added security. Virtual PINs are free-form text, with no recognizable pattern, which makes them much harder to detect with the kind of attack we have just demonstrated. Moreover, Virtual PINs are only usable in conjunction with First Virtual's unique email verification process. No payment is made until the consumer confirms an email query, which means that defrauding First Virtual is a multi-step process that is extremely difficult to automate. (For more details, we recommend our paper, "Perils and Pitfalls of Practical CyberCommerce", available via ftp from ftp://ftp.fv.com/pub/nsb/fv-austin.txt.) The bottom line, once again, for those of you who have read this far: NEVER TYPE YOUR CREDIT CARD NUMBER INTO A COMPUTER. There's simply no other way to keep credit cards safe on the net. The program we have demonstrated completely undermines the security of all known programs that claim to handle credit card numbers safely on the Internet. - -------- Nathaniel Borenstein <nsb(a)fv.com> Chief Scientist, First Virtual Holdings FAQ & PGP key: nsb+faq(a)nsb.fv.com ------- end -------

1 0

FL Demonstrates Fatal Flaw in Logins
by Paul E. Campbell 17 Dec '03

17 Dec '03

Okay..so I couldn't resist. This stuff is almost too good to be real. I've doctored up their propaganda a little to help make a better impact on the "average user". :) FL Demonstrates Fatal Flaw in Logins [My apologies in advance if you see several copies of this message. I am posting this fairly widely due to the severity and importance of the problem described.] As you may already have heard via the popular press, First Login Security Corporation has developed and demonstrated a program which completely undermines the security of every known login mechanism. This is a very serious matter because any person attending first year computer science courses can easily implement such a program. We want to make sure that the Internet community is properly informed about the nature of the problem that we have uncovered, and to buy our new sooper-dooper fingerprint sniffer addon device all workstations, vehicle entry systems, and personalized toaster settings. In this (unavoidably short) post, I will try to explain the nature of the problem and its implications for Internet commerce. In deference to those are are not as stupid as the ones to whom this propaganda is aimed, we will hide the explanation of how the attack works until the last part of this message. First of all, let me be perfectly clear about the nature of the problem we have exposed. It is NOT a bug in a single program, and it is therefore NOT something that can be fixed with a "patch" or any other kind of software upgrade. Instead, we have demonstrated a very general attack that undermines ALL programs that ask users to type in their username and password into their home computer. We have tested the program and confirmed that it undermines the security of the login software from Windows 95 and from SunOS, and we expect that it will work similarly for ANY future software based on passwords. Quite simply, we believe that this program demonstrates a FATAL flaw in one whole approach to Internet authentication, and that the use of software to enter passwords can NEVER be made safe. For normal users, we recommend the following simple rule: NEVER TYPE YOUR PASSWORD INTO A COMPUTER. We should also be clear about the Internet authentication mechanisms that are NOT affected by this problem. First Login is unaffected because we never ask the user to put their password at risk by typing it into a computer. Hardware-based solutions can also be devised that are immune to this attack, including solutions based on retinal scanners, smart cards, and fingerprint identification devices in the home. We believe that current zero-knowledge proofs are also not vulnerable to this attack, although some variants of zero-knowledge proofs may be vulnerable to a similar form of attack. Other mechanisms based on the use of cellular telephones or shared fax machines to transmit secret passwords are also unaffected by this kind of attack. Other proposed login mechanisms should, from now on, be evaluated with this kind of attack in mind. The bottom line: INTERNET AUTHENTICATION CAN BE VERY SAFE, WITH SEVERAL DIFFERENT MECHANISMS, BUT USING SIMPLE PASSWORDS IS NOT ONE OF THE SAFE MECHANISMS. It's important to understand why we have taken this step. Obviously, as the long-time leaders in Internet espionage, the last thing we would want to do is to undermine general confidence in Internet logins. However, we realized that many people believed that simply logging in was a safe and easy path to the internet superhighway, and that very few people understood how easily it could be undermined. Upon investigation, we were frankly startled to realize just how easy it was -- a single programmer got the first version of our login spoofing program running in about a week, shortly after he mastered the intricacies of the printf() function. Solutions to not echo the password to the screen took a year later before we discovered the ioctl() function. Aside from our obvious interest in promoting our own ridiculously overpriced product that has such a high failure rate that your company will probably drop kick it into the trash can, we felt that we had an ethical obligation to bring this problem to the attention of the consumers, banks, and other financial institutions who could conceivably suffer catastrophic losses when we are stealing their corporate secrets by espionage. In short, we have been in the business of spying for years and quite frankly, our guilty conscience started to get on us. So we took the time to warn users so we could feel better the next time we helped a large corporation totally rip the shirts off the back of a small business owner, since we warned you ahead of time before we stole everything. We also realize that we have an obligation to do everything possible to avoid helping any unscrupulous people who might seek to utilize this flaw for malicious purposes. Frankly, we're concerned that our competitors will have it as easy as we did in the future. We now have the money and reputation to afford sophisticated bribes and cat burglary tools, so we don't have as much use for login spoofing programs anymore that we once did. We also demonstrated login spoofing to such vital organizations as CERT, the review board of the New England Journal of Medicine, and the Association of Police Chiefs because nobody else would take us seriously. Only after many such private disclosures in which we preyed on the paranoia of the organizations involved did we dare publish the code directly on the internet in a public area of a hacker's convention ftp site. In addition, we have taken several steps to "cripple" our demonstration program, all of which will be discussed below. We wrote it in APL as an entry to the Obfuscated APL Code Contest, not realizing at the time that all APL code looks that way. We took out the echo suppressing ioctl() calls because they aren't supported in our version of APL anyway. And we stored the attempted logins in a memory array before the program exitted instead of a disk file so that the program can't be used by anyone who doesn't understand APL. The bottom line, once again, for those of you who have read this far: NEVER TYPE YOUR PASSWORD INTO A COMPUTER. The stupid ad for our new scam/product: The way our program works is really quite simple. First, all users fill out a 1000 question purity test and the results are entered into the program's database. Then after typing your user name, the program generates a quiz based on your purity score. It authenticates you from a highly accurate estimate of your purity score and a list of personal questions such as the name of your mother's ex-husband's first dog's color. As an added bonus, we also offer the Sneaker II, a clever employee evaluation tool which uses the answers on the purity test to determine the most likely fetishes and potential crimes of all the employees in your company. As an added bonus, Sneaker II will also give you 3 free megabytes of downloads from our own extensive smut database culled from corporate men that we have personally spied on during some of our highly sensitive personal affairs assignments. Natasha Boredstein <nb(a)fake.com> Chief Propagandist, First Login Security

1 0

Alleged-RC2 code posted to sci.crypt
by Raph Levien 17 Dec '03

17 Dec '03

I'm surprised I haven't seen a mention of this here. Path: agate!usenet.ins.cwru.edu!slider.bme.ri.ccf.org!kira.cc.uakron.edu!neoucom.edu!news.ysu.edu!news.ecn.uoknor.edu!news.eng.convex.com!hermes.oc.com!news.unt.edu!cs.utexas.edu!howland.reston.ans.net!news.nic.surfnet.nl!sun4nl!xs4all!utopia.hacktic.nl!not-for-mail From: anon-remailer(a)utopia.hacktic.nl (Anonymous) Newsgroups: sci.crypt Subject: RC2 source code Date: 29 Jan 1996 06:38:04 +0100 Organization: Hack-Tic International, Inc. Lines: 182 Sender: remailer(a)utopia.hacktic.nl Message-ID: <4ehmfs$6nq(a)utopia.hacktic.nl> NNTP-Posting-Host: utopia.hacktic.nl Comments: Hack-Tic may or may not approve of the content of this posting Comments: Please report misuse of this automated remailing service to Comments: <postmaster(a)utopia.hacktic.nl> /**********************************************************************\ * To commemorate the 1996 RSA Data Security Conference, the following * * code is released into the public domain by its author. Prost! * * * * This cipher uses 16-bit words and little-endian byte ordering. * * I wonder which processor it was optimized for? * * * * Thanks to CodeView, SoftIce, and D86 for helping bring this code to * * the public. * \**********************************************************************/ [potential trade secret and ITAR violation elided] So far, no confirmations, denials, or test vectors posted. If true, this removes my biggest objection to S/MIME (leaving all the nonbiggest objections in place, of course). Raph

1 0

Re: CONTEST: Name That Program! (no-brainer)
by jpb＠miamisci.org 17 Dec '03

17 Dec '03

At 1:29 PM 1/29/96, cjs wrote: >> As you may have read in my previous message, First Virtual has developed >> and demonstrated a program that completely undermines all known schemes >> for using software-encrypted credit cards on the Internet. More details >> are avialable at http://www.fv.com/ccdanger. >> >> That was the easy part. > >***ROFL*** > >This "pre-encryption" program is not a virus. It attaches to the >keyboard driver and captures keystrokes from the keyboard as they are >typed -- BEFORE they can be encrypted by the application encryption >software. First Virtual scientists note that credit a check-digit. A >greater danger is that passwords are also as easily captured. > >***ROFL*** Umm - that is not news, it's an old hacker trick originally used for scamming login/passwd pairs. I've seen this done as either a patch to the telcom program used in a public lab on campus (this was actually quite clever - it'd wait till you completed your login and then email the cracker your login/passwd while simultaneously keeping the information from appearing on screen. It even kept his email address encrypted so I had to use a debugger to find it) or as a TSR or Macintosh extension. 2048bit-Fingerprint: F8 A2 A5 15 56 42 9B 16 3F BD 57 0F 8A ED E3 21 No man's life, liberty or property are safe while the legislature is in session.

1 0

Re: FL Demonstrates Fatal Flaw in Logins
by br＠scndprsn.Eng.Sun.COM 17 Dec '03

17 Dec '03

A couple of posts have raised the issue of doing the FV keyboard-capture attack using Java. |However, I don't know much about Java, would it be possible to make such an |applet with Java? The only events a Java applet is privy to are those that are typed in an applet window (and only those it itself spawned). So if a user types their credit card number in an applet window, the applet could send the information back to its server (and to that server only). In theory, it is possible to make an applet which appears to be selling something, get people to visit the page it's on, convince these people to enter their credit card numbers, and send those back to the server of origin. Of course, once this happens, you always know what host the applet came from (unless the thief, in order to get a few credit card numbers, has hacked DNS so that it's harder to track it). That's the extent of the risk. -- Benjamin Renaud Java Products Group

2 1

(FYI) January 1996 IEEE Transactions on Software Engineering
by Michael Peponis 17 Dec '03

17 Dec '03

The latest issue of IEEE Transactions on Software Engineering, This issue contains the best papers of the IEEE symposium on securtiy and privacy 1994. There is a very good artical, Prudent Engineering Practice for Crytographic Protocols, which I think should be required reading for all those involved in the design and implementation of Secure protocols. Regards, Michael Peponis PGP Key Avalible form MIT Key Server,or via finger

1 0