Business Logic Protocol Fraud
Security is hard.
Basic protocols, like TCP, HTTP and SSL are constantly under assault from those hoping to exploit weaknesses to gain advantages. It takes white hats all over the world to just barely keep ahead of the bad guys in maintaining the availability of basic, agreed-upon, scrutinized and open network communication protocols. And that’s for the already thoroughly-researched ones!
Now take into consideration that the major Internet retailers have their own protocols. PayPal API, Amazon Payments, Google Checkout are all proprietary protocols. It might be harder to devise attacks for them, since they aren’t open protocols, but on the other hand, they will almost assuredly have more weaknesses that can be exploited.
A group of security researchers from Indiana University and Microsoft have done an initial examination of business logic flaws in each of the proprietary protocols and presented their findings in this paper.
http://research.microsoft.com/pubs/145858/caas-oakland-final.pdf
(Bruce Schneier writes about it here)
The researchers found straight-forward exploits in each of the business protocols. The causes of each exploit range from a mundane oversight (not checking a signature) to the fact that these transactions involve three parties, none of whom has the whole picture of the full transaction.
Message Integrity Failure #1 - One of the attacks succeeds because the PayPal Standard checkout API forgets to include a signed hash in their finishOrder message. By the way, this is the same flaw that doomed SSL version 2.0, over a decade ago.
Message Integrity Failure #2 - Another attack involves Amazon’s Simple Pay. The service correctly requires signatures on all its messages, but then at the end it turns out that the presentation of any signed receipt (even one that you paid to yourself) will work as a proof to the merchant.
“...Everyone who has a computer and a small amount of cash (e.g., $25) is a qualified attacker. By exploiting the logic flaws, a malicious shopper is able to purchase at an arbitrarily-set price, shop for free after paying for one item, or even avoid payment.”
Don’t trust your Customer – The PayPal Express system stores “PAID” status state with the client. Therefore a malicious client can buy a cheap item and then use the PAID status of that item on an expensive one.
Bottomless Cart - With Google Checkout it was possible for customers to add items to their cart after invoking the order total, effectively allowing them to shop for free for some time.
The researchers did this research against two open-source payment packages, InterSpire and NopCommerce, which use the eCommerce APIs. The paper doesn’t come out and say if these vulnerabilities are in the APIs themselves or in the packages. But the conclusion is the same either way.
The technologies that are actually adopted by today’s e-commerce are web services like PayPal, Amazon Payments and Google Checkout, which are never referred to as “payment protocols”. Indeed they are not protocols – they are APIs with proprietary implementations and public interfaces, accompanied by the developer’s guides and sample code. Compared with protocols, which clearly specify the actions different parties are supposed to take, the ways these APIs are used are less rigorously defined, thus offering flexibility to their callers.
Does this mean that these proprietary systems are inherently insecure? Not necessarily. The real point is that systems need scrutiny to improve their security and protect the assets involved. Open protocols get that scrutiny all the time. This paper is exactly the kind of analysis that these services need. The existence of the more egregious failures suggests that these services might not have been properly pen-tested. That is the worrisome aspect – that their owners aren’t taking the security of these business protocols seriously enough. Perhaps Amazon, PayPal and Google should send gift baskets to these security researchers and invite them to do another round.