[Fwd: Re : Fw: VERISIGN "PAYFLOW LINK" PAYMENT SERVICE SECURITY FAILURE (#5947-000093-7546\939465)]

From: Blue Boar (BlueBoar@thievco.com)
Date: 01/07/02


Date: Mon, 07 Jan 2002 10:05:52 -0800
From: Blue Boar <BlueBoar@thievco.com>
To: vuln-dev@securityfocus.com

Date: Sat, 5 Jan 2002 20:26:15 -0800
From: vps-support <vps-support@verisign.com>
To: "'keith@theroysters.com'" <keith@theroysters.com>,
"'nbailey@hotmail.com'" <nbailey@hotmail.com>,
             "'bugtraq@securityfocus.com'" <bugtraq@securityfocus.com>

vps-support wrote:
>
> Hi,
>
> The exploits that you are talking about are inherent to the HTTP protocol.
> There's no way for us to get around them. We could use an http_reffer on the
> post but a good hack can spoof that to.
>
> Basically the only way you can be totally sure is by using dedicated sockets
> on SSL and that is what Payflow Pro does. In addition the Payflow Pro client
> has a cert folder in the SDK that validates that you are talking to VeriSign
> on the other end an not someone spoofing the address of the transaction
> servers.
>
> Payflow Link only allows Sale, Authorization, and Delay Capture transactions
> to be posted to it so effectively the only malicious thing you could do is
> tell someone that more sales have come through their shopping cart program
> than really have. Payflow Link merchants should use their carts to Authorize
> transactions then capture the transactions via the secure VeriSign
> Administrative site and they should also check their carts results against
> what appear in the VeriSign administrative site because VeriSign is the
> secure connection to the card issuing banks, not their shopping carts.
> Because of the HTTP protocol you might be able to intercept a transaction on
> a carts page and change the amounts etc before it gets to the VeriSign
> transaction broker where it secure but again this is an HTTP issue.
>
> You can't post credits via Payflow Link so you can't really exploit Payflow
> Link to commit fraud if that's what you ultimately want to get at. If
> someone sends extra confirmations back to a cart the customer can always
> contact the merchant and resolve the situation assuming the merchant uses
> the authorization followed by capture via the VeriSign Manager method.
>
> Thank You,
>
> Dan G.
> VeriSign Payment Services Support
>
> ************************************************************************
> To avert risking the security of valuable corporate data,
> Well-prepared organizations should adopt a hacker's "outside-in"
> perspective to identify weaknesses that elude traditional security
> solutions. Now, VeriSign and Qualys are working together to offer
> an automated service designed to track and manage your network's
> vulnerabilities from the OUTSIDE - the only reliable vantage point
> - with nothing to install, nothing to configure. To get started, go to:
> <http://www.verisign.com/cgi-bin/go.cgi?a=w175248930810000>
> ************************************************************************
>
> -----Original Message-----
> From: support
> Sent: Friday, January 04, 2002 10:21 PM
> To: vps-support
> Subject: Re : Fw: VERISIGN "PAYFLOW LINK" PAYMENT SERVICE SECURITY
> FAILURE (#5947-000093-7546\939465)
>
> (#5947-000093-7546\939465)
>
> ORIGINAL MESSAGE:
> -----------------
>
> From: nbailey@hotmail.com
> Posted At: 15:56:01.530 01/04/2002
> Posted To: support@verisign.com
> Subject: Fw: VERISIGN "PAYFLOW LINK" PAYMENT SERVICE SECURITY FAILURE
>
> Please investigate and forward to the appropriate Verisign employees...
>
> ----- Original Message -----
> From: "keith royster" <keith@theroysters.com>
> To: <bugtraq@securityfocus.com>
> Sent: Friday, January 04, 2002 2:24 PM
> Subject: VERISIGN "PAYFLOW LINK" PAYMENT SERVICE SECURITY FAILURE
>
> > VERISIGN PAYFLOW PAYMENT SERVICE SECURITY FAILURE
> >
> > PAYFLOW LINK SERVICE DESCRIPTION: The final checkout page of various
> online
> > shopping cart applications presents the shopper with a form asking for
> credit
> > card acct#, exp date, etc. When the shopper submits the form, the data is
> sent
> > directly to the vendor's PayFlow Link account at Verisign for validation.
> If
> > the credit card information is validated, Verisign authorizes payment and
> > submits the data back to the vendors shopping cart application. When the
> > vendor's shopping app receives this data, it assumes payment was
> authorized and
> > finalizes the order for the vendor to fill and ship it.
> >
> > EXPLOIT #1: On the final checkout page, save the HTML to disk (keeping
> browser
> > open to maintain session) and edit the ACTION= portion of the form to
> direct
> > the data back at the shopping cart instead of to verisign. The exact URL
> > should match that which verisign would submit a validated order to. Save
> the
> > edited HTML, reload in your browser, and submit bogus credit card info
> with
> > your order. Since there is no authentication between Verisign and the
> shopping
> > application, the shopping app will think that the card was authorized, and
> so
> > it will finalize the order.
> >
> > EXPLOIT #2: Sign up for a free demo PayFlow Link account at Verisign.
> While in
> > demo mode, this account will "validate" almost any credit card info
> submitted
> > to it as long as the card# meets basic format, expiration date hasn't
> expired,
> > and amount <= $100. This demo account should be configured to send the
> > confirmation information to the exploitee's shopping system. Then perform
> a
> > similar HTML edit of the final checkout page as above, only this time
> change
> > the hidden form tag to direct the payment to the demo PayFlow Link
> account.
> > Save the HTML, reload in your browser, and submit bogus credit card info.
> >
> > THE RISK: Vendors that do no validate payment in their Verisign acct prior
> to
> > shipment, or those that offer immediate downloads of software upon
> payment, are
> > vulnerable to theft.
> >
> > THE FIX: In a communication from Verisign, they recommend upgrading to
> their
> > more secure PayFlow Pro product if you have security concerns with PayFlow
> Link.
> >
> > WHAT I KNOW: I have successfully performed both exploits on a Miva
> Merchant
> > 3.x shopping cart. Due to a lack of accessability, I have not tested
> other
> > shopping cart applications or other versions of Miva Merchant. I have
> > communicated this information to both Miva and Verisign. Verisign tested
> and
> > confirmed both exploits as well. They then responded that they will work
> with
> > Miva to work towards better security, although they did not offer any
> > timelines. They did not mention working with other vendors of other
> shopping
> > carts, nor did they admit the problem exists with other shopping cart
> apps.
> > Their only current solution is to educate their customers regarding the
> risks
> > and encourage them to upgrade to the more secure (and costly) PayFlow Pro
> > product.
> >
> > WHAT I DON'T KNOW: I don't know what other shopping cart applications (if
> any,
> > besides Miva's) are vulnerable. But I am highly suspicious that others
> are
> > because the problem seems to be that the PayFlow Link app does not offer
> any
> > credentials so that the receiving shopping cart app can validate the
> source of
> > the data. I also have not verified any other version of Miva Merchant
> besides
> > 3.x. Merchant 4.x is the most current version, but I think it uses the
> same
> > PayFlow Link module and so it should be vulnerable as well. I would be
> > interested in working with others that have access to other shopping cart
> apps
> > that can interface with PayFlow Link.
> >
> > PS - my first post to bugtraq, so I hope I did it right. Please let me
> know if
> > I've left anything off.
> >
> > --
> > keith royster
> > keith@theroysters.com
> >
> >
> >
> >
> >