joint work with rui wang kehuan zhang xiaofeng wang indiana univ shaz qadeer msr l.
Download
Skip this Video
Download Presentation
Joint work with Rui Wang, Kehuan Zhang, XiaoFeng Wang (Indiana Univ.), Shaz Qadeer (MSR)

Loading in 2 Seconds...

play fullscreen
1 / 49

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


  • 240 Views
  • Uploaded on

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). …. Software-as-a-Service. A multi-component system across the Internet

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Joint work with Rui Wang, Kehuan Zhang, XiaoFeng Wang (Indiana Univ.), Shaz Qadeer (MSR)' - kosey


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
joint work with rui wang kehuan zhang xiaofeng wang indiana univ shaz qadeer msr

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)

software as a service

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
slide3

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

motivation financial
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
motivation academic
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
why challenging intuitively

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.

web stores integrating 3 rd party cashier services
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?
example of a normal checkout workflow

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

merchant applications websites that we have studied
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
what we have found
What we have found

Explained in this talk

  • Logic flaws in 9 checkout scenarios
slide11

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.

nopcommerce s integration of amazon simple pay

.

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

flaw exploit

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

interspire s integration of paypal express cont

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
interspire s integration of paypal standard

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

interspire s integration of google checkout
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.
four levels of confirmations
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.
responsible experiments
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.
our communications with buy com customer service

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.

vulnerability reporting and status of fixes
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.
slide23

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.

slide25

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)

system research s contribution draw the map and translate real tasks
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

another contribution
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.
slide28

Privacy implication: Side-Channel Leaks

Side-channel-leaks in Web Applications: A Reality Today, A Challenge TomorrowIn Oakland’10

slide29

Web application

  • split between client and server
  • state transitions driven by network traffic

Worry about privacy? Let’s do encryption.

slide30

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.
slide31

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.
slide32

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.

slide33

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.
slide34

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)
slide35

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

slide36

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

slide37

$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

slide38

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.
inference based on the evolution of the pie chart size in 4 or 5 days
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

fundamental characteristics of web apps
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!
slide42

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.
slide43

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)
slide44

Application-agnostic padding for TurboTax

  • Neither rounding nor random-padding can solve the problem.
    • Because of the asymmetric path situation
slide45

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
slide46

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.
summary
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.
acknowledgments
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)