Hello All:
== Some Background ==
LinkPoint is the name of the API that Card Service International
(one of the biggest online merchant account providers) uses for
communication between a merchant's servers and their credit-card
gateway.
The LinkPoint client API communicates with the credit-card gateway
using an SSL-based protocol. Authentication and encryption is
facilitated with x509 digital certificates (the same ones that https
uses).
You must provide the client with two pieces of information for it to
authenticate to the gateway server. The first is what CSI calls
"Store Name" -- it's actually a six digit number. The second is the
path to the certificate file they send you.
== The Problem ==
Although I have not discovered a technical (code) security problem, I
believe there is a serious procedural security problem in they way
CSI initially sets up accounts.
When you are approved for a CSI merchant account (or even when you
are approved for a test account), CSI sends you two emails. One of
the emails has the subject "Welcome to LinkPoint API" (the other is
unimportant). This email contains two pieces of information:
The gateway server's hostname
Your "Store Name" (the six digit number)
Plus, they attach your certificate AND _private key_ to the bottom of
the message. The idea is that you copy and paste the cert + private
key into a file for the client API to use when it connects.
I don't think I need to spell out the problem any further for everyone
on this list. Basically, they are sending all of the information you
need authenticate as a merchant through plain, unencrypted, email.
You would need a few more things to exploit this potential security
hole. Namely, you would need the CSI API and some knowledge of how
to use it. This appears to be an attempt at security through obscurity.
Also, you would obviously need a way to get the plain email (sniffing, etc)
Notes: * The digital certificates do not have a passphrase.
* The LinkPoint API documentation is publicly available at:
http://www.cardservice.com/inetserv/lpapi.pdf
== Card Service's Response ==
My attempt to contact CSI lead to a phone call from the
"Lead Senior Tech" in the "API Support" department of CSI.
Since I did not type this email while I was on the phone, all of the
quoted comments bellow are from memory and probably aren't exact.
They are, however, pretty close to what was said.
I spoke with this person for about ten minutes and was not satisfied
with his response. This person's basic theme was "It's never happened
before and there are security precautions on the back-end".
I explained to him that using the information in their email, I could
pose as the merchant -- and after a while, he reluctantly agreed. I
then asked him to clarify how that isn't a serious security problem,
and he quickly responded with something along the lines of "lets say
you can pose as the merchant, what are you going to do?". I responded
by saying "I'd start posting refunds to my card" and he said "the
refund option has to be enabled per merchant". Next, I told him I
could charge cards. His response to this was that "well, then you would
be giving money to the merchant".
I suggested to him that if I was a malicious user, I could charge
random cards with random amounts to the merchant's account. His
response: "our backend would detect that". I asked for clarification
and realized that the security he is talking about is their "Fraud
Protection" system. From my knowledge (and I've used the CSI API in
several projects) and according the the API documentation available
online, this system just blocks an end-user from attempting to charge
credit cards if they've had repeated failures. The key here is that
it uses the _end user's_ (the person submitting a credit card to the
merchants site -- the web browser) IP. This IP is sent to the gateway
server from the client API. It's very simple to write a program which
charges a whole bunch of cards and makes the API think each one came
from a different IP (especially since the IP is just one of the items
in the struct you pass to the client API). Obviously, the Fraud
Protection provided by the gateway server is not meant to prevent a
fraudulent merchant -- it is made to prevent fraudulent customers from
fooling legitimate merchants. In this scenario, you _would be_ the
merchant and therefore not subject to fraud checks.
At this point, I had given up. I have a hard time understanding how
it's "not a security problem" for me to be able to pose as the
merchant. Even if I can't refund my card, I can cause a lot of
unwanted trouble by charging cards, etc.
== Summary ==
Unprotected Digital Certificates (no passphrase) that establish the
identity of a merchant are sent via unencrypted email, along with the
merchants "Store Name". Someone with access to the LinkPoint API could
use this information to pose as the merchant and have access to all of
the same functions and information as the merchant (charge a card,
etc).
--
Tolga
This archive was generated by hypermail 2b30 : Sun Jul 15 2001 - 21:21:31 PDT