Vulnerabilities in Online Payment Systems

This hack was conducted as a research project. It’s unlikely it’s being done in the wild:

In one attack, Wang and colleagues used a plug-in for the Firefox web browser to examine data being sent and received by the online retailer Buy.com. When users make a purchase, Buy.com directs them to PayPal. Once they have paid, PayPal sends Buy.com a confirmation message tagged with a code that identifies the transaction.

PayPal handles its side of the process securely, says Wang, but Buy.com was relatively easy to fool. First the team purchased an item and noted the confirmation code used by PayPal. Then they selected a second item on Buy.com but did not pay up. Instead, they used the code from the first transaction to fake a confirmation message, which Buy.com accepted as proof of payment.

Paper here.

Tags: banking, PayPal, replay attacks

Posted on May 9, 2011 at 1:50 PM • 24 Comments

Comments

noah • May 9, 2011 2:09 PM

I was implementing PayPal integration for an online store just last week and almost left a similar hole. I’d be surprised if it wasn’t being used in the wild.

Andrew • May 9, 2011 2:21 PM

May not have been before but after this went public I’m sure it is now.

Atul Agarwal • May 9, 2011 2:23 PM

Interesting..

I haven’t extensively looked into this, but I think the PayPal’s IPN system solves this problem.

“The IPN message is not actually part of the response sent to your website. Rather, the IPN message is sent to the your listener, which allows you to take actions that are not directly tied to the operation of your website.”

Source : https://cms.paypal.com/cgi-bin/marketingweb?cmd=_render-content&content_ID=developer/e_howto_admin_IPNIntro

Kaur • May 9, 2011 2:49 PM

This is definetly being done in the wild. Every >1000 user site I’ve built that has paypal has experienced several attack attempts similar to this.

The IPN can be used to solve it somewhat but one other big mistake that people seem to do is not double-check the amount payed. People are trying to attack it by completing the whole process but changing the amount the pay.

Nick P • May 9, 2011 3:39 PM

Isn’t this basically a replay attack? Replay attacks are a common attack strategy in the wild for hitting any kind of e-commerce site. It’s very shoddy design work on buy.com’s part, violating best practices in validation.

I’d also be surprised if something like this hasn’t been done in the wild. Are today’s crackers so used to things like metasploit and premade infection kits that they no longer can identify simple opportunities such as this?

Walter • May 9, 2011 3:42 PM

I have had the unfortunate experience of working on quite a few sites that were all susceptible to this type of attack. It is quite common on small sites where there isn’t a high risk of scammers. Or where the owner prefers the quick and dirty over secure (or the original developer was just incompetent).
Fortunately all the quick and dirty solutions I’ve seen were breaking down because of technical reasons before they could be abused.

Christopher • May 9, 2011 4:26 PM

There are indeed two different methods of payment data transmission in place at PayPal.

PDT is the one abused in the paper. It employs a transaction ID that is reusable by the attacker if the attacked online shop doesn’t stick to PP’s development guidelines. They are rather verbose about this issue at PayPal.

IPN, the one mentioned by you, Atul, doesn’t piggyback payment processing info onto the customer’s browsing session, but the paper still shows an angle against it (although I am too tired to look if it’s actually valid, and the paper’s presentation is exceptionally bad).

All in all, I think IPN is a lot safer, but PDT is a lot easier to hack down for the average web developer. So here we are again, with the old balance of security and commodity.

Steve Parker • May 9, 2011 6:08 PM

I’ve been selling PDFs online since 2004, and have covered this from day one. It is clearly documented in the PayPal notes (or it was then, I haven’t read them closely since). The merchant site gets a key to verify the transaction, and can validate every part of the transaction (currency, value, etc). That is what the “Return to Merchant” button is for.

It would be nice if PayPal could find a way to tell a merchant that a customer went through the whole process but didn’t notice the “Return to Merchant” button on the Paypal site; when that happens, customers pay but do not get their files, because my website has not received any kind of notification that the payment has been made.

tommy • May 9, 2011 6:49 PM

The very concept of PayPal and their business model stunk when first I heard about it. Never used it from the beginning, never will. This, and other exploits, really shouldn’t surprise anyone remotely concerned with security.

cuddlefish • May 9, 2011 9:45 PM

Bitcoin is an… interesting solution to this problem. Of course, companies who don’t host their own daemons and instead rely on an e-wallet will have basically the same problems.

cuddlefish • May 9, 2011 9:50 PM

Oh, wait, no. MyBitcoin (the most popular e-wallet) GPG-signs all its outgoing data. So I guess that’s more secure.

On a side note, why aren’t more payment processors doing that?

Daniel Wijk • May 10, 2011 2:19 AM

Another interesting vulnerability I discovered when making a purchased a couple of months back was that the web-shop I used did not check the items payed for versus the items in my shopping bag.

When I accidentally added another item into my shopping bag while paying the company thanked me for purchasing item A and B although I only payed for item A.

I contacted the web-shop asap when the receipt came to my email address and I discovered I had payed for just 1 item but where promised a delivery of two. Sadly (for the web-shop) they never replied me despite trying to both phone them, email them and using their “24/7 online support” and I got two items for the price of one. I still haven’t heard anything from them.

Danny Moules • May 10, 2011 3:28 AM

Of course PayPal provide solutions to prevent this being a problem but that doesn’t mean individual implementations actually make use of it properly.

Adam • May 10, 2011 3:29 AM

Cuddlefish, Bitcoin is interesting, but who’s to say it’s not vulnerable to it’s own manner of attacks? After all what’s to stop someone grinding the whole network to a halt by flooding clients with bogus transactions or transactions for very trivial amounts, e.g. two bitcoin clients ping ponging a 0.00000001 BC transaction back and forth a billion times. At the very least you could probably make the entire system chug. At worst, well you might be able to corrupt people’s wallets which I suspect in most cases are not backed up.

Kaur • May 10, 2011 7:14 AM

@Adam

Currently every bitcoin transaction that is for an amount less than 0.01 will need to include a transaction fee of at least 0.01. This is exactly to combat a potential attack. These exact numbers are enforced by miners and as such can be changed on the fly. It’s also possible to set up your own miner that will allow transactions of very small fractions without a fee.

Adam • May 10, 2011 8:32 AM

@Kaur, fair enough but what if I transfer 0.01 then? Or 1 BC? I could even fraudulently buy a pot of bitcoins through one of the various exchanges, allocate the coins to various machines set up in any arbitrary configuration I liked and continuously start transactions between them. I expect at the moment that my traffic would vastly exceed the rest of the network combined and I’d probably swamp it at the very least.

I just think the thing is untested and likely to be very fragile.

Anton • May 10, 2011 11:09 AM

A similair attack was used some time ago in the Netherlands. A webshop to order food, justeat.nl, had a flawed iDeal implementation (iDeal is a payment system by the dutch banks similair to paypal) . It allowed an attacker to intercept the request to iDeal and modify the amount of money to pay. After the transaction the site didn’t verify the amount payed.

This hack became quite popular with students in the whole country. About 30.000 euro damage was done when it was discovered, but most of it was payed back by the students.

Dirk Praet • May 10, 2011 6:15 PM

One of the problems I see is that several e-commerce systems offer 3rd party payment plugins that haven’t necessarily been scrutinized for security by the main developer team. And thus get implemented no questions asked by quite some people that are more concerned with a slick look-and-feel than what is actually under the hood. By the time the shop gets defrauded, most bills are paid and both shopkeeper and customer get told a story of evil hackers or Chinese APT’s nobody has any defense against.

Roger Wolff • May 11, 2011 3:44 AM

@adam, re bitcoin.

The developers have put a lot of thought into protecting the bitcoin network against all sorts of attacks, including the ones brought up by you.

Daniel Wijk • May 11, 2011 5:36 AM

Adam: If you think its untested and likely to be fragile then by all means share your thoughts with the developers and see what they say about your thoughts.

Only good things can come out of critical thinking and constructive criticism.

Doug Coulter • May 11, 2011 12:11 PM

I know, I didn’t RTFA and this isn’t slashdot, but:

Wouldn’t anyone be putting those tokens from Paypal in a database for their records (maybe required to balance the books anyway and make sure Paypal wasn’t ripping them off), and wouldn’t it be trivial to do a search on each new token to prevent any playback? Does Paypal not make them unique? They’d have to, wouldn’t they?

Despite them not being the guilty party here, I think Paypal is a disaster waiting to happen. They are getting to act like a bank without even the minimal regulation that has shown to be not good enough even for those banks subjected to it.

It’s a big waving red flag most people ignore out of “it works and I’m lazy”. Well,,,,,look what happened last time — want more?

Tangurena • May 11, 2011 1:07 PM

Pay.gov (run by the federal reserve bank of Cleveland) avoids this problem by using a separate back channel to submit payment details to the “merchant” (some government agency). That back channel uses certificates which have to be previously distributed, so this avoids man-in-the-middle attacks. They also avoid the “return to merchant” button problem by redirecting the user back to the originating site.

I worked on one government website that brought in about 1/4 billion/year in taxes/fees/revenue this way.

Kaur • May 11, 2011 1:08 PM

@Adam

The total transaction block size limit is 512KB I belive. The storage is provided to transactions prioritized by the included transaction fees. So if you make a bunch of useless transactions and fill up the space then regular users will essentially have to outbid you for that space by including a higher transaction fee. So in order to not completely be ignored you have to start including transaction fees yourself. These fees come from your wallet and go into the winning miner’s wallet. Basically, this attack will get real expensive real fast.

Ross • May 13, 2011 2:32 PM

@Doug: yes, it’s really easy to do protections like you note — verify no duplicate transaction IDs. I do that on my site. I also use PayPal’s other tools which both verify the transaction amount and prevent against the article’s attack if you use them right.

I’ve also got the benefit of working in digital goods inside a game, so if anyone really tried to scam me I’d just terminate their account.

Like Steve Parker, one of my biggest problems is the “customer failed to return to the website” issue. I tend to assume it’s user error (not waiting for the forwarder, not seeing the backup link) but it happens enough some of it may be PayPal. One way or the other, I get a lot of follow up emails that the automatic delivery didn’t work.

Schneier on Security

Vulnerabilities in Online Payment Systems

Comments

Leave a comment Cancel reply