Date: Sat, 5 Jan 2002 20:26:15 -0800 From: vps-support <vps-supportat_private> To: "'keithat_private'" <keithat_private>, "'nbaileyat_private'" <nbaileyat_private>, "'bugtraqat_private'" <bugtraqat_private> 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: nbaileyat_private > Posted At: 15:56:01.530 01/04/2002 > Posted To: supportat_private > Subject: Fw: VERISIGN "PAYFLOW LINK" PAYMENT SERVICE SECURITY FAILURE > > Please investigate and forward to the appropriate Verisign employees... > > ----- Original Message ----- > From: "keith royster" <keithat_private> > To: <bugtraqat_private> > 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 > > keithat_private > > > > > > > > > >
This archive was generated by hypermail 2b30 : Mon Jan 07 2002 - 11:08:42 PST