[Fwd: Re : Fw: VERISIGN "PAYFLOW LINK" PAYMENT SERVICE SECURITY FAILURE (#5947-000093-7546\939465)]From: Blue Boar (BlueBoar@thievco.com)
- Previous message: Ed Moyle: "RE: Cross-Site Scripting in PlumTree?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 07 Jan 2002 10:05:52 -0800 From: Blue Boar <BlueBoar@thievco.com> To: email@example.com
Date: Sat, 5 Jan 2002 20:26:15 -0800
From: vps-support <firstname.lastname@example.org>
To: "'email@example.com'" <firstname.lastname@example.org>,
> 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
> 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:
> -----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)
> ORIGINAL MESSAGE:
> From: email@example.com
> Posted At: 15:56:01.530 01/04/2002
> Posted To: firstname.lastname@example.org
> Subject: Fw: VERISIGN "PAYFLOW LINK" PAYMENT SERVICE SECURITY FAILURE
> Please investigate and forward to the appropriate Verisign employees...
> ----- Original Message -----
> From: "keith royster" <email@example.com>
> To: <firstname.lastname@example.org>
> 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
> > shopping cart applications presents the shopper with a form asking for
> > card acct#, exp date, etc. When the shopper submits the form, the data is
> > directly to the vendor's PayFlow Link account at Verisign for validation.
> > 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
> > open to maintain session) and edit the ACTION= portion of the form to
> > 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
> > edited HTML, reload in your browser, and submit bogus credit card info
> > your order. Since there is no authentication between Verisign and the
> > application, the shopping app will think that the card was authorized, and
> > 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
> > to it as long as the card# meets basic format, expiration date hasn't
> > and amount <= $100. This demo account should be configured to send the
> > confirmation information to the exploitee's shopping system. Then perform
> > similar HTML edit of the final checkout page as above, only this time
> > the hidden form tag to direct the payment to the demo PayFlow Link
> > 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
> > 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
> > more secure PayFlow Pro product if you have security concerns with PayFlow
> > WHAT I KNOW: I have successfully performed both exploits on a Miva
> > 3.x shopping cart. Due to a lack of accessability, I have not tested
> > shopping cart applications or other versions of Miva Merchant. I have
> > communicated this information to both Miva and Verisign. Verisign tested
> > confirmed both exploits as well. They then responded that they will work
> > Miva to work towards better security, although they did not offer any
> > timelines. They did not mention working with other vendors of other
> > carts, nor did they admit the problem exists with other shopping cart
> > Their only current solution is to educate their customers regarding the
> > 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
> > besides Miva's) are vulnerable. But I am highly suspicious that others
> > because the problem seems to be that the PayFlow Link app does not offer
> > 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
> > 3.x. Merchant 4.x is the most current version, but I think it uses the
> > 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
> > 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
> > email@example.com