I. Electronic commerce security bugs ------------------------------------------ E-COMMERCE SECURITY BUGS Based on the paper: Rui Wang, Shuo Chen, XiaoFeng Wang, and Shaz Qadeer. How to Shop for Free Online -- Security Analysis of Cashier-as-a-Service Based Web Stores. In IEEE Symposium on Security and Privacy, 2011, pp. 465-480. doi: 10.1109/SP.2011.26 Motivation: Web apps integrate 3rd-party services focus: cashier-as-a-service (CaaS) CaaS vendors: - PayPal, - Amazon Payments, - Google Checkout Web stores using CaaS APIs: - Buy.com - JR.com - Walmart.com - Adidas.com - Lenovo.com - Dell.com etc. ------------------------------------------ ------------------------------------------ PROBLEM AND CONTRIBUTIONS Many CaaS integrations have "serious security flaws" allowed: - shopping for free - paying arbitrary price Contributions: - security analysis of CaaS integration - security flaws and practical attacks - complexity of the problems ------------------------------------------ ------------------------------------------ TECHNICAL PROBLEM Coordination of 3 parties: order /---------> [ Web Store ] / ^ / | joint decision: [Shopper] | is order paid \ | appropriately? \ | \ payment v \--------> [ CaaS ] ------------------------------------------ Have you ever tried to play one parent off against another or seen a kid do that? ------------------------------------------ WHAT MERCHANT AND CAAS NEED TO AGREE ON - Web store owns the item - Payment will be transferred to web store from the shopper (via the CaaS) - The payment is for the right amount - The payment is for the right item(s) ------------------------------------------ Why would any of this be a problem? Could we just use a cookie with the payment total? How does this work in a physical store when paying by credit card? ------------------------------------------ COMPLICATING FACTORS Who is responsible for checking that: - Transaction ID is correct - Transaction is for the right store Attacker can pretend to be both - buyer - seller Transactions happening in parallel APIs are public ------------------------------------------ A. Attack Model ------------------------------------------ ATTACK MODEL Attacker can: call web APIs exposed by merchant and CaaS website in arbitrary order, with arbitrary argument values. Allowed: - register as a seller - obtain (legit) digital certificates - deliver messages in different order than a browser would Note: - NO network attacks (man-in-the-middle) - Crypto assumed perfect, NOT broken CANNOT break HTTPS protocols CANNOT forge signatures - All communication via HTTPS ------------------------------------------ Would it be a mistake to assume that an attacker just uses a browser normally? Why? Does HTTPS solve all security problems? B. examples ------------------------------------------ OVERVIEW OF ATTACKS (2011) Merchant CaaS Faulty Result ========================================== NopCommerce PayPal Check of Pay payment arbitrary total price NopCommerce Amazon Shop Simple for free Pay Interspire Amazon Sign. Shop Simple check for free Pay Interspire PayPal Shopper Pay Express with 2 arbitrary sessions price Interspire PayPal Replays Pay Std. allowed arbitrary price Interspire Google Add items Obtain Ch.kout to cart extra items after total is fixed etc. ------------------------------------------ 1. Nopcommerce and PayPal Standard 2. notation ------------------------------------------ NOTATION FOR ORIGIN AND SIGNING TStore.com (T) is web store CaaS.com (C) is CaaS Attacker (A) is shopper S,S1,S2,S3 in {T, C, A} - S(val) means S originated val - S*(val) means S signed val - A(val) means attacker controls all non-signed values passed S> N.a : S starts Nth exchange S1> N.a.a : S' sends response to N.a S2< N.a.b : S2 receives response to N.a S3< N.b is reply to N.a received by S3 Example: A> 1.a TStore.com/placeOrder A< 1.b redir paypal.com/stdPay? T(orderID) & T(gross) & ... ------------------------------------------ What parameter passing mechanism is used in web calls? 3. example: NopCommerce and PayPal Standard ------------------------------------------ A SIMPLE ATTACK (FIG. 4) A> 1.a TStore.com/placeOrder A< 1.b redir paypal.com/stdPay? T(orderID) & T(gross) & ... A> 2.a paypal.com/stdPay? A(orderID) & A(gross)& ... A< 2.b redir TStore.com/finishOrder? C(tx) & ... A> 3.a TStore.com/finishOrder? A(tx) & ... T> 3.a.a paypal.com/PDTDetails? A(tx)&T(identity) T< 3.a.b paid? A(orderID) & A(gross) & ... A< 3.b done Code for TStore.com/finishOrder: tnDetails=wCall_PDTDetails(tx,identity); /* resulting in 3.a.a and 3.a.b */ orderID=GetOrderIDField(tnDetails); order=LoadOrderByID(orderID); if ((order != null) and (order.status==PENDING) order.status = PAID; ------------------------------------------ Is communication between the web store and PayPal vulnerable in the given attack model? ------------------------------------------ ANY PROBLEMS? See any problems with that use of APIs? ------------------------------------------ 4. example: Nopcommerce and Amazon Simple Pay ------------------------------------------ EXAMPLE WITH AMAZON SIMPLE PAY A> 1.a TStore.com/placeOrder A< 1.b T*(amzn.com/pay?orderID & gross & returnURL ...) A> 2.a T*(amzn.com/pay?orderID & gross & returnURL ...) A< 2.b redir C*(T(returnURL)?C(payeeEmail) &C(status=PAID)&T(orderID) &T(gross)&...) A> 3.a C*(T(returnURL)?C(payeeEmail) &C(status=PAID)&T(orderID) &T(gross)&...) A< 3.b done ------------------------------------------ Is this one secure? ------------------------------------------ FLAW IN AMAZON SIMPLE PAY Anyone can become a seller with Amazon (for a $25 credit card) Attacker creates "store" AtksRus idea: - pay store AtksRus and use info to check out from web store ------------------------------------------ Can you get a credit card to charge $25 and remain anonymous? So, who gets the money? ------------------------------------------ MESSAGES IN THE ATTACK A> 1.a TStore.com/placeOrder A< 1.b T*(amzn.com/pay?orderID & gross & TStore.com/finishOrder ...) A> 2.a A*(amzn.com/pay?A(orderID) & A(gross) & A(TStore.com/finishOrder) ...) A< 2.b redir C*(A(TStore.com/finishOrder)? C(orders@atksRUs.com) &C(status=PAID)&A(orderID) &A(gross)&...) A> 3.a C*(A(TStore.com/finishOrder)? C(orders@atksRUs.com) &C(status=PAID)&A(orderID) &A(gross)&...) A< 3.b done ------------------------------------------ Why does the payment go to Attacker? Why does the web store send the goods to the attacker? Why couldn't the attacker put the real merchant's email address in the pay message (2.a)? What better design could fix this problem? 5. example: Interspire and PayPal Express ------------------------------------------ EXAMPLE WITH PAYPAL EXPRESS A> 1.a TStore.com/placeOrder T> 1.a.a paypal.com/SetExpCheckout? T(identity) & ... T< 1.a.b C(token) A< 1.b redir paypal.com/pay ? C(token) A> 2.a paypal.com/pay ? A(token) A< 2.b redir TStore.com/finishOrder ? C(token) & C(payerID) A> 3.a TStore.com/finishOrder ? A(token) & A(payerID) T> 3.a.a paypal.com/DoExpPay ? T(identity) & C(token) &T(gross) T< 3.a.b C(result) A< 3.b redir TStore.com/updateOrderStatus ? T*(orderID) A> 4.a TStore.com/updateOrderStatus ? T*(orderID) T< 4.b done ------------------------------------------ Some messages in this example are not signed, is that a security bug? Why is orderID signed by the web store (T)? ------------------------------------------ MERCHANT'S (PSEUDO) CODE finishOrder() { result=wCall_DoExpPay( identity,token,gross); // This results in 3.a.a and 3.a.b SESSION["result"]=result; signedOID=sign(orderID); redirect("/updateOrderStatus?" + signedOID); //This results in 3.b and 4.a } updateOrderStatus() { Verify the signature of T*(orderID) in message 4.a If verification fails, then exit; // here verification succeeded order=LoadOrderByID(orderID); if (SESSION["result"]==SUCCESS) orderStatus=PAID; SESSION["result"]=null; } ------------------------------------------ Is this secure? ------------------------------------------ ATTACK ON PAYPAL EXPRESS (1) First session: A> 1.a TStore.com/placeOrder // cheap T> 1.a.a paypal.com/SetExpCheckout? T(identity) & ... T< 1.a.b C(token) A< 1.b redir paypal.com/pay ? C(token) A> 2.a paypal.com/pay ? A(token) A< 2.b redir TStore.com/finishOrder ? C(token) & C(payerID) A> 3.a TStore.com/finishOrder ? A(token) & A(payerID) T> 3.a.a paypal.com/DoExpPay ? T(identity) & C(token) &T(gross) T< 3.a.b C(result) A< 3.b redir TStore.com/updateOrderStatus ? T*(orderID) Attacker doesn't send message 4.a now but what is SESSION["result"]? ------------------------------------------ ------------------------------------------ ATTACK ON PAYPAL EXPRESS (2) A2 is attacker's second session: A2> 1.a TStore.com/placeOrder // expensive T> 1.a.a paypal.com/SetExpCheckout? T(identity) & ... T< 1.a.b C(token2) A2< 1.b redir paypal.com/pay ? C(token2) A2> 2.a paypal.com/pay ? A(token2) A2< 2.b redir TStore.com/finishOrder ? C(token2) & C(payerID) A2> 3.a TStore.com/finishOrder ? A(token2) & A(payerID) T> 3.a.a paypal.com/DoExpPay ? T(identity) & C(token2) &T(gross2) T< 3.a.b C(result) A2< 3.b redir TStore.com/updateOrderStatus ? T*(orderID2) Now attacker knows T*(orderID2) So back to first session: A> 4.a TStore.com/updateOrderStatus ? T*(orderID2) T< 4.b done ------------------------------------------ At this point, what is the orderStatus of expensive orderID2? What would be a fix to prevent this attack? 6. other examples a. Interspire, IPNs, and PayPal Standard ------------------------------------------ INTERSPIRE WITH IPN AND PAYPAL STANDARD Instant Payment Notification (IPN) is an HTTP message sent by CaaS to merchant, notifying them of payment A> 1.a TStore.com/placeOrder A< 1.b redir paypal.com/stdPay ? T(orderID) & T(gross) & T(merchantID) & T(TStore.com/handleIPN) ... A> 2.a paypal.com/stdPay ? A(orderID) & A(gross) & A(merchantID) & A(TStore.com/handleIPN) ... C> 2.a.a TStore.com/handleIPN ? C*(A(orderID) & A(gross) & A(merchantID) & C(status)) C< 2.a.b T(result) A< 2.b redir TStore.com/finishOrder ? A> 3.a TStore.com/finishOrder ? ... A< 3.b displays order status ... ------------------------------------------ ------------------------------------------ PSEUDO CODE FOR HANDLER handleIPN() { order=LoadOrderByID(orderID); if (order==null || order.status != PENDING) exit; if (merchantID != TStore's ID) exit; if (gross != order.gross || status != PAID) exit; // here everything checks order.status=PAID; } loadOrderByID(orderId) { if (orderId is empty) orderId=COOKIE[`ORDER_ID']; find order in database with orderId; } ------------------------------------------ Is that secure? 7. exploits can also apply to closed-source software ------------------------------------------ EXPERIMENTS ON OTHER STORES Buy.com and JR.com also could be attacked in similar ways Buy.com uses PayPal Express pay for one item, get token, reuse token on a different order JR.com and CaaS (Amazon) did not coordinate security checks allows bogus merchants ------------------------------------------ 8. exploits worked on live stores ------------------------------------------ EXPERIMENTS ON REAL STORES With univ. attorney present - Canceled orders or sent items back - paid more rather than less - told company about flaws ------------------------------------------ C. attacker anonymity ------------------------------------------ ATTACK CAN REMAIN ANONYMOUS Can buy MasterCard gift cards for $25 at a supermarket, no ID needed Register MasterCard with fake information (e.g., gmail accounts) Buying digital products has no physical delivery ------------------------------------------ D. software verification to prevent problems ------------------------------------------ SOFTWARE VERIFICATION Formal model (using C code) + bounded checker (Poirot) - found all logic flaws in about 5 min. - but ran out of memory if loop/bound was more than 6 - discovered some new attacks ------------------------------------------ ------------------------------------------ CONCLUSION OF PAPER 1. Automatic verification is necessary. - systems too complex for manual verification of security 2. Systems should be simplified to aid automatic verification ------------------------------------------ ------------------------------------------ ALTERNATIVE FORMAL METHODS For modeling of protocols, which use cryptography for security 1. Dolev and Yao's algebraic modeling: Danny Dolev and Andrew C. Yao. On the Security of Public Key Protocols. Technical Report. Stanford University, 1981 Related tools: - Interrogator and - NRL Protocol Analyzer 2. BAN Logic: Michael Burrows, Martin Abadi, and Roger Needham. A logic of authentication. ACM Trans. Computer Systems, vol 8 #1, pp.18-36, 1990. ------------------------------------------