Joint work with Rui Wang, Kehuan Zhang, XiaoFeng Wang (Indiana Univ.), Shaz Qadeer (MSR)

1. Security and privacy implications of the multi-component nature of Software-as-a-Service Shuo Chen (MSR) Joint work with Rui Wang, Kehuan Zhang, XiaoFeng Wang (Indiana Univ.), Shaz Qadeer (MSR)

2. … Software-as-a-Service • A multi-component system across the Internet • Security/privacy implications not fully recognized by web developers • Typical SaaS app today: client and multiple services across trust boundaries • Desktop app: everything on one machine • Simple SaaS app: client and server

3. Security implication: how to integrate web services How to Shop for Free Online – Security Analysis of Cashier-as-a-Service Based Web StoresTo appear in Oakland’11

4. Motivation (financial ) • Some interesting items that we bought from web stores Breath alcohol tester from Buy.com Charger from Buy.com DVD from GoodEmotionsDVD Agility cream from Pride Nutrition Journal (digital copy) from LinuxJournalStore • Didn’t pay, or only paid the prices that we set arbitrarily • Because of logic bugs in checkout mechanisms

5. Motivation (academic) • APIs as web services • An important ingredient in the concept of software-as-a-service • e.g., Bing Search APIs, Google Map APIs, Facebook APIs, PayPal APIs • Intuition: security for multi-party web apps can be very challenging • Need to show a significant empirical evidence

6. Sounds reasonable, but ask Dad to call me. Why challenging, intuitively? Mom, can I do X? Mom I think it is fine. Naughty kid Sounds like a wacky idea. I am not sure. What do you think? Dad, Mom is ok about X’, can you call her? Dad OK.

7. Web stores integrating 3rd-party cashier services • 3rd-party cashiers • e.g., PayPal, Amazon Payments, Google Checkout • We call them CaaS (Cashier-as-a-Service) • A decision to be made jointly • The merchant handles the order • The CaaS handles the payment • Decision: has the shopper properly made the payment for the order?

8. Buy.com Example of a normal checkout workflow RT1.a RT1.b RT4.a RT4.b Shopper T Thank you for your order! Your order #12345 will be shipped. View the order Why do you think that I have to run a browser? RT3.a.a RT3.a.b T Please confirm: shipping address: xxxxxxxxxxxxxxxxxxx billing address: xxxxxxxxxxxxxxxxxx total amount: $39.54 RT2.a RT2.b RT3.b This is just one example. • There are many payment methods, such as PayPal Standard, PayPal Express, Amazon Simple Pay, Checkout By Amazon, Google Checkout. • Even for one payment method, each merchant application integrates it in a different way. RT3.a PayPal (CaaS) Pay Now RT:HTTP round-trip : Web API

9. Merchant applications/websites that we have studied • The most popular .NET based open-source merchant app • The most popular commercial merchant app • Used by 15000+ businesses across 65 countries • Interspire’s own hosting service • A store for consumer electronics • 12 million shoppers

10. What we have found Explained in this talk • Logic flaws in 9 checkout scenarios

11. Four attack Examples Note: only high-level summaries in this talk; Subtleties in the source code are critical, but skipped; Please read the paper for the whole stories.

12. . Chuck, pay in Amazon with this signed letter: NopCommerce’s integration of Amazon Simple Pay Dear Amazon, order#123 is $10, when it is paid, call me at 425-111-2222. [Jeff’s signature] Great, I will ship order#123! Jeff, I want to buy this DVD. Amazon, I want to pay with this letter Jeff Dear Amazon, order#123 is $10, when it is paid, call me at 425-111-2222.[Jeff’s signature] Hi, $10 has been paid for order#123. payeeEmail= a@b.com [Amazon’s signature] Shopper Chuck Amazon Note: the phone number is analogous to the returnURL field in Amazon Simple Pay

13. Mark, pay in Amazon with this signed letter: Great, I will ship order#123! Flaw & exploit Jeff, I want to buy this DVD. Dear Amazon, order#123 is $10, when it is paid, call me at 425-111-2222. [Jeff’s signature] Jeff • Anyone can register an Amazon seller account, so can Chuck. • We purchased a $25 MasterCard gift card by cash; • We registered it under the name “Mark Smith” with fake address/phone number. • Registered seller accounts in PayPal, Amazon and Google using the card. Amazon, I want to pay with this letter Hi, $10 has been paid for order#123. payeeEmail= a@b.com [Amazon’s signature] Dear Amazon, order#123 is $10, when it is paid, call me at 425-111-2222.[Jeff’s signature] [Mark’s signature] Shopper Chuck (and seller Mark) • Chuck’s trick • Pay to Mark, but check out from Jeff. • Amazon thought that Chuck was buying from Mark • Jeff thought that Chuck was paying to Jeff Amazon

14. Interspire’s integration of PayPal Express

15. Session 2: place an expensive order (orderID2) , but skip the payment step in PayPal • Session1: pay for a cheap order (orderID1) in PayPal, but avoid the merchant from updating it status to PAID Interspire’s integration of PayPal Express (cont.) TStore.com TStore.com RT3.b RT3.b RT4.a • (RT3.b) redir to • TStore.com/updateOrder?orderID2T* • (RT3.b) redir to • TStore.com/updateOrder?orderID1T* orderID2T* • (RT4.a) call TStore.com/updateOrder?orderID1T* • Expensive order2 is checked out from session 1

16. Attacker (shopper and Mark.com) Interspire’s integration of PayPal Standard Jeff.com RT1.a: jeff.com/placeOrder • Attacker can set an IPNHandlermark.com/handleIPN loop • Normally, IPNHandler is jeff.com/handleIPN RT3.a: jeff.com/finishOrder jeff.com/ handleIPN RT2’.a: replay the message • And let PayPal send the payment notification to Mark. Read the paper to understand how subtle this bug is mark.com/handleIPN • Use a loop to place and check out many same-price orders by replaying the stolen message. RT2.a: paypal.com/stdPay? orderID&gross&merchantID&IPNHandler PayPal.com

17. Interspire’s integration of Google Checkout • The order is generated based on the cart at the payment time (RT3.a). • The payment amount is calculated based on the cart at the moment when the shopper clicks “checkout” (RT2.a). • Between RT2.a and RT3.a, the shopper can add more items to the cart.

18. Confirming these vulnerabilities in the real world

19. Four levels of confirmations • Installed NopCommerce and Interspire on our own web server. Constructed attacks against them. • Against our own store on BigCommerce.com -- Interspire’s hosting service. • Against real stores powered by NopCommerce and Interspire. • Constructed similar attacks against web stores running closed-source software, e.g., Buy.com and JR.com. • Without source code access, some exploit ideas are still applicable.

20. Responsible experiments • Experiments were conducted under close guidance of an Indiana University lawyer. • Obtained the support from Dean of School of Informatics • Principles: • No intrusion • No eventual monetary damage to the stores • Communicated full details to all affected parties • Pleasant outcome • Nobody expressed any negative opinion on our tests. • Our responsible effort was appreciated by most of them.

21. Dear Buy.com customer service, Last week I placed the two orders (Order Number: 54348156 Order number: 54348723) in buy.com. Both items were shipped recently, but I found that my paypal account has not been charged for the order 54348723 (the alcohol tester). My credit card information is: [xxxxxxxxx] The total of the order 54348723 is $5.99. Please charge my credit card. Thank you very much Dear buy.com customer service, I am a Ph.D. student doing research on e-commerce security. I bumped into an unexpected technical issue in buy.com's mechanism for accepting the paypal payments. I appreciate if you can forward this email to your engineering team. The finding is regarding the order 54348723. I placed the order in an unconventional manner (by reusing a previous paypal token), which allowed me to check out the product without paying. I have received the product in the mail. Of course I need to pay for it. Here is my credit card information [xxxxxxxxxxxx]. Please charge my card. The total on the invoice is $5.99. Our communications with Buy.com customer service From: Buy.Com Support <customerhelp@noreply.buy.com>Date: Sun, Jun 13, 2010 at 3:32 PMSubject: Re: Other questions or comments (KMM3534132I15977L0KM)To: Test Wang ruiwangworm@gmail.com Thank you for contacting us at Buy.com. Buy.com will only bill your credit card only when a product has beenshipped. We authorize payment on your credit card as soon as you placean order. Once an item has shipped, your credit card is billed for thatitem and for a portion of the shipping and/or tax charges (ifapplicable). If there are items on "Back Order" status, your credit card isre-authorized for the remaining amount and all previous authorizationsare removed. This is the reason you may have multiple billings for yourorder. … After our refund–eligible period, we mailed the products back by a certified mail. We disclosed technical details to them. A generic reply that misunderstood the situation Re: Other questions or comments (KMM3545639I15977L0KM) Buy.Com Support <customerhelp@noreply.buy.com> Wed, Jun 16, 2010 at 6:25 PM To: Test Wang <ruiwangworm@gmail.com> Hello Test, Thank you for contacting us at Buy.com. Based on our records you were billed on 6/10/2010 for $5.99. To confirm your billing information please contact PayPal at https://www.paypal.com/helpcenter or at 1-402-935-2050.

22. Vulnerability reporting and status of fixes • Amazon SDK vulnerability • 15 days after our reporting, they released a new set of SDKs for all supported languages and a security advisory, crediting Rui Wang • On 11/1/2010, 40 days after the advisory, Amazon stopped serving requests made by the vulnerable SDKs. All merchants must use the new version. • Amazon Simple Pay issue • Being fixed. • Interspire • Fixed all. • NopCommerce • Fixed all but one (the Amazon Simple Pay issue). • Buy.com and JR.com • We have sent the reports. No response. Not aware of their progress.

23. Complexity of Caas-based Checkout Logic (skipped in this talk) i) We manually extracted a subset of the checkout logic from Interspire; ii) Used Poirot (being developed by MSR) to do a bounded verification on the extracted model to measure the complexity of the checkout logic.

24. discussions

25. re Protocol verification tools would have discovered these bugs. So what is the contribution of this work? formal protocol How to check? (The verification communityknows already ) predicates • The real challenge that I see in system security in general How to extract the logic model? What to check? System researcher’s contribution Actual merchant system Actual CaaS system Security goals (e.g., shopper should not be able to shop for free)

26. System research’s contribution: draw the map and translate real tasks Verification: it is just a reachability problem on a map. We translate it into the concrete destination. We draw the map We translate it into the concrete start point. Attacker’s goal Actual operational context The real world

27. Another contribution • Verification is a heavy tool • Don’t just force people to use it. • Be realistic -- the industry produces tons of programs, but can only afford to verify a tiny percent of it • Tell them where to use, and convince them why. • We tell people that 3rd-party service integration is a meaningful place to apply, and give them strong evidences.

28. Privacy implication: Side-Channel Leaks Side-channel-leaks in Web Applications: A Reality Today, A Challenge TomorrowIn Oakland’10

29. Web application • split between client and server • state transitions driven by network traffic Worry about privacy? Let’s do encryption.

30. Side-Channel Leaks • The eavesdropper cannot see the contents, but can observe : • number of packets, timing/size of each packet • Previous research showed privacy issues in various domains: • SSH, voice-over-IP, video-streaming, anonymity channels (e.g., Tor) • Our motivation and target domain: • target: today’s web applications • motivation: the web is the platform to deliver SaaS.

31. Our Main Findings • Surprisingly detailed user data are being leaked out from several high-profile web applications • personal health info (illnesses/medications/surgeries) • family income • investment details (mutual fund choices and allocations) • search queries • The root causes are some fundamental characteristics in today’s web apps • Defense is non-trivial • effective defense needs to be application specific. • calls for a disciplined web programming methodology.

32. Scenario: search using encrypted Wi-Fi WPA/WPA2. Example: user types “list” on a WPA2 laptop. 821  910 822  931 Query suggestion 823  995 824  1007 Attacker’s effort: linear, not exponential. Consequence: Anybody on the street knows our search queries.

33. Revealing your illnesses/medications/surgeries and the type of doctor you are seeking • Many vulnerable UI designs • Entering health records • By typing – auto suggestion • By mouse selecting – a tree-structure organization of elements • Finding a doctor • Using a dropdown list as your search input • Illness/medication/surgery information is leaked out, as well as the type of doctor being queried.

34. Revealing your family income and other info • We studied TurboTax Online • Design: a wizard-style questionnaire • Tailor the conversation based on user’s previous input. • The forms that you work on tell a lot about your family • Filing status • Number of children • Paid big medical bill • The adjusted gross income (AGI)

35. child credit state machine All transitions have unique traffic patterns. Entry page of Deductions & Credits Summary of Deductions & Credits Not eligible Full credit Partial credit • Now, consult the IRS instruction: • $1000 for each child • Phase-out starting from $110,000. For every $1000 income, lose $50 credit. (two children scenario) $0 Partial credit Not eligible Full credit $110000 $150000

36. Student-loan-interest state machine • Even worse, most decision procedures for credits/deductions have asymmetric paths. • Eligible – more questions • Not eligible – no more question Entry page of Deductions & Credits Summary of Deductions & Credits Not eligible Enter your paid interest Full credit Partial credit $0 Partial credit Not eligible Full credit $115000 $145000

37. $0 Disabled Credit $24999 A subset of identifiable AGI thresholds Earned Income Credit $41646 Retirement Savings $53000 College Expense $116000 IRA Contribution $85000 $105000 Student Loan Interest $115000 $145000 Child credit * $110000 $130000 or $150000 or $170000 … First-time Homebuyer credit $150000 $170000 Adoption expense $174730 $214780

38. Revealing your fund choices and allocation • Which funds you invest in? • No secret. • Each price history curve is a GIF image from MarketWatch. • Everybody in the world can obtain the images from MarketWatch. • Just compare the image sizes! 3346 B 3312 B 3294 B • How do you allocate your money? • Based on the public information of closing price of each fund, we are able to recover the GIF pie-chart using the image sizes in 4-5 days.

39. Inference based on the evolution of the pie-chart size in 4-or-5 days • Fidelity updates the pie chart every day after the market is closed. • The mutual fund prices are public knowledge.  80000 charts Size of day 1 Size of day 4; Prices of the day Size of day 3; Prices of the day Size of day 2; Prices of the day  800 charts 1 chart  80 charts  8 charts

40. Root causes: some fundamental characteristics of today’s web applications

41. Fundamental characteristics of web apps • Significant traffic distinctions • The chance of two different user actions having the same traffic pattern is really small. • Distinctions are everywhere in web app traffic. It’s the norm. • Low entropy input • Eavesdropper can obtain a non-negligible amount of information • Stateful communication • Many pieces of non-negligible information can be correlated to infer substantial information • Often, multiplicative ambiguity reduction power!

42. What is the challenge in defense? • Traffic pattern distinctions are everywhere. Which ones will result in serious data leaks? • Need to analyze the application semantics, the availability of public knowledge, etc. • Finding such leaks is hard! • Is there a vulnerability-agnostic defense to fix the vulnerabilities without finding them? • Of course, padding is the right strategy. • Packet size rounding: pad to the next multiple of  • Random-padding: pad x bytes, where x  [0, ) • We found that even for the discussed apps, the defense policies have to be case-by-case.

43. Application-agnostic padding for Google Health • OK to use rounding or random-padding • 32.3% network overhead (i.e., 1/3 bandwidth on side-channel info hiding)

44. Application-agnostic padding for TurboTax • Neither rounding nor random-padding can solve the problem. • Because of the asymmetric path situation

45. Application-agnostic padding for Google search • Rounding is not appropriate, because • Google’s responses are compressed. • The destination networks may or may not uncompress the responses • E.g., Microsoft gateways decompress and inspect web traffic, but Indiana University does not. • rounding before the compression Indiana Univ. still sees distinguishable sizes; • rounding before the compression  Microsoft still sees distinguishable sizes

46. Application-agnostic padding for Fidelity • Random padding is not appropriate, because • Repeatedly applying a random padding policy to the same packets quickly degrades the effectiveness. • The range of the randomness shrinks. • Suppose the user checks the mutual fund page 7 times, then • 96% probability that the randomness shrinks to /2. • Fidelity cannot do the padding • Because the browser loads the images from MarketWatch.

47. Summary

48. Summary • Many people may think that We have type-safe languages; we have HTTPS. secure web programming = web programming + secure infrastructure This understanding is too shallow. • HTTPS • HTTPS • HTTPS • Think carefully about how your adversary can exploit the multi-component nature of your app.

49. Acknowledgments • Microsoft Martín Abadi, Johnson Apacible, Brian Beckman, Josh Benaloh, Ranveer Chandra, Cormac Herley, Emre Kiciman, Akash Lal, Rob Oikawa, Jim Oker, Dan Simon, Yi-Min Wang • Indiana University Beth Cate (lawyer), Robert Schnabel (dean of Informatics)