Vulnerability Development mailing list archives
RE: Vuln in Verisign PayFlow Link payment service
From: keith royster <keith () homebrew com>
Date: Fri, 4 Jan 2002 13:15:01 -0500
I think the solution is very easy. Don't post from the browser to Verisign, but to the server that will forward the request to Verisign and then back to the browser. In that way the server controls everything and the client is unable to change the outcome.
Agreed, but that's not how PayFlow Link works. Verisign has another product, called PayFlow Pro, which I believe does do this. So instead of fixing it, such as with a "shared secret" solution mentioned previously, they plan to just encourage people to upgrade to the Pro version.
-----Original Message----- From: Megan McRee [mailto:meganmc () mail ru] Sent: vrijdag 4 januari 2002 1:12 To: vuln-dev () securityfocus com Subject: Re: Vuln in Verisign PayFlow Link payment service I hate to see this post. From a developer's perspective, this is one of the easiest and most flexible card processing systems to integrate with my software that I have found. Perhaps a fix for VeriSign would be to passback a secret code (configurable through the PayFlow Link admin panel) that does not originate from a cart input value, but is stored and sent from PayFlow. Then a simple 'if' statement in the cart software could weed out the bad along with an e-mail sent to the admin. That would surely slow someone down if they have to guess the secret code's input value. I would hate to see them change the way the current system of passing back values works. Does anyone know of any other card processing services that pass back variables to software/scripts in the same manner? ----- Original Message ----- From: Keith Royster <keith () theroysters com> To: <vuln-dev () securityfocus com> Sent: Thursday, January 03, 2002 5:39 PM Subject: Vuln in Verisign PayFlow Link payment serviceHello! I'm very new to this list and am looking for advice on how andwhereto properly post information regarding a vulnerability I have identified with Verisign's PayFlow Link credit card payment service. I would ultimately like for this information to get into the Vuln Database at BugTraq, but do not know the proper procedures and requirements forgettingit there. Below is a brief(?) description of the service and theexploit...THE SERVICE: The final checkout page of various online shopping cart applications presents the shopper with a form asking for credit cardacct#,exp date, etc. When the shopper submits the form, the data is sentdirectlyto the vendor's PayFlow Link account at Verisign for validation. If the credit card information if 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 wasauthorizedand finalizes the order for the vendor to fill and ship it. EXPLOIT #1: On the final checkout page, save the HTML to disk and edittheACTION= 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 thereisno 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.Whilein demo mode, this account will "validate" almost any credit card info submitted to it. This account should be configured to send theconfirmationinformation to the exploitee's shopping system. Then perform a similarHTMLedit of the final checkout page as above, only this time change thehiddenform tag to direct the payment to your demo PayFlow Link account. SavetheHTML, reload in your browser, and submit bogus credit card info. THE RISK: Vendors that do no validate payment in their Verisign acctpriorto shipment, or those that offer immediate downloads of software upon payment, are vulnerable to theft. WHAT I KNOW: I have successfully performed both exploits on a MivaMerchant3.x shopping cart. I have not had the opportunity to test other shopping cart applications or other versions of Merchant. I have communicatedthisinformation to both Miva and Verisign. Verisign tested and confirmedbothexploits as well. They then responded that they do not intend to fix it-that instead they will 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 thatothersare. 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's PayFlowLinkmodule is the same 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. TIA!
Current thread:
- Vuln in Verisign PayFlow Link payment service Keith Royster (Jan 03)
- Re: Vuln in Verisign PayFlow Link payment service Megan McRee (Jan 03)
- Re: Vuln in Verisign PayFlow Link payment service jon schatz (Jan 03)
- Re: Vuln in Verisign PayFlow Link payment service Doru Petrescu (Jan 04)
- Re: Vuln in Verisign PayFlow Link payment service Megan McRee (Jan 05)
- Re: Vuln in Verisign PayFlow Link payment service Keith Royster (Jan 05)
- Re: Vuln in Verisign PayFlow Link payment service Megan McRee (Jan 05)
- Re: Vuln in Verisign PayFlow Link payment service Megan McRee (Jan 03)
- Re: Vuln in Verisign PayFlow Link payment service Keith Royster (Jan 04)
- <Possible follow-ups>
- RE: Vuln in Verisign PayFlow Link payment service Erwin Geirnaert (Jan 04)
- RE: Vuln in Verisign PayFlow Link payment service keith royster (Jan 04)