Re: FV's Borenstein discovers keystroke capture programs!

[Jeremy Mineweaser <Jeremym@area1s220.residence.gatech.edu>]

At 09:53 AM 1/30/96 -0500, Nathaniel Borenstein wrote:

>As to how the credit card numbers are entered:  they are entered at
>account setup time via a telephone call.

Then why should an attacker even bother to infect users' machines
with your program?  There is a much better way.  Let me outline it
for you:

The keyboard sniffer can be modified to attach to the computer
which holds your customer database.  It simply watches for card
numbers (which is even more trivial than doing so on the client's
machine, as it's the only thing this machine does) and stores them.
Then, when the attacker calls in to set up an account, the keyboard
sniffer is alerted (by any of several methods, such as a specific,
probably invalid, credit card number) and replaces this value with
a card number that was previously captured.  In this manner the
attacker has obtained a valid FV account drawn on a valid credit
card number of a real FV customer.  This account can then be
used to purchase various goods and services.  And while it causes
a similar degree of damage as your previous scheme, it also
causes you to lose money in the process.  Since you are the
verifier (in the function of the bank) in this case, then you will
lose out in the event of fraud.  The credit card companies will
still receive their money, and guess who will pay it:  FV!

This method has several other benefits over your previous scheme.
Your scheme required infection of numerous computers;
this scheme requires infecting only one computer.  And while
one may be held liable for the infection of the database computer,
the person who opens the fake FV account cannot.  All s/he has
done is call you up and follow procedure.  Even if he were dumb
enough (as we know many criminals are) to give you his real
card number over the telephone, it would not show up in your
database.  He would be completely clean... no trace.
Furthermore, once the rogue program is in place, EVERY attack
succeeds.

As a corollary to this attack, the attacker could design his/her
trojan to watch for the creation of new accounts and replace
the intended FV_ID with another value created by a PRNG
seeded by a known value.  The attacker can then seed his/her
copy of the PRNG with the same value and conduct valid
(although fraudulent) transactions using the generated FV_IDs.
With this approach he does not even have to contact your
new accounts office via telephone; s/he simply implants the
trojan and begins making transactions.  This is similar to the
above attack with regard to payment liability.

---
   Jeremy Mineweaser     | GCS/E d->-- s:- a--- C++(+++)$ ULC++(++++)>$ P+>++$
 j.mineweaser@ieee.org   | L+>++ E-(---)  W++ N+  !o-- K+>++  w+(++++) O-  M--
                         | V-(--) PS+(--) PE++ Y++>$ PGP++>+++$ t+() 5 X+ R+()
    *ai*vr*vx*crypto*    | tv(+)  b++>+++ DI+(++)  D+  G++ e>+++  h-() r-@ !y-