Vulnerability Development mailing list archives

e-commerce site security (was: Re: Solar Eclipse's Guide To Stealing 100000 Credit Cards in 21 Days)


From: sinster () BALLTECH NET (Jon Paul, Nollmann)
Date: Tue, 18 Jan 2000 11:24:36 -0800


Sprach kay <kay () PHREEDOM ORG>:
And perhaps this is not the biggest/onle danger! There are numerous
"e-commerce" sites on the Internet with surprisingly weak security that
just wait for someone to crack them.

Very true.  I've been contracted to implement a secure e-commerce site
by one of my clients, and I've discovered a number of very interesting
tidbits.

First off, very few e-commerce sites actually do their own credit card
processing.  Nearly all of them license a credit card processing
service from one of only a handful of such companies.  These companies
generally provide an executable client and/or a library against which
you can link your own programs.  That client/library actually makes
the requests to the credit card processor, who makes the billing
request of one of the "meatspace" credit card processing centers,
as would be appropriate for the specific type of credit card the
customer is using.

The choice of CC processing service provider makes more of an impact
on a site's security than anything else I've seen.  Some of these
providers have truly horrible security in their client/library, and
some have good security.  The best I've seen (and the provider I'm
licensing for my project) is Signio (www.signio.com), formerly known
as PaymentNet.  These guys ship a client and library that are based on
SSLeay, and use SSL-3 to communicate with Signio's servers.  Since the
server key can be hardwired to the client, that neatly avoids the
biggest problem with SSL-3.

Signio also, in their documentation, strongly urges that clients _not_
store actual credit card numbers anywhere, that they instead store
only the verification code returned by the transaction.  This code is
a limited-use credit card equivalent, to the extent that other than
queries (which don't return the credit card number), it only allows
you to void a transaction.

Also to their credit, Signio is good about allowing us licensees
evaluate their security.

[ Unfortunately, Signio has recently been bought by Verisign, so I
expect them to start doing The Wrong Thing. ]

This brings us to the second point: a tremendous number of sites out
there store not just the verification code, but also the actual credit
card numbers.  Often that's stored in domain-wide cookies on the
customer's machine, but more often they're stored in a log stored in a
database table.  And a disturbing number of those databases have, for
instance, the old scott/tiger account enabled, or sa/sa, or sa/<no
password>, or system/admin, or what have you.  Some have good
passwords, but the database device is a publicly readable file!
Sometimes, the database is even bound to an externally visible
interface!

For those sites that use a processing client (instead of a library),
the credit card number is nearly always a command-line argument, visible
with simple tools like ps.  So get SNMP access to the box, or (heaven
forbid) a login shell, and you can snarf whatever credit card numbers
you want without any special privileges.

--
Jon Paul Nollmann ne' Darren Senn                      sinster () balltech net
Unsolicited commercial email will be archived at $1/byte/day.
A lawyer has no business with the justice or injustice of the cause which
he undertakes....  The justice or injustice of the cause is to be decided
by the judge.                  Samuel Johnson, "Tour of the Hebrides", 1773



Current thread: