Card Service International / LinkPoint API Security Concerns

[Tolga Tarhan <ttarhan () basxcorp com>]

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